drjava-hackers — DrJava developers mailing list

[DrJava] [ drjava-Feature Requests-594354 ] Support Java 1.4 assert statement

[<no...@so...>]

Feature Requests item #594354, was opened at 2002-08-12 18:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=594354&group_id=44253

Category: Compiler integration
Group: Unknown size
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support Java 1.4 assert statement

Initial Comment:
assert is supported in the Sun 1.4 javac, although you 
have to 'enable assertions' with the -ea command-line 
option (even in Forte for Java 1.4 you have to manually 
configure enabling of assertions in about 4 different 
places!).  Would be REALLY nice to use assertions 
under Dr.Java, as the code I'm writing now is stuffed with 
asserts... any easy way to get there??  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=594354&group_id=44253

[DrJava] [ drjava-Feature Requests-594329 ] compiler message printing

[<no...@so...>]

Feature Requests item #594329, was opened at 2002-08-12 19:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=594329&group_id=44253

Category: Compiler integration
Group: None
Status: Open
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler message printing

Initial Comment:
When students come for help, it helps a lot if they bring 
a printout of the compiler error messages, as well as 
the source code. 

Please provide a way to print these messages, ideally 
with a print command for the purpose (might also be 
commands for printing the interactions and console 
window contents, though that is currently possible with 
copy and paste). At the least, make copy work in the 
compiler output tab.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=594329&group_id=44253

Re: [DrJava] ack re jsr14 1.2

[Eric E. A. <eri...@ma...>]

> However, this does pose an interesting dilemma still for testing.  We 
> would
> still need to have both versions of JSR14 available if we were to write
> testcases to handle each situation, no?  (Eric?)  What do we presently 
> do to
> ensure that platform specific bugs don't propogate?

My understanding is that we would then have two implementations of IFoo 
(one for each version of JSR14), and each implementation would be a 
simple adapter, right? In that case, the methods in the adapters would 
be simple forwarding methods, and they should never change, so I think 
it's okay if we don't include unit tests for them (we should be able to 
verify when they're written that they can't possibly break). Then we can 
test the rest of the code with just one of the two adapters, or even a 
mock object adapter if we want to test some of the client code in 
isolation. Of course, the mock object would not help to test the logic 
for reflectively instantiating an adapter...

-- Eric


>
> Just some thoughts before bed...
>
> theo:)
>
> p.s. I had sent that previous message because it's evil how close 
> Ctrl-X and
> Ctrl-C are on the keyboard (Pine shortcuts).  I had originally meant to 
> cancel
> the message and draft one later... but you guys saw what happenned :-D
>
> On Sun, 11 Aug 2002, Charles Reis wrote:
>
>> Date: Sun, 11 Aug 2002 22:49:33 -0500
>> From: Charles Reis <cr...@ri...>
>> To: Brian Stoler <bs...@bs...>
>> Cc: drj...@li...
>> Subject: Re: [DrJava] ack re jsr14 1.2
>>
>> Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly,
>> couldn't we just invoke their compile, etc, methods using reflection?
>> Then we don't have to worry about this if the compiler interface 
>> changes
>> yet again-- we just "invoke" a different method...
>>
>> I'm not entirely against the other method (some classes only compile in
>> some environments), but I'd like to allow everyone to be able to 
>> compile
>> everything as long as we can, if possible...
>>
>> Of course, if reflection isn't an option, I think we'd have to do that
>> anyway-- JSR-14 v1.0 isn't available anymore, so only people who have 
>> an
>> old copy could compile DrJava if we went the route of requiring both.
>> (And we've already gotten complaints from people outside Rice who want
>> to compile.  Rightfully so...)
>>
>> Charlie
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> drjava-hackers mailing list
>> drj...@li...
>> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers

Re: [DrJava] ack re jsr14 1.2

[Theo Y. <ot...@ri...>]

Sorry about the previous truncated post.

I was thinking something similar along Charlie's lines, but in a subtlely
different way (and subsequently had proposed this design to help drjava register
Apple-specific handlers, so we can build on non-apple machines).

So... JSR14 (whichever version) wants us to subclass a class Foo, in their
codebase...

What if we create a dummy subclass (say, AFoo) that delegates to our proprietary
interface, that has identical methods (that way we could always swap out our
implementation).  Let's just use IFoo, for hypothetical reasons.

Thus we have an AFoo class with no logic, and we can compile it *once* with the
proprietary JSR14 classes, and zip it up into our lib directory, never to be
touched again.

In the meanwhile, we write and test whatever necessary IFoos that we wish... and
we can instantiate AFoo (a full-fledged subclass of Foo) with reflection.

So... we follow their rules and subclass -- but we don't dynamically load our
"Foo adapter" to allow us to cooperate with their silly rules.

Apple's event handlers also want us to subclass/implement Apple's proprietary
event interfaces, so I had thought maybe this mechanism would enable us to do
that without requiring the original interfaces to be on the classpath.

However, this does pose an interesting dilemma still for testing.  We would
still need to have both versions of JSR14 available if we were to write
testcases to handle each situation, no?  (Eric?)  What do we presently do to
ensure that platform specific bugs don't propogate?

Just some thoughts before bed...

theo:)

p.s. I had sent that previous message because it's evil how close Ctrl-X and
Ctrl-C are on the keyboard (Pine shortcuts).  I had originally meant to cancel
the message and draft one later... but you guys saw what happenned :-D

On Sun, 11 Aug 2002, Charles Reis wrote:

> Date: Sun, 11 Aug 2002 22:49:33 -0500
> From: Charles Reis <cr...@ri...>
> To: Brian Stoler <bs...@bs...>
> Cc: drj...@li...
> Subject: Re: [DrJava] ack re jsr14 1.2
>
> Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly,
> couldn't we just invoke their compile, etc, methods using reflection?
> Then we don't have to worry about this if the compiler interface changes
> yet again-- we just "invoke" a different method...
>
> I'm not entirely against the other method (some classes only compile in
> some environments), but I'd like to allow everyone to be able to compile
> everything as long as we can, if possible...
>
> Of course, if reflection isn't an option, I think we'd have to do that
> anyway-- JSR-14 v1.0 isn't available anymore, so only people who have an
> old copy could compile DrJava if we went the route of requiring both.
> (And we've already gotten complaints from people outside Rice who want
> to compile.  Rightfully so...)
>
> Charlie
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

[DrJava] Another reason to move to Ant 1.5

[Brian S. <bs...@bs...>]

They added a timezone parameter to the tstamp task. This would allow us to
get rid of the horrible hack that some idiot (me) created of TstampGMT!

-brian

Re: [DrJava] ack re jsr14 1.2

[Brian S. <bs...@bs...>]

> Does JDeveloper handle generics? Any chance of adding support for
> them? ;-)

Right now? Presumably no, or not really at least. I bet you could get
JDeveloper to invoke jsr14 for compilation, but syntax highlighting/code
completion/etc would be all messed up. When I get a chance I'll poke
around and see how hard it would be to hack a mode to support it. (I've
been poking at the source lately investigating my REPL addin.) I'll also
ask the JDev team (of which I am not a member, I'm in a group that makes
some pieces they use/distribute) if they have any plans re generics.

Of course, if they ever become part of the standard SDK I imagine they'd
have support.

-brian

Re: [DrJava] ack re jsr14 1.2

[Brian S. <bs...@bs...>]

> Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly,
> couldn't we just invoke their compile, etc, methods using reflection?

Nope, don't think so. We have to subclass one of their classes (Log) to be
able to catch the errors, and you can't synthesize that reflectively. (I
can't think of a way anyhow!)

> Of course, if reflection isn't an option, I think we'd have to do that
> anyway-- JSR-14 v1.0 isn't available anymore, so only people who have an
> old copy could compile DrJava if we went the route of requiring both.
> (And we've already gotten complaints from people outside Rice who want
> to compile.  Rightfully so...)

Well, you could just technically break the license from Sun and just check
both versions into CVS in the lib directory. Sure, Sun says you're not
allowed to redistribute, but I doubt anyone would notice, and anyhow, it's
only for other developers to be able to compile against it.

Actually, I wonder if you couldn't just use some sort of stubs. Hmm ...
:). Wouldn't it be cool if there was a program to take a set of class
files and create dummy stubs of just their public/protected interfaces?
This would give you a freely redistributable set of classes to satisfy a
build-time dependency. Wouldn't even be so hard to create this. :)

-brian

Re: [DrJava] ack re jsr14 1.2

[Eric E. A. <eri...@ma...>]

Does JDeveloper handle generics? Any chance of adding support for 
them? ;-)

-- Eric

On Sunday, August 11, 2002, at 10:29  PM, Brian Stoler wrote:

> I poked a lot and think I've got most of what I need to do the jsr14
> v1.2/javac 1.4.1 compiler adapter. There's just one huge problem: There 
> is
> a somewhat unresolvable build dependency problem! Here's the catch: To
> compile the old compiler adapter, we need jsr14 1.0 (or javac < 1.4.1) 
> in
> the classpath. But to compile the newer compiler adapter, we need jsr14
> 1.2 in the classpath. Yikes!
>
> So, I can see a couple of ways out of this situation:
>
> 1) Set up a framework like I used to talk about for having sub-projects
> that were compilable only sometimes. This same framework would apply to
> problems like this, as well as to OS-specific code. The idea is that the
> separate subprojects would be broken off into their own directories, and
> that on commit the class files would be committed as well as the source
> files. Then, the main project build system would take the committed 
> class
> files and use them to compile. Thus, the main build would not need to
> satisfy the weird build-time dependencies of the various sub-modules.
>
> or, for just this problem:
>
> 2) Force all developers to have both JSR14 v1.0 and JSR14 v1.2 in their
> lib directory. Then, compile each's compiler adapter separately as a 
> part
> of the compilation process, adding the relevant compiler to the 
> classpath
> just for that compilation. I think this should work reasonably.
>
> What do you guys think? As I said, the actual issue of making a JSR14 
> v1.2
> compiler adapter is not really that hard, but it brings up this tough
> issue. :)
>
> BTW, one side tiny problem that's easy to fix is the fact that if you 
> try
> to compile DrJava via Ant using JSR14 v1.2, it doesn't work. The reason 
> is
> that JSR14 v1.2 seems to default to having generics off unless you pass
> "-gj" on the compiler command line. Anyhow, this can be done trivially 
> in
> the build-common.xml task by putting a <compilerarg value="-gj" /> 
> inside
> the <javac>. This will keep the build script working on JSR14 1.0 as
> well, but the one small catch is that it requires Ant 1.5 to execute. No
> big deal I guess.
>
> Anyway ... .
>
> -brian
>
> PS: As you can see, I'm still playing a bit with DrJava in my spare 
> time.
> :) Another side project I'm beginning to investigate is creating a REPL
> module to put into Oracle's IDE JDeveloper. JDeveloper, by the way, is
> actually not bad (and they're not paying me to say this!). I mean, it
> helps a lot for making big goofy apps like Web applications, but it's 
> also
> got some nice stuff like good code completion, etc. It is, however, a
> memory hog and pretty slow on my home P2/350. Also, the new version 
> that's
> not out yet (9.0.3) is much better.
>
> Anyhow ... :)
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers

Re: [DrJava] ack re jsr14 1.2

[Charles R. <cr...@ri...>]

Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly, 
couldn't we just invoke their compile, etc, methods using reflection? 
Then we don't have to worry about this if the compiler interface changes 
yet again-- we just "invoke" a different method...

I'm not entirely against the other method (some classes only compile in 
some environments), but I'd like to allow everyone to be able to compile 
everything as long as we can, if possible...

Of course, if reflection isn't an option, I think we'd have to do that 
anyway-- JSR-14 v1.0 isn't available anymore, so only people who have an 
old copy could compile DrJava if we went the route of requiring both. 
(And we've already gotten complaints from people outside Rice who want 
to compile.  Rightfully so...)

Charlie

Re: [DrJava] ack re jsr14 1.2

[Theo Y. <ot...@ri...>]

What ab

On Sun, 11 Aug 2002, Brian Stoler wrote:

> Date: Sun, 11 Aug 2002 20:29:37 -0700 (PDT)
> From: Brian Stoler <bs...@bs...>
> To: drj...@li...
> Subject: [DrJava] ack re jsr14 1.2
>
> I poked a lot and think I've got most of what I need to do the jsr14
> v1.2/javac 1.4.1 compiler adapter. There's just one huge problem: There is
> a somewhat unresolvable build dependency problem! Here's the catch: To
> compile the old compiler adapter, we need jsr14 1.0 (or javac < 1.4.1) in
> the classpath. But to compile the newer compiler adapter, we need jsr14
> 1.2 in the classpath. Yikes!
>
> So, I can see a couple of ways out of this situation:
>
> 1) Set up a framework like I used to talk about for having sub-projects
> that were compilable only sometimes. This same framework would apply to
> problems like this, as well as to OS-specific code. The idea is that the
> separate subprojects would be broken off into their own directories, and
> that on commit the class files would be committed as well as the source
> files. Then, the main project build system would take the committed class
> files and use them to compile. Thus, the main build would not need to
> satisfy the weird build-time dependencies of the various sub-modules.
>
> or, for just this problem:
>
> 2) Force all developers to have both JSR14 v1.0 and JSR14 v1.2 in their
> lib directory. Then, compile each's compiler adapter separately as a part
> of the compilation process, adding the relevant compiler to the classpath
> just for that compilation. I think this should work reasonably.
>
> What do you guys think? As I said, the actual issue of making a JSR14 v1.2
> compiler adapter is not really that hard, but it brings up this tough
> issue. :)
>
> BTW, one side tiny problem that's easy to fix is the fact that if you try
> to compile DrJava via Ant using JSR14 v1.2, it doesn't work. The reason is
> that JSR14 v1.2 seems to default to having generics off unless you pass
> "-gj" on the compiler command line. Anyhow, this can be done trivially in
> the build-common.xml task by putting a <compilerarg value="-gj" /> inside
> the <javac>. This will keep the build script working on JSR14 1.0 as
> well, but the one small catch is that it requires Ant 1.5 to execute. No
> big deal I guess.
>
> Anyway ... .
>
> -brian
>
> PS: As you can see, I'm still playing a bit with DrJava in my spare time.
> :) Another side project I'm beginning to investigate is creating a REPL
> module to put into Oracle's IDE JDeveloper. JDeveloper, by the way, is
> actually not bad (and they're not paying me to say this!). I mean, it
> helps a lot for making big goofy apps like Web applications, but it's also
> got some nice stuff like good code completion, etc. It is, however, a
> memory hog and pretty slow on my home P2/350. Also, the new version that's
> not out yet (9.0.3) is much better.
>
> Anyhow ... :)
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

[DrJava] ack re jsr14 1.2

[Brian S. <bs...@bs...>]

I poked a lot and think I've got most of what I need to do the jsr14
v1.2/javac 1.4.1 compiler adapter. There's just one huge problem: There is
a somewhat unresolvable build dependency problem! Here's the catch: To
compile the old compiler adapter, we need jsr14 1.0 (or javac < 1.4.1) in
the classpath. But to compile the newer compiler adapter, we need jsr14
1.2 in the classpath. Yikes!

So, I can see a couple of ways out of this situation:

1) Set up a framework like I used to talk about for having sub-projects
that were compilable only sometimes. This same framework would apply to
problems like this, as well as to OS-specific code. The idea is that the
separate subprojects would be broken off into their own directories, and
that on commit the class files would be committed as well as the source
files. Then, the main project build system would take the committed class
files and use them to compile. Thus, the main build would not need to
satisfy the weird build-time dependencies of the various sub-modules.

or, for just this problem:

2) Force all developers to have both JSR14 v1.0 and JSR14 v1.2 in their
lib directory. Then, compile each's compiler adapter separately as a part
of the compilation process, adding the relevant compiler to the classpath
just for that compilation. I think this should work reasonably.

What do you guys think? As I said, the actual issue of making a JSR14 v1.2
compiler adapter is not really that hard, but it brings up this tough
issue. :)

BTW, one side tiny problem that's easy to fix is the fact that if you try
to compile DrJava via Ant using JSR14 v1.2, it doesn't work. The reason is
that JSR14 v1.2 seems to default to having generics off unless you pass
"-gj" on the compiler command line. Anyhow, this can be done trivially in
the build-common.xml task by putting a <compilerarg value="-gj" /> inside
the <javac>. This will keep the build script working on JSR14 1.0 as
well, but the one small catch is that it requires Ant 1.5 to execute. No
big deal I guess.

Anyway ... .

-brian

PS: As you can see, I'm still playing a bit with DrJava in my spare time.
:) Another side project I'm beginning to investigate is creating a REPL
module to put into Oracle's IDE JDeveloper. JDeveloper, by the way, is
actually not bad (and they're not paying me to say this!). I mean, it
helps a lot for making big goofy apps like Web applications, but it's also
got some nice stuff like good code completion, etc. It is, however, a
memory hog and pretty slow on my home P2/350. Also, the new version that's
not out yet (9.0.3) is much better.

Anyhow ... :)

[DrJava] [ drjava-Bugs-593204 ] testing 20030731-1445 and beta-20020804

[<no...@so...>]

Bugs item #593204, was opened at 2002-08-09 15:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=593204&group_id=44253

Category: Interactions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sue McGlashan (smcglash)
Assigned to: Nobody/Anonymous (nobody)
Summary: testing 20030731-1445 and beta-20020804

Initial Comment:
Hi

I tested the above on 2 systems:

Linux (standard Redhat 7.3 install),   and
W2K, running the Novell client.   Both had jdk1.4.

In Linux, the beta version worked (short tests), although 
it did complain about being unable to convert various 
strings, before starting.

The 20030731-1445 version  froze, after the following:
open a file
compile the file
run the file
compile the file
At this point, trying to run the file again caused drjave to 
freeze.  This sequence was reproducible whether using 
the same or two different files, after the second compile.


With the W2K, Novell client combination, I got the same 
problem I have previosly reported, except that I was 
unable to compile anything at all.

Thank you



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=593204&group_id=44253

[DrJava] [ drjava-Feature Requests-593053 ] Syntax coloring in Interactions

[<no...@so...>]

Feature Requests item #593053, was opened at 2002-08-09 13:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=593053&group_id=44253

Category: Interactions
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax coloring in Interactions

Initial Comment:
It would be nice if the Interactions Pane colored the
text the same way as the Definitions Pane, and possibly
also had the brace matching highlights.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=593053&group_id=44253

[DrJava] [ drjava-Bugs-592660 ] Can't compile using JDK 1.4.1 beta

[<no...@so...>]

Bugs item #592660, was opened at 2002-08-08 16:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=592660&group_id=44253

Category: Compiler integration
Group: Serious
Status: Open
Resolution: None
Priority: 7
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't compile using JDK 1.4.1 beta

Initial Comment:
It appears that the compiler in the tools.jar supplied
with JDK 1.4.1 beta will not work with DrJava.  Sun
doesn't distribute the source for their compiler (or
even the API, apparently), which makes this a little
difficult to track down.  Using javap, though, I
discovered that the JavaCompiler class appears to have
changed in the same way as JSR-14 (from 1.0 to 1.2). 
Looks like Sun is moving towards this new API, but we
still don't support it yet.

If 1.4.1 actually does use the JSR-14 v1.2, then we can
probably figure out what to change in our code (since
we have the JSR-14 code).  But we might just be forced
to start exec'ing the compiler and parsing the results,
since it's less than an ideal situation to have to
change our code every time Sun decides to change its
compiler...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=592660&group_id=44253

[DrJava] [ drjava-Feature Requests-592214 ] Generate Test Case from Class

[<no...@so...>]

Feature Requests item #592214, was opened at 2002-08-07 18:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=592214&group_id=44253

Category: Other
Group: Large (> 1 pair-month)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Generate Test Case from Class

Initial Comment:
(This is essentially the inverse of Feature Request
525996.)

For beginning students with no Java experience, it
could be very useful to be able to automatically
generate a simple test case class given an existing
class.  The process would involve displaying some sort
of dialog which would allow users to specify sample
inputs and expected outputs for any non-private method
in the class being tested.  (Strings and other
primitives wouldn't be a problem; perhaps for objects
users could just enter the appropriate code as if in
the Interactions pane.)  DrJava would then generate
code for the test case using several test methods which
each called assertEquals.

We wouldn't care about making this TOO robust, because
once students get some experience, they should learn to
write the test cases themselves.  But this sort of tool
would allow teachers to introduce unit testing from the
very beginning, without having to explain any of the
details needed for writing a test (eg. import
statements, inheritence, public, etc).  And as long as
the tool also put in some reasonable comments, it could
be an example of good coding style, as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=592214&group_id=44253

[DrJava] [ drjava-Bugs-592037 ] Non-intuitive Interactions classpath

[<no...@so...>]

Bugs item #592037, was opened at 2002-08-07 13:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=592037&group_id=44253

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 6
Submitted By: Charles Reis (csreis)
Assigned to: Charles Reis (csreis)
Summary: Non-intuitive Interactions classpath

Initial Comment:
The interactions classpath always includes DrJava's own
classpath before any directories which have been
specified on "extra.classpath" or the source roots of
the currently open documents.  This can be confusing to
new users if DrJava is started from the desktop, and if
old versions of class files are left on the desktop. 
Instead, the interactions classpath should first
include any source root directories, then
extra.classpath, and then DrJava's own classpath.  

(The only problem with this is the possibility of
defining a separate
edu.rice.cs.drjava.model.repl.newjvm.InteractionsJVM
class, which would then cause DrJava to crash when
resetting the interactions pane.  To fix this, we
should really modify how DynamicJava loads classes so
that it does not look on the system classpath.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=592037&group_id=44253

[DrJava] [ drjava-Bugs-591785 ] Compiler doesn't find all class files

[<no...@so...>]

Bugs item #591785, was opened at 2002-08-06 22:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591785&group_id=44253

Category: Compiler integration
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: James Hsia (jhsia)
Summary: Compiler doesn't find all class files

Initial Comment:
The compiler doesn't always find class files that it
needs for compiling a given file, even if the class
files exist in the same directory as the file being
compiled.  This is the case if compiling a single file
Foo which depends on a non-public class Bar defined in
a file not named Bar.  Even if Bar.class exists in the
same directory as Foo.java, DrJava's compiler can't
find it (though javac on the command line can).  This
can also cause problems with Compile All if everything
but Foo.java is already in sync (so Foo.java ends up
being the only file compiled). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591785&group_id=44253

[DrJava] [ drjava-Feature Requests-591773 ] Customizable LookAndFeel

[<no...@so...>]

Feature Requests item #591773, was opened at 2002-08-06 15:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591773&group_id=44253

Category: User interface
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Customizable LookAndFeel

Initial Comment:
Please add the ability to select the Swing LookAndFeel, 
and maybe even the ability to customize the themes for 
the MetalLookAndFeel.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591773&group_id=44253

[DrJava] [ drjava-Bugs-591709 ] Clicking Compile then Test hangs

[<no...@so...>]

Bugs item #591709, was opened at 2002-08-06 19:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591709&group_id=44253

Category: Compiler integration
Group: Crashes
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: James Hsia (jhsia)
Summary: Clicking Compile then Test hangs

Initial Comment:
If the user clicks Compile All on the toolbar and then
quickly clicks the Test button, DrJava will hang.  This
is because Compile runs in a SwingWorker thread, so
different threads are trying to access the compiler at
the same time (testing forces a compile).  To fix this,
make sure any method which will access the compiler is
mutually exclusive (with a synchronization lock).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591709&group_id=44253

[DrJava] [ drjava-Feature Requests-591642 ] Print Interactions Pane option

[<no...@so...>]

Feature Requests item #591642, was opened at 2002-08-06 16:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591642&group_id=44253

Category: Interactions
Group: None
Status: Open
Priority: 4
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Print Interactions Pane option

Initial Comment:
There should be an option to print the contents of the
interactions pane.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591642&group_id=44253

[DrJava] [ drjava-Feature Requests-591637 ] JUnit progress bar

[<no...@so...>]

Feature Requests item #591637, was opened at 2002-08-06 16:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591637&group_id=44253

Category: User interface
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: JUnit progress bar

Initial Comment:
JUnit should display a progress bar as it runs the
tests.  I think some of this code was already in place
in the existing JUnit integration, but it wasn't
working before.  To get it to work, use a SwingWorker
and Swing timers, as described on the page below:

http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591637&group_id=44253

[DrJava] [ drjava-Feature Requests-591631 ] New Test Case option in File menu

[<no...@so...>]

Feature Requests item #591631, was opened at 2002-08-06 16:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591631&group_id=44253

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: New Test Case option in File menu

Initial Comment:
There should be a "New Test Case" option in the File
menu which prompts for the name of the class and then
generates the necessary framework code.  (ie. the
import statement, class ... extends TestCase, and the
constructor.)  We could optionally add some comments
and possibly even start a "public void test" method for
them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591631&group_id=44253

[DrJava] [ drjava-Feature Requests-591529 ] Warn if interactions out of sync

[<no...@so...>]

Feature Requests item #591529, was opened at 2002-08-06 12:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591529&group_id=44253

Category: Interactions
Group: Small (< 1 pair-week)
Status: Open
Priority: 6
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warn if interactions out of sync

Initial Comment:
If anything is entered in the Interactions Pane when the 
open documents are out of sync, a warning message 
should be displayed (much like in DrScheme).  This 
should definitely be triggered by files which have been 
saved but not compiled, and probably also triggered by 
modified but unsaved files.  The message will only go 
away after the Interactions Pane is reset (possibly 
through a compile).  Perhaps, unlike DrScheme, we can 
only show the message once, but always have it appear 
just before the prompt.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=591529&group_id=44253

[DrJava] [ drjava-Bugs-591244 ] Moving or deleting files causes errors

[<no...@so...>]

Bugs item #591244, was opened at 2002-08-05 18:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591244&group_id=44253

Category: Other
Group: Makes DrJ unstable
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Moving or deleting files causes errors

Initial Comment:
If the file of an open document is moved or deleted on
disk, DrJava doesn't handle it very well.  Clicking on
Compile All or Compile Current causes either exceptions
to be thrown or the user interface to hang.  Other
features involving files might cause similar problems.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591244&group_id=44253

[DrJava] [ drjava-Bugs-591123 ] repl bug w/conditional expressions

[<no...@so...>]

Bugs item #591123, was opened at 2002-08-05 09:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591123&group_id=44253

Category: DynamicJava
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: repl bug w/conditional expressions

Initial Comment:
When DynamicJava evaluates a conditional expression, it evaluates 
all clauses, regardless of the the result of the test clause!

For example: 

  (false ? 1/0 : 2) 

results in

  java.lang.ArithmeticExpression: / by zero

-- Eric


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=591123&group_id=44253