drjava-hackers — DrJava developers mailing list

[DrJava] [ drjava-Bugs-756859 ] Debugger unusually sluggish in new releases

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

Bugs item #756859, was opened at 2003-06-18 16:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=756859&group_id=44253

Category: Debugger
Group: Makes DrJ unstable
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Musicant (musicant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Debugger unusually sluggish in new releases

Initial Comment:
I am trying to run the new development releases 
drjava-20030613-1720.jar and drjava-20030617-2059.jar 
on my office machine, which is a 733 MHz Windows 98 
machine running JDK 1.4.1_03. When I select Debugger, 
Debug Mode from the menu bar at the top, DrJava is slow 
about bringing up the debugger pane (15 seconds). 
Running a small program with a breakpoint on the second 
line seems to hang indefinitely.

The last stable release (drjava-stable-20030313.jar) is 
sluggish but useable: 1 second to start the debugger 
window, and 14 seconds to reach the breakpoint on the 
second line of my program.

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

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

[DrJava] [ drjava-Bugs-756809 ] Unexplained NullPointerException

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

Bugs item #756809, was opened at 2003-06-18 14:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=756809&group_id=44253

Category: User interface
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Musicant (musicant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unexplained NullPointerException

Initial Comment:
I got the following uncaught exception only once from 
drjava-20030617-2059, with Windows XP running jdk 1.4.
1_03. I am unable to reproduce this problem, so I don't 
know how useful this bug report is. Nonetheless, here it 
is:

I started up DrJava, typed in a simple class, didn't save it 
(so the filename was still "Untitled"), and clicked Compile 
All. I got the following exception from DrJava:

java.lang.NullPointerException
        at sun.awt.windows.WInputMethod.
dispatchEvent(Unknown Source)
        at sun.awt.im.InputContext.
dispatchEvent(Unknown Source)
        at sun.awt.im.InputMethodContext.
dispatchEvent(Unknown Source)
        at java.awt.Component.
dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown 
Source)
        at java.awt.Component.dispatchEvent(Unknown 
Source)
        at java.awt.LightweightDispatcher.
retargetMouseEvent(Unknown
Source)
        at java.awt.LightweightDispatcher.
trackMouseEnterExit(Unknown
Source)
        at java.awt.LightweightDispatcher.
processMouseEvent(Unknown
Source)
        at java.awt.LightweightDispatcher.
dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown 
Source)
        at java.awt.Window.dispatchEventImpl(Unknown 
Source)
        at java.awt.Component.dispatchEvent(Unknown 
Source)
        at java.awt.EventQueue.dispatchEvent(Unknown 
Source)
        at java.awt.EventDispatchThread.
pumpOneEventForHierarchy(Unknown
Source)
        at java.awt.EventDispatchThread.
pumpEventsForHierarchy(Unknown
Source)
        at java.awt.EventDispatchThread.
pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.
pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown 
Source)

It appeared that DrJava continued to function well from 
here, though I will admit I saw this as an excuse to shut 
down DrJava and start over. I cannot seem to make this 
happen again, so... hopefully this info is useful.



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

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

[DrJava] [ drjava-Bugs-754654 ] RuntimeException when a large ArrayList is printed

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

Bugs item #754654, was opened at 2003-06-14 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=754654&group_id=44253

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: RuntimeException when a large ArrayList is printed

Initial Comment:
In trying to debug a program, I had DrJava print the 
contents of a very long ArrayList (8000+ elements) in 
the interactions pane and it threw a RuntimeException, 
and the Interactions pane is essentially unusable 
afterwords, so I can't continue debugging.  Every time I 
press a key in the Interactions window, the same 
exception is thrown, and the exception in DrJava box 
pops up twice to let me know.  Here's the stack trace:

javax.swing.text.StateInvariantError: infinite loop in 
formatting

	at 
javax.swing.text.FlowView$FlowStrategy.layout
(FlowView.java:404)

	at javax.swing.text.FlowView.layout
(FlowView.java:182)

	at javax.swing.text.BoxView.setSize
(BoxView.java:379)

	at javax.swing.text.BoxView.updateChildSizes
(BoxView.java:348)

	at javax.swing.text.BoxView.setSpanOnAxis
(BoxView.java:316)

	at javax.swing.text.BoxView.layout
(BoxView.java:683)

	at javax.swing.text.BoxView.setSize
(BoxView.java:379)

	at 
javax.swing.plaf.basic.BasicTextUI$RootView.setSize
(BasicTextUI.java:1598)

	at 
javax.swing.plaf.basic.BasicTextUI$RootView.paint
(BasicTextUI.java:1317)

	at 
javax.swing.plaf.basic.BasicTextUI.paintSafely
(BasicTextUI.java:635)

	at javax.swing.plaf.basic.BasicTextUI.paint
(BasicTextUI.java:769)

	at javax.swing.plaf.basic.BasicTextUI.update
(BasicTextUI.java:748)

	at javax.swing.JComponent.paintComponent
(JComponent.java:541)

	at javax.swing.JComponent.paint
(JComponent.java:808)

	at javax.swing.JComponent.paintChildren
(JComponent.java:647)

	at javax.swing.JComponent.paint
(JComponent.java:817)

	at javax.swing.JViewport.paint
(JViewport.java:707)

	at javax.swing.JComponent.paintChildren
(JComponent.java:647)

	at javax.swing.JComponent.paint
(JComponent.java:817)

	at 
javax.swing.JComponent.paintWithOffscreenBuffer
(JComponent.java:4771)

	at javax.swing.JComponent.paintDoubleBuffered
(JComponent.java:4724)

	at javax.swing.JComponent._paintImmediately
(JComponent.java:4668)

	at javax.swing.JComponent.paintImmediately
(JComponent.java:4477)

	at 
javax.swing.RepaintManager.paintDirtyRegions
(RepaintManager.java:410)

	at 
javax.swing.SystemEventQueueUtilities$ComponentWorkR
equest.run(SystemEventQueueUtilities.java:117)

	at java.awt.event.InvocationEvent.dispatch
(InvocationEvent.java:178)

	at java.awt.EventQueue.dispatchEvent
(EventQueue.java:448)

	at 
java.awt.EventDispatchThread.pumpOneEventForHierarch
y(EventDispatchThread.java:197)

	at 
java.awt.EventDispatchThread.pumpEventsForHierarchy
(EventDispatchThread.java:150)

	at java.awt.EventDispatchThread.pumpEvents
(EventDispatchThread.java:144)

	at java.awt.EventDispatchThread.pumpEvents
(EventDispatchThread.java:136)

	at java.awt.EventDispatchThread.run
(EventDispatchThread.java:99)



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

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

[DrJava] Development Release

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

   A new development release of DrJava is now available, including 
several significant bug fixes to the debugger and Javadoc support. 
Also, the JSR-14 v2.0 compiler from Sun is now supported, allowing 
developers to compile DrJava with JSR-14 v2.0 and users to write their 
own programs in DrJava with JSR-14 v2.0.

   Note that the Interactions Pre-processor has temporarily been 
disabled in this release, due to a bug (750605, where qualified class 
names break in the Interactions Pane).  This means that generics are not 
currently supported in the Interactions Pane.  This support will return 
in one of the next development releases.

   Please give this new build a try and let us know if you have any 
trouble with it!

Charlie

[DrJava] DrJava Plug-in for Eclipse

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

The first milestone release for the DrJava Plug-in for Eclipse is now 
available at http://drjava.org!  Eclipse is an open source IDE developed 
by IBM, and our new plug-in provides it with an Interactions Pane and a 
simplified user interface.  Future versions of our plug-in will 
integrate Eclipse's debugger with the Interactions Pane to allow users 
to interact with programs at a breakpoint.

For more information, follow the Eclipse Plug-in link on http://drjava.org.

Charlie Reis

[DrJava] [ drjava-Bugs-752204 ] Indent: Curly braces within parenthesis

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

Bugs item #752204, was opened at 2003-06-10 16:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=752204&group_id=44253

Category: Definitions (source editor)
Group: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: James Hsia (jhsia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Indent: Curly braces within parenthesis

Initial Comment:
Whenever an expression that uses curly braces is typed
within an enclosing set of parentheses (e.g. passing a
statically defined array to a method) and that
expression is not the final argument passed to the
method, then any following lines are indented too far
which is a problem. 

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

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

[DrJava] Workaround for Generic Arrays

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

One of the greatest frustrations of GJ/JSR14 generics is the inability 
to build new arrays of an appropriate type.  It is a simple matter to 
create a new generic collection, but the special nature of arrays 
requires runtime type information that is not available when 
implementing generics with erasure.

ArrayList<T> arrayList = new ArrayList<T>();   // Works fine.
T[] array = new T[5];                          // Problematic.

I just discovered that Java 1.3 includes reflection support for 
building correctly-typed arrays at runtime.  Using this support, it is 
possible to perform the command above, although in a roundabout, 
un-type-checked way.  This support could be very useful for designing 
clean generic interfaces in parts of DrJava which make use of arrays.  
Here's a trivial usage example:

import java.lang.reflect.*;

class RuntimeTyper {
   <T> T[] makeTypedArray(T thing, int size) {
     return (T[]) Array.newInstance(thing.getClass(), size);
   }
}

Also keep in mind the typed toArray method in the Collection interface:

Object[] toArray(Object[] a);

Using these two capabilities together, we can get statically type-safe 
arrays from generic Collections (assuming that the Collection is 
non-empty):

   <T> T[] getArray(Collection<T> stuff) {
     Iterator iter = stuff.iterator();
     if (iter.hasNext()) {
       T[] array = (T[]) Array.newInstance(iter.next().getClass(), 0);
       return stuff.toArray(array);
     }
     else {
       // TODO: Perhaps some clever person could figure out how to 
handle this case.
       throw new IllegalStateException("Cannot make typed array from 
empty Collection!");
     }
   }

--
Peter

[DrJava] [ drjava-Bugs-750605 ] Qualified classnames break in Interactions

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

Bugs item #750605, was opened at 2003-06-07 16:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=750605&group_id=44253

Category: Interactions
Group: Serious
Status: Open
Resolution: None
Priority: 8
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Qualified classnames break in Interactions

Initial Comment:
The Interactions Preprocessor appears to insert 
parentheses into qualified classnames, which causes them 
to be interpreted incorrectly.  For example, the input:

edu.rice.cs.drjava.DrJava

is translated to:

(((edu.rice).cs).drjava).DrJava

This results in an error ("Undefined class 'edu'"), since 
DynamicJava then treats each package name as a variable/
field.  This problem is especially apparent when trying to 
invoke a main method using the "java classname" 
shortcut.

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

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

[DrJava] [ drjava-Feature Requests-749045 ] FindBugs Integration

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

Feature Requests item #749045, was opened at 2003-06-04 13:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=749045&group_id=44253

Category: User interface
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: FindBugs Integration

Initial Comment:
I would like to see some integration of the excellent
FindBugs tool from the University of Maryland with
DrJava.  The two stories below describe two potential
levels of integration, for the short-term and
long-term, respectively.

Sort-Term Story:

A user is editing several documents in DrJava and
wishes to run FindBugs on the associated class files
before submitting their work.  They select "FindBugs"
from the Tools menu.  DrJava launches a new instance of
the FindBugs GUI, passing it the locations of the
classfiles associated with the current open documents
and the user's current classpath.  The user can then
use FindBugs as usual, referring back to the documents
in DrJava manually.

Longer-Term Story:

A user wishes to run the FindBugs filters on the
currently opened documents.  They select "FindBugs"
from the Tools menu.  DrJava uses the FindBugs patterns
with the current documents and classpath, displaying a
new tab with a progress bar a la the JUnit tab.  When
the analysis is complete, the pattern hits are
displayed in the tab with the same style of interaction
as errors from the compiler, JUnit, or Javadoc,
including the ability to jump to hit locations and edit
the source in question.

The FindBugs support could also be integrated with any
notion of projects which we might add to DrJava.

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

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

[DrJava] [ drjava-Refactorings-748445 ] Track Line Numbers in Document

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

Refactorings item #748445, was opened at 2003-06-03 15:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=451586&aid=748445&group_id=44253

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Track Line Numbers in Document

Initial Comment:
There are several parts of DrJava that need to know the
character offsets of each line within a document. 
Currently, CompilerErrorModel and the line number
display in MainFrame are the two most prominent
examples.  We should investigate whether maintaining an
internal collection of Positions would be more
efficient than constant searching for newlines.

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

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

[DrJava] [ drjava-Feature Requests-748389 ] Project Support

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

Feature Requests item #748389, was opened at 2003-06-03 14:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=748389&group_id=44253

Category: Other
Group: Medium (< 1 pair-month)
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Project Support

Initial Comment:
It would be nice to have some kind of lightweight
notion of a project within DrJava.  It might be
appropriate to use some kind of ant script to record
files and provide support for batch compiling, testing,
etc.  Obviously a lot of work will need to be done to
provide stories for this functionality and ensure that
it doesn't interfere with our current ease of use for
individual files.

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

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

[DrJava] [ drjava-Bugs-747819 ] Runtime exception occured on compile

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

Bugs item #747819, was opened at 2003-06-02 16:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=747819&group_id=44253

Category: Compiler integration
Group: Crashes
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Runtime exception occured on compile

Initial Comment:
I was working away on a project, and I got this error 
when I tried to compile:

java.lang.IllegalArgumentException: Couldn't find index 
for error CompilerError(file=G:\cvs\project3
\MathTest.java, line=106, col=8, msg=loc is already 
defined in term(java.lang.String))

	at 
edu.rice.cs.drjava.ui.CompilerErrorPanel$ErrorListPane._
getIndexForError(CompilerErrorPanel.java:465)

	at 
edu.rice.cs.drjava.ui.CompilerErrorPanel$ErrorListPane.s
electItem(CompilerErrorPanel.java:689)

	at 
edu.rice.cs.drjava.ui.CompilerErrorCaretListener.updateH
ighlight(CompilerErrorCaretListener.java:197)

	at 
edu.rice.cs.drjava.ui.CompilerErrorCaretListener.caretUp
date(CompilerErrorCaretListener.java:114)

	at 
javax.swing.text.JTextComponent.fireCaretUpdate
(JTextComponent.java:336)

	at 
javax.swing.text.JTextComponent$MutableCaretEvent.fir
e(JTextComponent.java:3099)

	at 
javax.swing.text.JTextComponent$MutableCaretEvent.m
ouseReleased(JTextComponent.java:3154)

	at 
java.awt.AWTEventMulticaster.mouseReleased
(AWTEventMulticaster.java:227)

	at 
java.awt.AWTEventMulticaster.mouseReleased
(AWTEventMulticaster.java:227)

	at 
java.awt.AWTEventMulticaster.mouseReleased
(AWTEventMulticaster.java:227)

	at 
java.awt.AWTEventMulticaster.mouseReleased
(AWTEventMulticaster.java:227)

	at java.awt.Component.processMouseEvent
(Component.java:5022)

	at java.awt.Component.processEvent
(Component.java:4819)

	at java.awt.Container.processEvent
(Container.java:1525)

	at java.awt.Component.dispatchEventImpl
(Component.java:3527)

	at java.awt.Container.dispatchEventImpl
(Container.java:1582)

	at java.awt.Component.dispatchEvent
(Component.java:3368)

	at 
java.awt.LightweightDispatcher.retargetMouseEvent
(Container.java:3359)

	at 
java.awt.LightweightDispatcher.processMouseEvent
(Container.java:3074)

	at 
java.awt.LightweightDispatcher.dispatchEvent
(Container.java:3004)

	at java.awt.Container.dispatchEventImpl
(Container.java:1568)

	at java.awt.Window.dispatchEventImpl
(Window.java:1586)

	at java.awt.Component.dispatchEvent
(Component.java:3368)

	at java.awt.EventQueue.dispatchEvent
(EventQueue.java:445)

	at 
java.awt.EventDispatchThread.pumpOneEventForHierarc
hy(EventDispatchThread.java:191)

	at 
java.awt.EventDispatchThread.pumpEventsForHierarchy
(EventDispatchThread.java:144)

	at java.awt.EventDispatchThread.pumpEvents
(EventDispatchThread.java:138)

	at java.awt.EventDispatchThread.pumpEvents
(EventDispatchThread.java:130)

	at java.awt.EventDispatchThread.run
(EventDispatchThread.java:98)

A subsequent compile (I didn't make any changes, just 
pushed OK on the error box and hit compile again) 
worked fine.

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

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

[DrJava] Re: [ drjava-Feature Requests-623272 ] allow lifting interactions into a test

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

Whoa! Great job, guys. I can't wait to try out this new functionality  
for writing new unit tests...

-- Eric


On Friday, May 30, 2003, at 05:40 PM, SourceForge.net wrote:

> Feature Requests item #623272, was opened at 2002-10-14 15:30
> Message generated for change (Comment added) made by nrhorowitz
> You can respond by visiting:
> https://sourceforge.net/tracker/ 
> ?func=detail&atid=438938&aid=623272&group_id=44253
>
> Category: Interactions
> Group: Medium (< 1 pair-month)
> Status: Open
> Priority: 7
> Submitted By: Eric E. Allen (eallen)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: allow lifting interactions into a test
>
> Initial Comment:
> Story:
>
>
>
> The user enters a series of commands to a fresh interactions
>
> window. The definitions pane is open to a file containing a public
>
> class extending TestCase. He then pushes a "make into test"
>
> button in the interactions pane, and the interactions history is
>
> lifted into a new JUnit test method in the TestCase class in the
>
> definitions pane. All import and package statements are
>
> reconciled with those at the top of the source file. All
>
> incompatibilities between DynamicJava and regular Java syntax
>
> are detected and reported (or fixed) before continuing. A dialog
>
> box appears asking the user to name the new test method.
>
>
>
> The user continues entering commands into interactions without
>
> resetting. He then hits the "make into test" button again. All
>
> interactions since the last time he hit the button are lifted into a
>
> new test method, again in the open TestCase class.
>
>
>
> If the currently open document does not contain a public class
>
> extending TestCase, a new document is created with a new
>
> extension of TestCase. The user is prompted to name the new
>
> class, and the new test method is inserted into it.
>
>
>
> It make be advisable to break this story up into a series of smaller
>
> ones.
>
>
>
> -- Eric
>
>
>
> ----------------------------------------------------------------------
>
>> Comment By: Neal Horowitz (nrhorowitz)
> Date: 2003-05-30 15:40
>
> Message:
> Logged In: YES
> user_id=697810
>
> What could be considered a first step in this is now
>
> committed.  There is now an action (available through the
>
> context menu in the interactions pane or through the tools
>
> menu) that will take the current input in the interactions
>
> pane and write it to the definitions pane at the current
>
> caret position.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/ 
> ?func=detail&atid=438938&aid=623272&group_id=44253

[DrJava] DrJava / System.in

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

  The drjava-20030529-2239 development release is now available on
SourceForge, providing support for reading input from System.in.  This has
been a frequently requested feature, so if you have any programs that read
from System.in, please try them out with this copy of DrJava to make sure
that they behave correctly!

  Other changes include a new context menu in the document list pane and
several bug fixes related to saving files.  You can download this release
from the "more download options" link on drjava.org or from the link
below:

http://sourceforge.net/project/showfiles.php?group_id=44253&release_id=162451

Charlie

[DrJava] [ drjava-Bugs-745714 ] Searches Repeat When Changing Direction

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

Bugs item #745714, was opened at 2003-05-29 14:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=745714&group_id=44253

Category: Definitions (source editor)
Group: Annoying
Status: Open
Resolution: None
Priority: 3
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Searches Repeat When Changing Direction

Initial Comment:
Story:

A user is searching for a particular string in their code.  They 
accidentally step past the item they want, so they toggle the "Search 
Backwards" checkbox and hit "Find Next".  Nothing appears to 
happen.  Hitting "Find Next" again has the expected effect, moving 
to the next search hit in the chosen direction.

Note:

The code to flip direction needs to check whether the current 
selection matches the current search string, and if so, move the 
cursor to the opposite side of the selected text.  What's happening 
now, I believe, is that the search is re-finding the text that is already 
selected.

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

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

[DrJava] [ drjava-Feature Requests-745668 ] JSR-14 v2.0 Support

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

Feature Requests item #745668, was opened at 2003-05-29 18:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=745668&group_id=44253

Category: Compiler integration
Group: Medium (< 1 pair-month)
Status: Open
Priority: 9
Submitted By: Charles Reis (csreis)
Assigned to: Charles Reis (csreis)
Summary: JSR-14 v2.0 Support

Initial Comment:
Sun has just released JSR-14 v2.0, and JSR-14 v1.3 is
no longer available from their Early Access web site.

We need to update DrJava to support this new version,
which includes not only updates to generics (including
experimental support for covariant subtyping), but new
language features like type enumerations, autoboxing,
static imports, and enhanced for loops.

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

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

[DrJava] Re: New JSR 14.

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

Jim Van Fleet wrote:
> Yeah, JSR 14 has become a 1.5 preview.  Suddenly, we're en vogue!
> 
> I'm here and ready to help you work on it.  It's an issue with our team,
> too.  (I'm working with Zoran on his compiler group.)
 >
> I'm hoping that it will be positive in at least one of these ways.  1)
> If it worked in DrJ, we could just use that as our coding platform.  2)
> The process might illuminate me on how we could plug this into Eclipse,
> which is what they are/have been using.

We should be able to get it to work with DrJava pretty soon (probably next 
week).  Eclipse is a very different can of worms, because they have 
incremental compilation.  I don't see Eclipse cooperating with JSR-14 until 
IBM actually makes an effort to support it.  Guess they'd better get 
started, if JDK 1.5 is scheduled for the end of this year.


> I'm taking notes already on what's going on.  Do you know anything about
> shell scripting?

I have a passing knowledge if you have any questions, but it sounds like 
you got the general idea of the scripts they included.


> I see one probably minor issue and a couple of major ones.  Note that this
> is only in my esitmation, I am not familiar enough with these parts of DrJ
> to think I'm an authority.
> 
> The script distributed with the files flat out won't work for OS X, as it
> assumes the presence of rt.jar instead of classes.jar and ui.jar (I
> think...)  That's the minor issue.

Actually, we won't be using their scripts at all-- we call their compiler 
programmatically, so it isn't an issue.


> The first major issue is that this new JSR-14 appears to depend on 1.4,
> potentially forcing us to choose between generics and 1.3 support.  I'll
> let you make the call.  What's happening is that the javac and java
> scripts are depending on an environment variable being set that indicates
> the root of a valid 1.4 distribution.  It doesn't check that that are, in
> fact, 1.4, it just checks that they exist.  (At least, from what I can
> tell with my extremely limited shell script knowledge.)  It does the same
> with the jsr-14 jar, but I figured that wasn't just a big deal-- we're
> already finding that in some way, it's just that the file name may have
> changed.

In fact, JSR-14 v1.0 requires JDK 1.3, JSR-14 v1.2 requires JDK 1.4.0 and 
JSR-14 v1.3 requires JDK 1.4.1.  I'm not surprised that JSR-14 v2.0 
requires JDK 1.4.1.  (Note that this is true regardless of the scripts.)

In the recent past, the only way to use generics in JDK 1.3 (eg. on Macs 
without Jaguar/1.4.1) is to find a copy of JSR-14 v1.0, or use GJ itself. 
DrJava can support those compilers, but we can't redistribute them (and Sun 
doesn't distribute old versions of JSR-14).  So technically, there has been 
no "legal" way for new users to use generics in JDK 1.3 unless they happen 
to have an old copy of JSR-14.

Our current job is to write a new adapter to support JSR-14 v2.0 while 
maintaining compatibility with all the old versions.  Someday, we'll drop 
support for JDK 1.3, but not yet.  :)


> The other major issue is that the alias for javac passes the new jsr-14
> jar to the java interpreter that's running javac as its boot class path.
> I'd imagine this is going to have to be done "by hand" in the code.
> Then, on top of that, I believe javac itself is given the generic
> collect.jar and rt.jar on its boot classpath.
> 
> Java invocation is a bit more straightforward, it's just
> 
> /bin/java -Xbootclasspath/p:${JSR14DISTR}/gjc-rt.jar
> 
> after the checks I've mentioned above.

This is going to be a headache.  Previous versions of JSR-14 haven't 
required changes to rt.jar or even collect.jar.  We'll have to be very 
aware of this in both the compiler adapter and the Interactions Pane, since 
classes compiled with JSR-14 v2.0 will need to have this new rt.jar for 
updated library classes.  (Note that the user might need to reset the 
Interactions Pane if he switches to JSR-14 v2.0 while DrJava is running...)

I think we can pull all of this off, but it will take a little work.  Neal 
and I are going to start experimenting with it this afternoon.

Thanks for your input, and I'm sure we can use your help.

Charlie

[DrJava] Re: New JSR 14.

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

   Wow, thanks for the heads-up.  Yes, we need to update DrJava to work 
with this new version (as painful as it probably will be)...  The 
problem is that Sun never distributes the old versions of JSR-14, so any 
new users wishing to use generics in DrJava are *currently* out of luck.

   As an interesting side note, JSR-14 v2.0 is also JSR-201, which 
includes enumerations, autoboxing, enhanced for loops, and static 
imports.  As much as I dread having to support four different versions 
of JSR-14 with different JVM versions, I'm looking forward to trying 
these new features out.  :)

Charlie


Jim Van Fleet wrote:
> There was a new JSR 14 released this past week, and the internals are
> totally different.  java and javac are now scripts, operating on a
> "util-looking" (gjc-rt.jar) jar file.
> 
> Are there any plans to update DrJava with this?   If so, how?  I haven't
> tried just throwing the new jar into the fire, as it were, because I don't
> think some of the functionality in that script would be reflected in just
> a jar invocation.
> 
> Jim
> 
> 
> 

[DrJava] [ drjava-Bugs-745557 ] Cannot debug fields of an outer class

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

Bugs item #745557, was opened at 2003-05-29 15:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=745557&group_id=44253

Category: Debugger
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot debug fields of an outer class

Initial Comment:
In the new interactive debugger, the user can access
fields and methods of a class by using "this.x" or
"this.foo()".  However, fields or methods of an outer
class are currently inaccessible.  (eg. "Foo.this.x"
doesn't work)

This is likely a result of the trick we are using to
interpret "this" in DynamicJava.  (We're simply
treating it as a variable we can redefine.)  We'll
probably have to use a more thorough approach to
actually define a "this" entity within the interpreter.

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

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

[DrJava] [ drjava-Feature Requests-745158 ] Auto-close Comments

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

Feature Requests item #745158, was opened at 2003-05-28 15:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=745158&group_id=44253

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto-close Comments

Initial Comment:
Story:

A user is writing the comments for a method (s)he has just defined.  
First comes the open comment tag, then enter.  DrJava recognizes 
this as the start of a comment and automatically inserts the close 
tag, leaving something like this:

[indent]/** 
[indent] * 
[indent] */

The cursor should be positioned at the end of the middle line, ready 
to accept the comment text.

Notes:

Right now we provide the first step, adding the indentation and first 
asterick, but this leaves the rest of the document in "commented 
out" state.  It would be cleaner to add the close tag immediately and 
preserve the state of the text following the comment.

We may want to detect whether there is a stranded "middle" of a 
comment for which the user is attempting to add an proper open 
tag, e.g.

[user adds "/**" tag here]
[indent] * 
[indent] */

In this situation, we may not want to immediately close off the tag.  
This is debatable, though.

Another issue is whether we should behave this way for ordinary 
multiline comments (starting with "/*") or just for documentation 
comments.  Consistency might be an advantage here, but this might 
also annoy users who are attempting to comment out a block of 
code.  Then again, java itself doesn't lend itself well to this style of 
block commenting, since another comment could prematurely close 
the whole block.  Given this situation, perhaps consistency with 
documentation comments is best.  Again, comments are welcome.

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

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

[DrJava] [ drjava-Bugs-742226 ] java.lang.StringIndexOutOfBounds on a tricky file

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

Bugs item #742226, was opened at 2003-05-23 02:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=742226&group_id=44253

Category: Definitions (source editor)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: java.lang.StringIndexOutOfBounds on a tricky file

Initial Comment:
In drjava drjava-20030520-1527.jar
The problem arises when you try to open or save a file
that contains something like this:
--cut here-->
#import java.util.*;
#import java.io.*;

class bug interface<--end cut

The bug only occurs if the file ends with one of the
keywords the language uses to define classnames (ie in
java: class and interface) and no extra character after it.

The problem comes from
drjava.model.definitions.DefinitionsDocument.java and
it's an issue with how the classnames are detected in
getNextTopLevelClassName(DefinitionsDocument.java:2496).

In fact, it's not much of an issue since it doesn't
happen regularly and even a simple change (adding space
to the end) enables you to save the file.

--EBW.
eri...@ep...

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

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

[DrJava] [ drjava-Feature Requests-741878 ] Javadoc options

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

Feature Requests item #741878, was opened at 2003-05-22 10:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=741878&group_id=44253

Category: Definitions (source editor)
Group: None
Status: Open
Priority: 4
Submitted By: Neal Horowitz (nrhorowitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Javadoc options

Initial Comment:
A user should be able to choose the various command-
line flags that are sent to javadoc, at the very least what 
access to give javadoc (public/private etc).  The simplest 
option that comes to mind is just to have an editable 
string in the preferences, but this could lead to 
unforseen problems (since a user could enter anything 
into such a field).

Alternately, the user could be given a more useful dialog 
when javadoc is requested.  Such a dialog would include 
access levels, whether or not to include source roots, 
and output directory, possibly with "browse" or some 
similar option that would then bring up the current 
JFileChooser.

This would be much more robust than the current 
interface, plus it would workaround JFileChooser's 
annoying requirement that you explicitly create new 
folders before choosing them as the output directory (if 
the user types the name in a text field, we can go ahead 
and create the directory).

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

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

[DrJava] [ drjava-Bugs-741312 ] problem with javadoc files

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

Bugs item #741312, was opened at 2003-05-21 14:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=741312&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: problem with javadoc files

Initial Comment:
In drjava-20030520-1527, when I press "JavaDoc" (or select "Create 
JavaDoc" from the "Tools" menu), I'm prompted to select a directory 
for storing JavaDoc files. I select the directory /Users/eallen/temp, 
Then the html browser pops up with the following error messages:

Could not load the specified URL: file:/Users/eallen/temp/allclasses-
no-frame.html

and 

Could not load the specified URL: file:/Users/eallen/temp/index-
all.html

Also, when the JavaDoc html browser is in focus, I lose all menus 
except for "DrJava".

I'm running Java 1.4.1_01-14 on OS 10.2.6.

This error exists in the previous development release as well. 

Well, perhaps I'm simply using DrJava incorrectly, but I can't tell 
because there's no documentation on JavaDoc functionality. :-)

-- Eric


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

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

[DrJava] [ drjava-Feature Requests-741308 ] Include "help" for javadoc

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

Feature Requests item #741308, was opened at 2003-05-21 13:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=741308&group_id=44253

Category: User interface
Group: None
Status: Open
Priority: 5
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include "help" for javadoc

Initial Comment:
In drjava-20030520-1527, Javadoc is supported, but there is no 
documentation included in the "Help" browser...

-- Eric



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

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

[DrJava] [ drjava-Bugs-741289 ] Cannot save prefs in Windows

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

Bugs item #741289, was opened at 2003-05-21 18:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=741289&group_id=44253

Category: Config Framework
Group: Serious
Status: Open
Resolution: None
Priority: 7
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot save prefs in Windows

Initial Comment:
An error message is displayed any time DrJava tries to 
save the config options in Windows (either in the 
Preferences window or when trying to quit).  The 
changes are not saved.


Could Not Save Changes
Could not save changes to your '.drjava' file
in your home directory.

java.io.IOException: Save failed: Could not rename temp 
file C:\Documents and Settings\creis\drjava5547.temp to 
C:\Documents and Settings\creis\.drjava


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

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