drjava-hackers — DrJava developers mailing list

[DrJava] New DrJava release supports Java 1.4.1 / JSR-14 v1.2

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

   The drjava-20020913-2254 release adds support for the Java 1.4.1 and 
JSR-14 v1.2 compilers.  The JSR-14 compiler is an experimental compiler 
available from Sun which supports generics.  DrJava developers can also 
now use JSR-14 v1.2 to compile the DrJava codebase.

   Download this release if you need to use either of these compilers 
within DrJava, and let us know if you have any problems.

Direct link to the release:
http://sourceforge.net/project/showfiles.php?group_id=44253&release_id=110914

Link to download JSR-14 (free login required):
http://developer.java.sun.com/developer/earlyAccess/adding_generics

Charlie

[DrJava] [ drjava-Ease of use Issues-609465 ] Default Compiler Message

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

Ease of use Issues item #609465, was opened at 2002-09-14 22:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=460211&aid=609465&group_id=44253

Category: Platform Independent
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default Compiler Message

Initial Comment:
The default string displayed in the Compiler Output tab should be different from the string displayed after a successful compilation.  This would allow a user to tell at a glance whether he has compiled something within DrJava yet or not.

This is primarily an issue when a user cannot compile because DrJava cannot find a compiler or because the selected compiler doesn't function properly within DrJava (i.e. JSR14 1.2, javac 1.4).  It can be misleading to see a "successful" message when no compilation is possible.  This would also be relevant when a user switches from one compiler to another.  Therefore, when a compiler is first setup or swapped, the message should be distinct.

I would be satisfied with a blank, "stateless" message.  A better solution would be to verify that the compiler is ready and display either a prompt or a warning, e.g. "No compiler has been specified.  Please choose a compiler in the Preferences dialog in the Edit menu."

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

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

[DrJava] [ drjava-Feature Requests-609462 ] Default WD on Interactions Path

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

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

Category: Interactions
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default WD on Interactions Path

Initial Comment:
The default working directory of DrJava (usually the directory from which DrJava was launched) should be included on the Interactions Path.  This would allow a user to launch DrJava and use it exclusively for the REPL features without first opening an arbitrary file in the directory.  This would also be consistent with the behavior when a working directory is specified in the configuration file.

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

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

[DrJava] More JSR-14 Refactoring

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

   Thanks to the compiler adapter Brian sent me, DrJava now supports 
using the JSR-14 v1.2 and Java 1.4.1+ compilers, as of the 
drjava-20020913-2254 commit.

   Once again, all developers will need to update their environment to 
get the new adapter working.  Since some of the classes can only be 
compiled in JSR-14 v1.2 (which won't work on OS X), the class files have 
been pre-compiled and stored in the compilers-jsr14v1_2.jar file in the 
src/edu/rice/cs/lib/ directory.  You will need to update this directory 
and put this jar file on your classpath, or you will not be able to compile!

   The source files themselves have been added to the src/src-jsr14v1_2/ 
source tree.  Feel free to update your local copy of this, though you 
don't need to unless you need to modify these files (ie. with "ant 
compile-jsr14v1_2").  See the 
src/edu/rice/cs/drjava/model/compiler/readme.txt file for more details.

   I'll do a release with the JSR-14 v1.2 support soon.  Please test it 
out and let me know if you have any problems.

Thanks!
Charlie

Re: [DrJava] Test Failure

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

   Did you also CVS update the rest of your repository?  Specifically, 
did you get the compilers-jsr14v1_0.jar in the lib directory, and then 
add it to your classpath?  There's instructions on how to update after 
the JSR-14 changes in my last email.

   Anyway, I'm trying to run the tests on OS X right now and the 
DebugTest is failing, giving a java.net.ConnectException in 
testStartupAndShutdown.  I'll eventually look into this, but the JSR-14 
stuff is higher priority for me at the moment.

   If you have followed all the steps in the last email and still get 
this problem, let me know.  I'm able to run CompilerRegistryTest in 
isolation on my iBook without a problem, so I think it's probably a 
classpath issue.

(By the way, updating everything means you have to get Ant 1.5.  This is 
not available through Fink on OS X, or at least it only went up to Ant 
1.4.1 for me.  But if you download the Ant 1.5 binary from Ant's web 
site, it works fine on OS X.)

Charlie


Peter Centgraf wrote:
> Just for the hell of it, I ran "ant update clean compile test" on my Mac 
> OS 10.1.5 iBook.  The first test case took 76s, which is quite 
> excessive, but I figure that probably includes slow Mac OS X JVM loading 
> time.  The other quirk is a little harder to explain away.  Can anyone 
> duplicate this failure?  I'll send my .drjava to the curious.
> 
>     [junit] Testcase: testLimitOneByOne took 0.075 sec
>     [junit]     FAILED
>     [junit] Number of available compilers expected:<0> but was:<1>
>     [junit] junit.framework.AssertionFailedError: Number of available 
> compilers expected:<0> but was:<1>
>     [junit]     at junit.framework.Assert.fail(Assert.java:51)
>     [junit]     at junit.framework.Assert.failNotEquals(Assert.java:234)
>     [junit]     at junit.framework.Assert.assertEquals(Assert.java:68)
>     [junit]     at junit.framework.Assert.assertEquals(Assert.java:181)
>     [junit]     at 
> edu.rice.cs.drjava.model.compiler.CompilerRegistryTest._getCompilersAfterDisablingSome(
> CompilerRegistryTest.java:209)
>     [junit]     at 
> edu.rice.cs.drjava.model.compiler.CompilerRegistryTest._getCompilersAfterDisablingOne(
> CompilerRegistryTest.java:189)
>     [junit]     at 
> edu.rice.cs.drjava.model.compiler.CompilerRegistryTest.testLimitOneByOne
> (CompilerRegistryTest.java:127)
> 
>     + junit stack overhead . . .
> 
> --
> Peter
> 
> 
> 
> -------------------------------------------------------
> 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] Test Failure

[Peter C. <cen...@ri...>]

Just for the hell of it, I ran "ant update clean compile test" 
on my Mac OS 10.1.5 iBook.  The first test case took 76s, which 
is quite excessive, but I figure that probably includes slow Mac 
OS X JVM loading time.  The other quirk is a little harder to 
explain away.  Can anyone duplicate this failure?  I'll send my 
.drjava to the curious.

     [junit] Testcase: testLimitOneByOne took 0.075 sec
     [junit]     FAILED
     [junit] Number of available compilers expected:<0> but was:<1>
     [junit] junit.framework.AssertionFailedError: Number of 
available compilers expected:<0> but was:<1>
     [junit]     at junit.framework.Assert.fail(Assert.java:51)
     [junit]     at junit.framework.Assert.failNotEquals(Assert.java:234)
     [junit]     at junit.framework.Assert.assertEquals(Assert.java:68)
     [junit]     at junit.framework.Assert.assertEquals(Assert.java:181)
     [junit]     at 
edu.rice.cs.drjava.model.compiler.CompilerRegistryTest._getCompilersAfterDisablingSome(
CompilerRegistryTest.java:209)
     [junit]     at 
edu.rice.cs.drjava.model.compiler.CompilerRegistryTest._getCompilersAfterDisablingOne(
CompilerRegistryTest.java:189)
     [junit]     at 
edu.rice.cs.drjava.model.compiler.CompilerRegistryTest.testLimitOneByOne
(CompilerRegistryTest.java:127)

	+ junit stack overhead . . .

--
Peter

[DrJava] DrJava / JSR-14 Refactoring

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

   I've been working on refactoring DrJava to start supporting the 
JSR-14 v1.2 compiler, which uses a different source tree than the JSR-14 
v1.0 compiler.  Essentially, to maintain support for Java 1.3 and JSR-14 
v1.0 compiler adapters within DrJava (eg. on Mac OS X), the adapters 
have to be compiled using JSR-14 v1.0.  However, Sun does not distribute 
this version any longer, nor will this version allow us to compile an 
adapter for JSR-14 v1.2.

   Because of this, all files dependent on the JSR-14 v1.0 compiler have 
been moved to a separate source tree, and pre-compiled copies of their 
class files are now included in the compilers-jsr14v1_0.jar file in the 
lib directory, which should be added to your classpath.  You don't need 
to worry about compiling these classes when building DrJava.  (If you do 
need to make changes to them, use the "ant compile-jsr14v1_0" command.)

   One important note: some of the changes require us to now use Ant 1.5 
instead of Ant 1.4, so be sure to upgrade your copy of Ant if necessary. 
  (I've upgraded the copy in the javaplt directory.)

   To get all the changes I've just committed, I would suggest either 
running "cvs update" from your "src" directory, or checking the code out 
from scratch.  The only things that are essential, though, are updating 
your lib directory, build-common.xml, and the drjava directory.

   At this point, DrJava can be compiled using either JSR-14 v1.0 or 
JSR-14 v1.2.  I'll work on creating a compiler adapter for JSR-14 v1.2 
next, so that it can be used within DrJava.

Let me know if you have any questions...

Charlie

[DrJava] [ drjava-Bugs-607929 ] fails to connect to debugger

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

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

Category: Debugger
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hicks (mwhicks1)
Assigned to: Nobody/Anonymous (nobody)
Summary: fails to connect to debugger

Initial Comment:
I'm running the curent stable release
(drjava-stable-20020814.jar), on Redhat Linux 7.3.  I'm
using Java 1.4 SDK (java version "1.4.0_01", Java(TM) 2
Runtime Environment, Standard Edition (build
1.4.0_01-b03), Java HotSpot(TM) Client VM (build
1.4.0_01-b03, mixed mode)).  I could not get the
properties info out of the About panel, as it's now a
table, and X doesn't want to grab the contents into its
buffer--tips for this?

In any case, my problem was that when I started the
debugger (click Debug-Mode in the debugging panel), I
would get an exception:

Could not start the debugger.
edu.rice.cs.drjava.model.debug.DebugException: Could
not connect to VM: java.net.ConnectException:
Connection refused.

However, this seems to have magically fixed itself
while I've been typing up this report!  That is, in
trying to do this repeatedly, it has started working,
and I haven't been able to recreate the original
failure.  Therefore, this report can serve to be just
informational until it happens again, and I can report
more information.


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

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

[DrJava] [ drjava-Bugs-606485 ] printouts are massive therefore slow

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

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

Category: Performance
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Byer (bushing)
Assigned to: Nobody/Anonymous (nobody)
Summary: printouts are massive therefore slow

Initial Comment:
DrJava Version : 20020904-2101

bash-2.01$ wc -l Parser.java 
     224 Parser.java

bash-2.01$ lpq
Printer: ryon1.2ps@printer
 Queue: 1 printable job
 Server: pid 16382 active
 Unspooler: pid 16384 active
 Status: processing 'dfA098two-feet.owlnet.rice.edu',
size 9413252, format 'f', IF filter 'hpif' at
17:16:50.712
 Filter_status: 00 BBYER    
 Rank   Owner/ID                  Class Job
Files                 Size Time
1      ==bbyer@two-feet+98.1.1      A    98 Java
Printing      9413252 17:16:50


:)
Ben


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

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

[DrJava] DrJava Release

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

   A new release of DrJava (drjava-20020904-2101) has been posted on 
SourceForge in the "Development Releases" category, which resolves many 
of the JUnit, RMI, and classpath issues from the most recent stable 
release (drjava-stable-20020814).

You can download this new release from the following links:

http://sourceforge.net/project/showfiles.php?group_id=44253&release_id=108991
http://drjava.sourceforge.net/current.shtml  (the second link)

You can view the release notes here:

http://sourceforge.net/project/shownotes.php?release_id=108991


   We recommend upgrading to this version until the next stable release 
is out.  If you are using DrJava in a course, we recommend testing and 
using this version with your students-- we will provide rapid feedback 
on any bug reports from this version.

   Thanks, and please continue to send your feedback!

Charlie Reis

[DrJava] [ drjava-Bugs-604459 ] MacOS-X last (stable ?) version quits.

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jp roy (jp4id)
Assigned to: Nobody/Anonymous (nobody)
Summary: MacOS-X last (stable ?) version quits.

Initial Comment:
This release does not word at all on MacOS-X.
DrJava is not launched.
I think it is the same with Win2000.
Please, we are starting a course soon.

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

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

[DrJava] [ drjava-Bugs-604309 ] application std input

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

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

Category: Interactions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: application std input

Initial Comment:
When an application is run in the interactions window 
using the "java ..." mechanism, it can't read from 
System.in. Thus DrJava can't be used with lots of (old 
fashioned :) Java texts that do much with this style of 
running java programs.

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

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

[DrJava] [ drjava-Bugs-603842 ] Interactions window loses focus

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

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

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interactions window loses focus

Initial Comment:
After executing a program from the interactions window 
(example: java Lexer) and resetting the interactions 
window while the program is doing something (for 
example, waiting for input), the interactions window 
loses focus after every keystroke.

This was tested using the lexer.java file from Rice's 
Comp 311 class, assignment 1.

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

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

[DrJava] [ drjava-Bugs-603414 ] Can't start stable (?) DrJava in Win2k

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

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

Category: Other
Group: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't start stable (?) DrJava in Win2k

Initial Comment:

"drjava-stable-20020814.jar" do not start
"drjava-beta-20020619-0308.jar" always worked in same
configuration

It seems something related to keystroke to action
association in configuration routines: it doesn't
recognize keystrokes identified by strings like "ctrl
maiusc S"

Logs follow

bye, 
Stefano

***********************************************

C:\temp> ver
Microsoft Windows 2000 [Versione 5.00.2195]

(NB: w2k Italian version)

************************************************

C:\temp>java -version
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

************************************************
C:\temp>java -jar drjava-stable-20020814.jar
Exception in thread "main"
java.lang.ExceptionInInitializerError 
at
edu.rice.cs.drjava.config.SavableConfiguration.loadConfiguration(Sava
bleConfiguration.java:71)
        at
edu.rice.cs.drjava.config.FileConfiguration.loadConfiguration(FileCon
figuration.java:66)
        at
edu.rice.cs.drjava.config.DefaultFileConfig.evaluate(ConfigurationToo
l.java:81)
        at
edu.rice.cs.drjava.config.ConfigurationTool.<clinit>(ConfigurationToo
l.java:64)
        at
edu.rice.cs.drjava.DrJava.<clinit>(DrJava.java:64)
Caused by: Could not parse configuration option.
Option: key.save.file.as
Given value: "ctrl maiusc S"
Must be a valid string representation of a Keystroke.
        at
edu.rice.cs.drjava.config.KeyStrokeOption.parse(KeyStrokeOption.java:
114)
        at
edu.rice.cs.drjava.config.KeyStrokeOption.parse(KeyStrokeOption.java:
52)
        at
edu.rice.cs.drjava.config.OptionParser.setString(OptionParser.java:10
4)
        at
edu.rice.cs.drjava.config.KeyStrokeOption.setString(KeyStrokeOption.j
ava:52)
        at
edu.rice.cs.drjava.config.DefaultOptionMap.setString(DefaultOptionMap
.java:68)
        at
edu.rice.cs.drjava.config.OptionMapLoader.<clinit>(OptionMapLoader.ja
va:75)
        ... 5 more



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

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

[DrJava] [ drjava-Bugs-600270 ] No debugging in non-public class

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

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

Category: Debugger
Group: Annoying
Status: Open
Resolution: None
Priority: 6
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: No debugging in non-public class

Initial Comment:
Currently, the debugging features do not work well with
non-public classes.  Breakpoints are not hit unless the
breakpoint is in the first class of the file, and
stepping is unable to find the source file for a class,
even if it is open.  (For now, debugging only works
well with public classes.)

This is partly because of an incorrect assumption in
the debugger code that a class always resides in a
source file of the same name.  To fix this, we'll have
to change getClassName() in DefinitionsDocument to
return the correct class name for a given position,
instead of just the first class declared.  We'll also
have to find a method for locating the source file
containing a non-public class (I think there's a way to
do this using JPDA / JDI methods).

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

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

[DrJava] [ drjava-Bugs-599304 ] No extra.classpath in user-defined class

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

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

Category: Interactions
Group: Serious
Status: Open
Resolution: None
Priority: 7
Submitted By: Charles Reis (csreis)
Assigned to: Charles Reis (csreis)
Summary: No extra.classpath in user-defined class

Initial Comment:
If classes or jars on the "extra.classpath" are
referenced by user-defined classes (eg. a subclassing a
class in a custom jar, like objectdraw.jar), they
cannot be used in the Interactions window, which will
complain about not being able to find the super class.
 However, referencing the super class directly works.

This was a bug introduced during the development of the
debugger, related to the "sticky class loader" used by
the Interactions pane.  It is present in the most
recent stable release, but is now resolved (and the
debugger has been updated accordingly).  The fix will
be included in the next release-- this bug report is
merely for the record.

Note that this bug directly affects using
objectdraw.jar in DrJava (which is in use at several
universities).  The workaround that had been discovered
was to put objectdraw.jar on the command line classpath
when starting DrJava.  This is no longer necessary--
simply putting objectdraw.jar in the "Interactions
Classpath" of the Preferences Window will work now.

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

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

[DrJava] [ drjava-Bugs-597966 ] interactions frame close crash

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

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

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: interactions frame close crash

Initial Comment:
My students will be making extensive use of DrJava in 
conjunction with the objectdraw package 
(http://applecore.cs.williams.edu/~cs134/eof/library/). 
objectdraw.FrameWindowController is used to create 
frames that behave like applets. Program tests usually 
involve creating these frames. When the frame is closed 
it calls System.exit(0). DrJava pops up a dialog 
confirming that you want to proceed, since it terminates 
the interactions session. I wish this dialog could be 
avoided, but that's not what this report is about.

After a number of frames have been closed this way in 
the same DrJava process, the process may hang when 
this dialog appears. Have to kill it with the task 
manager. Ugh.

import objectdraw.*;
class Test extends FrameWindowController {}

should be enough to test this. Do new Test() a number 
of times in the interactions window, closing each frame 
that pops up before doing it again.

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

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

[DrJava] [ drjava-Bugs-597926 ] compiler output hour glass

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

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

Category: Compiler integration
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler output hour glass

Initial Comment:
After a compile with cursor in editor window, the cursor 
returns from an hour glass to pointer. But if you then 
move it into the compiler output tab, it turns back into 
an hour glass. Switch tabs and the problem goes away.

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

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

[DrJava] [ drjava-Ease of use Issues-595765 ] Mac OS Save Prompt

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

Ease of use Issues item #595765, was opened at 2002-08-15 17:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=460211&aid=595765&group_id=44253

Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac OS Save Prompt

Initial Comment:
When closing an unsaved file, DrJava prompts the user with a Cancel/No/Yes dialog asking whether to save the file.  On Mac OS, it is standard to arrange the dialog as Don't Save/Cancel/Save, with the buttons in that reading order.  It is also extremely common to bind Command-D to the Don't Save option.  DrJava should follow this standard, at least on Mac OS.

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

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

[DrJava] [ drjava-Ease of use Issues-595759 ] Tab Toggles

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

Ease of use Issues item #595759, was opened at 2002-08-15 17:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=460211&aid=595759&group_id=44253

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tab Toggles

Initial Comment:
As of version 20020814-0343, there is no central place to manage the tabs displayed at the bottom of the screen.  The only operation possible is to close each tab by switching to it and hitting the close check-box.  Some panes cannot be removed at all.  This arrangement creates an non-reversible operation - closing a pane.

I suggest a new "View" menu, placed between the Edit and Tools menus, which would contain CheckBoxMenuItems corresponding to all of the lower tabs.  When a menu item is checked, the tab would be visible.  This list should include all of the tabs, including Interactions, Console, and Debug (if available).  If no tab is visible, the split pane divider should be removed.  This would maintain consistency and emphasize that the operation is performing a purely visual function.  All operations using the tabs should proceed in the background, so that changes will be displayed immediately upon revealing a tab.  There should be no functional difference for the rest of DrJava whether a tab is hidden or visible.

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

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

[DrJava] [ drjava-Feature Requests-595750 ] Allow "compiler" to be any class file

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

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

Category: Compiler integration
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow "compiler" to be any class file

Initial Comment:
Why not allow the user to select an arbitrary class as a compiler? 
We could call the main method of the specified class, passing in the 
source file to compile. We would then display the output to 
System.err. And if those errors conform to the expected grammar 
(which we'd have to provide in the documentation) we could even 
pop to the source locations!

At first glance, this doesn't seem like it'd be hard to implement, 
but the payoff would be immense. It would make integration of all 
sorts of source-transforming tools (e.g., AspectJ, iContract, the 
Java Syntactic Extender, Daikon, ESCJava, etc.) trivial. In fact, it 
would also allow for easy integration of Java compilers such as 
Jikes that are written in other languages (just write a class to call 
exec). As long as errors are piped to System.err, we can display 
them, 

If we did this, we may also want to rethink how we integrate JSR-
14. We could put all of the functionality for reflective invocation, 
etc., into one of these classes. Also, we could immediately support 
JSR-14 1.2 integration simply by execing (at least until we had a 
faster solution in place). Incidentally, we could also exec on OS X 
to immediately fix the JSR-14v1.0 integration problem on that 
platform. Oh, and users could invoke the old GJ compiler if they 
chose simply by specifying gjc.v6.Main as their compiler.

Alternatively we could provide a special interface that included a  
"compile" method to invoke. Then any compiler class specified 
would have to implement that interface. This compile method would 
take a source file and return some higher-level representation of 
the errors. That way, we'd pass the burden of parsing to each class 
(of course, new tools could just generate the error objects 
directly). The disadvantage of this approach is that tools which 
already generate errors to System.err with the expected syntax 
would be harder to integrate. Well, I suppose we could make our 
interface an abstract class and provide a parsing method for the 
expected syntax...

-- Eric


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

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

[DrJava] [ drjava-Bugs-595735 ] can't use JSR14 on OS X

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't use JSR14 on OS X

Initial Comment:
The JSR-14 compiler (either version) doesn't work with DrJava on 
OS X. When running that compiler on any source file, the following 
error is reported:

Error: try to access field com.sun.tools.javac.v8.JavaCompiler.syms 
from class edu.rice.cs.drjava.model.compiler.JSR14Compiler(no 
associated file)

We believe this is because the OS X JVM prepends the class path 
with its own tools.jar. JSR-14 redefines many of the classes in the 
standard javac compiler, but on OS X, the ordinary Java class files 
are seen first. When we call JSR-14 methods that don't exist in the 
ordinary class files, The JVM signals the error above. 

Note: this same functionality on OS X guarrantees that DrJava 
always has a 1.3 compiler available, and that the debugger is always 
available, but it bites us with JSR-14.

-- Eric


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

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

[DrJava] [ drjava-Bugs-595730 ] paren highlighting

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

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

Category: Definitions (source editor)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: paren highlighting

Initial Comment:
If you're after two closes in a row, with the 
corresponding region highlighted, and you delete the 
second close, the region of the close now before the 
cursor should be highlighted and isn't. (You get larger 
regions as you type successive closes; you should get 
smaller ones as you delete them.)

Also, if you turn the highlight source check box off, 
paren region highlighting often does not work on the line 
that was highlighted last.


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

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

[DrJava] [ drjava-Feature Requests-595182 ] Specify a built directory

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

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

Category: Compiler integration
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Specify a built directory

Initial Comment:
There should be a configurable option allowing a user
to specify the directory to put the compiled class
files (the equivalent of passing a "-d" argument to the
compiler).  Ideally, this would be done at a "project"
level, but we don't have support for projects yet (and
will probably implement it using ant instead).  This is
a good interim feature, since a user would only use it
if most of their classes went to the same place.

Note this would also make it easier for us to develop
DrJava in DrJava, since we could compile classes easily
without always having to use ant.

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

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

[DrJava] DrJava Stable Release

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

   The second stable release of DrJava, drjava-stable-20020814, is now 
available!  This release includes a significant number of bug fixes 
since the beta release on August 4th, including many which were 
discovered during the TeachJava workshop.  See the release notes on 
Sourceforge (by clicking on "drjava-stable-20020814" on the Files page) 
to see a full list of the changes.

Charlie