Menu
▾
▴
drjava-hackers — DrJava developers mailing list
You can subscribe to this list here.
| 2002 |
Jan
(17) |
Feb
(80) |
Mar
(56) |
Apr
(79) |
May
(9) |
Jun
(60) |
Jul
(29) |
Aug
(40) |
Sep
(23) |
Oct
(6) |
Nov
(25) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(17) |
Feb
(85) |
Mar
(22) |
Apr
(3) |
May
(18) |
Jun
(27) |
Jul
(38) |
Aug
(19) |
Sep
(15) |
Oct
(6) |
Nov
(2) |
Dec
(5) |
| 2004 |
Jan
(19) |
Feb
(26) |
Mar
(30) |
Apr
(29) |
May
(8) |
Jun
(28) |
Jul
(39) |
Aug
(17) |
Sep
(19) |
Oct
(12) |
Nov
(18) |
Dec
(9) |
| 2005 |
Jan
(5) |
Feb
(18) |
Mar
(4) |
Apr
(5) |
May
(9) |
Jun
(10) |
Jul
(15) |
Aug
(11) |
Sep
(6) |
Oct
(6) |
Nov
(11) |
Dec
(6) |
| 2006 |
Jan
(10) |
Feb
(27) |
Mar
(24) |
Apr
(39) |
May
(14) |
Jun
(14) |
Jul
(5) |
Aug
(15) |
Sep
(21) |
Oct
(25) |
Nov
(10) |
Dec
(6) |
| 2007 |
Jan
(19) |
Feb
(23) |
Mar
(10) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(8) |
Aug
(6) |
Sep
(10) |
Oct
(7) |
Nov
(4) |
Dec
(5) |
| 2008 |
Jan
(23) |
Feb
(13) |
Mar
(19) |
Apr
(11) |
May
(11) |
Jun
(10) |
Jul
(12) |
Aug
(19) |
Sep
(11) |
Oct
(4) |
Nov
(6) |
Dec
|
| 2009 |
Jan
(8) |
Feb
(15) |
Mar
(21) |
Apr
(12) |
May
(14) |
Jun
(9) |
Jul
(2) |
Aug
(17) |
Sep
(36) |
Oct
(31) |
Nov
(13) |
Dec
(13) |
| 2010 |
Jan
(24) |
Feb
(17) |
Mar
(32) |
Apr
(18) |
May
(9) |
Jun
(6) |
Jul
(11) |
Aug
(18) |
Sep
(7) |
Oct
(20) |
Nov
(5) |
Dec
(4) |
| 2011 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(3) |
Dec
|
| 2013 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2003-07-28 19:45:25
|
Bugs item #779111, was opened at 2003-07-28 12:35 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=779111&group_id=44253 Category: Debugger Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Running Unit Test in Non-Debug vs. Debug Mode Changes Bhvr. Initial Comment: DRJ: 20030724-2151 JDK: 1.4.1_02 Win2k Pro Consider the following code: public class Jones extends TestCase // implements WinsAgain { public void testStuff() { Thread cooper = new Thread() { public void run() { System.out.println("Compilers rock!"); } }; cooper.start(); while(cooper.isAlive()) { } System.out.println("Cooper is no longer running."); assertTrue(true); } } Clicking the "Test" button while not in debug mode produces the following output: -------------------------------------------------- Welcome to DrJava. Compilers rock! Cooper is no longer running. > --------------------------------------------------- Changing to the Test Output Tab: --------------------------------------------------- All tests completed successfully. --------------------------------------------------- Now, I click Reset. Now I click Debugger->Debug Mode I do nothing else (no brakepoints, nothing) I click Test: ------------------------------------------------- Welcome to DrJava. Compilers rock! > -------------------------------------------------- -------------------------------------------------- Testing in progress. Please wait... -------------------------------------------------- ... and testing never finshes... no exceptions are thrown. looking at the Threads tab of the debugger I see: --------------------------------------------------- JUnit Test Thread | RUNNING --------------------------------------------------- So it would seem that testing in debug vs non debug mode changes the result of the program, namely, does the thread cooper die? I don't think this is desired, I think this is a bug. If this *is* the desired result of executing in debug mode, it is non obvious that testing in debug mode has the potential of changing the result of a program in the mind of the user--it would seem to violate program correctness. And as a great Thread once told me, not preserving program correctness and meaning is a Bad Thing :). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=779111&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-28 17:04:48
|
Ease of use Issues item #779032, was opened at 2003-07-28 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460211&aid=779032&group_id=44253 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Breakpoints Reached by Non-Interactions Window Threads Initial Comment: Hi. I've noticed that breakpoints which are reached by threads other than the single thread that manages control flow for the interactions window are not respected and do not allow the user to pause execution and step. Is this by design? For instance, consider a breakpoint within a method baker() inside class Jones. If the interactions window creates an instance of Jones and invokes baker() the breakpoint is reached, execution pauses, and the user may step. However, if the interactions window creates a new thread Wiess and Weiss's run method creates an instance of Jones and invokes baker(), the breakpoint is not reached, execution does not pause, and the user may not step. I'm a printf debugger by heart, so I don't use breakpoints and such very often in other IDEs--so this may very well be standard operating procedure in general for a debugger, but I thought I would ask. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460211&aid=779032&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-26 15:58:45
|
Feature Requests item #777845, was opened at 2003-07-25 22:31 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=777845&group_id=44253 Category: Javadoc integration Group: Medium (< 1 pair-month) Status: Open Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Javadoc generic source files Initial Comment: Story: User has specified the JSR-14 compiler in DrJava and is writing a source file with generics. He opens the Javadoc section of the Preferences window and checks the "Allow generic types" checkbox. He can then choose Javadoc All or Javadoc Current to generate Javadoc HTML files for his generic source file. Notes: If the option is enabled, we'll have to use their selected JSR-14 compiler to generate Java source without generics (with the "-s" flag) into a temporary directory, and then run Javadoc over those files. The resulting Javadoc will not have generics. A much better alternative is to investigate the SinjDoc tool at the address below, which appears to include support for generics: http://cag.lcs.mit.edu/~cananian/Projects/GJ/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=777845&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-26 15:54:03
|
Feature Requests item #777834, was opened at 2003-07-25 21: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=777834&group_id=44253 Category: Debugger Group: Medium (< 1 pair-month) Status: Open Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Access private members in debugger Initial Comment: In the debug interpreters, we seem to be having trouble accessing some private/protected fields and methods which should be in scope. It's still unclear exactly which cases work and which don't, but we should make an effort to provide access to anything that would normally be accessible in the method itself. In the short term, we can simply react if we are denied access to *any* field/method in a debug interpreter, granting access to it by circumventing the accessibility system with reflection. (This is done with a technique shown in the PrivilegedAccessor class: http://groups.yahoo.com/group/junit/files/src/PrivilegedAccessor.java) In the long term, we should be more accurate and prevent access to private fields and methods that the user actually shouldn't have access to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=777834&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-26 11:49:54
|
Feature Requests item #777837, was opened at 2003-07-25 21:58 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=777837&group_id=44253 Category: Debugger Group: Medium (< 1 pair-month) Status: Open Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Automatic package/imports in debugger Initial Comment: Story: User opens a source file in a package and sets a breakpoint. He then calls a method in the Interactions Pane that hits the breakpoint, and the Interactions Pane switches to a debug interpreter for the breakpoint. Behind the scenes, DrJava places the new debug interpreter into the source file's package and imports all classes/packages which were imported at the top of the source file. Notes: The package part of this is easy, since we already have a method which can parse out a document's package. We don't have any logic to parse import statements yet, so that might be a little more work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=777837&group_id=44253 |
|
From: Charles R. <cr...@ri...> - 2003-07-24 22:15:07
|
A new stable version of DrJava, drjava-stable-20030724, has just been released! This version includes the major features developed this spring by the students of Rice's Comp 312 (Program Engineering) course, along with numerous bug fixes and usability improvements. The most notable changes include the ability to use the Interactions Pane in the scope of a suspended method call in the Debugger, the ability to generate Javadoc HTML from source files, the ability to read input from System.in, and the ability to use generic types in the Interactions Pane. Please download this version from http://drjava.org and use it as your primary copy of DrJava. We welcome any feedback you have on this release; please submit any suggestions or difficulties as feature requests and bug reports on our SourceForge site. Thanks! Charlie Reis |
|
From: SourceForge.net <no...@so...> - 2003-07-24 03:20:27
|
Bugs item #776693, was opened at 2003-07-24 03:20 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=776693&group_id=44253 Category: Other Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: Robert Cartwright (rcartwright) Assigned to: Nobody/Anonymous (nobody) Summary: Console I/O is not reset when the Interactions pane is reset Initial Comment: I ran two versions of an I/O library test consecutively. The console I/O for the first program was still there after I opened and compiled the second program. By the way, sourceforge clears all fields in a bug report if you follow the instructions to login. Bummer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=776693&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-23 15:17:52
|
Bugs item #776313, was opened at 2003-07-23 10:17 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=776313&group_id=44253 Category: Debugger Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: James Hsia (jhsia) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot debug while testing Initial Comment: When a breakpoint is hit in a test class, the user is unable to access fields or methods of the class. This happens because the junit uses its own classloader called junit.runner.TestCaseClassLoader to load the classes that are being tested. At a breakpoint, DynamicJava tries to get the values of fields and methods, but fails because it says the object that contains the fields or methods as members is not a declaring instance of the same class. This is likely because it is comparing the object's class to the class that was loaded by our StickyClassLoader. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=776313&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-23 15:17:43
|
Bugs item #776312, was opened at 2003-07-23 10:17 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=776312&group_id=44253 Category: Debugger Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: James Hsia (jhsia) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot debug while testing Initial Comment: When a breakpoint is hit in a test class, the user is unable to access fields or methods of the class. This happens because the junit uses its own classloader called junit.runner.TestCaseClassLoader to load the classes that are being tested. At a breakpoint, DynamicJava tries to get the values of fields and methods, but fails because it says the object that contains the fields or methods as members is not a declaring instance of the same class. This is likely because it is comparing the object to the class that was loaded by our StickyClassLoader. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=776312&group_id=44253 |
|
From: Charles R. <cr...@ri...> - 2003-07-22 14:49:26
|
The DrJava developers have completed a large number of significant bug fixes and usability improvements since drjava-beta-20030710, notably including a new user interface for the Javadoc feature. Given the magnitude of these changes, we feel it's important to provide a release candidate (drjava-beta-20030722) before making the next stable release available. This allows you to download and try out the new features to ensure they work correctly in your environment, and to submit any new bugs that you find. If no new issues are encountered, this will become the stable release in about 2 or 3 days. Please download this release from http://drjava.org and try it out! A list of the new changes can be found in the release notes: http://sourceforge.net/project/shownotes.php?release_id=173095 Thanks for your help with DrJava! Charlie Reis |
|
From: SourceForge.net <no...@so...> - 2003-07-22 14:44:23
|
Bugs item #775665, was opened at 2003-07-22 09: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=775665&group_id=44253 Category: User interface Group: Ugly Status: Open Resolution: None Priority: 4 Submitted By: James Hsia (jhsia) Assigned to: Nobody/Anonymous (nobody) Summary: Opening debugger panel moves split pane divider Initial Comment: After moving the divider between the interactions pane and the definitions pane, opening the debug panel will often cause the interactions pane to change size. This is distracting and looks unprofessional. The problem is likely that we replace the document split pane with a new split pane that has the old document split pane at the top and the debug panel in the bottom. We will have to figure out the right Swing calls to make sure the new split pane is just as big as the old one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=775665&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-21 11:08:46
|
Bugs item #774932, was opened at 2003-07-21 06:08 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=774932&group_id=44253 Category: User interface Group: None Status: Open Resolution: None Priority: 2 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Closing Debug Console Initial Comment: Closing the debug console with the window's close box attempts to exit the JVM. This causes an ExitNotAllowedException to be thrown. We should change the close window handler on the debug console to not call System.exit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=774932&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-21 09:44:16
|
Feature Requests item #774899, was opened at 2003-07-21 04:44 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=774899&group_id=44253 Category: User interface Group: Small (< 1 pair-week) Status: Open Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Un-"modify" after Undo Initial Comment: Story: A user opens a file and performs a modification. DrJava sets the document's "modified" flag. The user then regrets the change and uses "Undo" to remove it and return to a pristine state. DrJava notices that all changes have been undone and clears the "modified" flag. The user then closes the document without incident. Currently, when the user attempts to close the document, they are warned about non-existant modifications. This is annoying and can easily be avoided. Some editors go a step further and notice when a document is in the same state as the file on disk even if Undo was not used explicitly. I can't think of a way to check this without doing a full string comparison on every edit, which I think is unacceptably heavy-weight. If someone can think of a better way to do it, or can implement the comparison without sacrificing performance, please implement it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=774899&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-21 09:30:32
|
Bugs item #774896, was opened at 2003-07-21 04:30 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=774896&group_id=44253 Category: User interface Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Bad CLI Filename throws NullPointerException Initial Comment: Attempting to open a file at the command line which does not exist will throw a NullPointerException. This gets wrapped as an UnexpectedException in DrJava.java, but here's the original stack trace: java.lang.NullPointerException at javax.swing.filechooser.FileSystemView. getParentDirectory(FileSystemView.java:457) at javax.swing.JFileChooser. setCurrentDirectory(JFileChooser.java:537) at edu.rice.cs.drjava.ui.MainFrame. _setCurrentDirectory(MainFrame.java:3215) at edu.rice.cs.drjava.ui.MainFrame. _setCurrentDirectory(MainFrame.java:3229) at edu.rice.cs.drjava.ui.MainFrame. access$7800(MainFrame.java:93) at edu.rice.cs.drjava.ui.MainFrame$ModelListener. activeDocumentChanged(MainFrame.java:3760) at edu.rice.cs.drjava.model.SingleDisplayModel$1. notifyListener(SingleDisplayModel.java:502) ... I think we just need to add some additional safety checks for this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=774896&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-20 03:42:36
|
Bugs item #774444, was opened at 2003-07-19 22: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=774444&group_id=44253 Category: User interface Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Peter Centgraf (centgraf) Summary: Unpredictable "Null Keystroke" Behavior Initial Comment: Our current technique for building menu options with no default keystroke is to use a "null keystroke" (with constructor values set to zero) as the shortcut. However, it appears that several keys on standard USB keyboards will generate that keystroke when used with Java. I've observed this myself with Metal and Sun's 1.4. 2 on WinXP. "Print Screen" and "Pause" will do it on my current keyboard. This will trigger an unpredictable menu item, depending on quirks of how the menus are initialized. (I've seen it open the About menu in one instance and run the "New JUnit Test" command in another.) We should find some way to disable the null keystroke or check for it explicitly when building menu items. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=774444&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-18 16:44:15
|
Feature Requests item #773763, was opened at 2003-07-18 11:44 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=773763&group_id=44253 Category: Debugger Group: Medium (< 1 pair-month) Status: Open Priority: 5 Submitted By: James Hsia (jhsia) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor debugger Initial Comment: It is very difficult to determine which events (currThreadSsuspended, currThreadSet, threadLocationUpdated, etc.) are fired by which actions (breakpoint reached, changing the current thread, stepping, etc.) in the debugger. This makes it hard to change the behavior of events or of specific actions. It would be ideal if there were a clearer chain of methods called and events fired by each action. Also, the current thread in the debugger needs to always be in sync with the current debug interpreter. Right now, during stepping and resuming, the debug interpreter is removed and the next debug interpreter in line (or the default interpreter if there are no other debug interpreters) is added, but the current thread is not changed. We would like stepping to not touch the current thread or the current debug interpreter, while resuming should remove both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=773763&group_id=44253 |
|
From: Charles R. <cr...@ri...> - 2003-07-16 14:21:09
|
I committed some of Peter's changes to platform.jar and the platform-specific source trees last night, allowing us to use the platform's default web browser to view HTML files on Mac/Windows. To get these changes, you'll need to run "cvs update" in your "src" directory. (After compiling util/ and drjava/, you'll be able to view Javadoc HTML in the platform's browser on Mac/Windows.) Charlie |
|
From: SourceForge.net <no...@so...> - 2003-07-15 17:40:14
|
Bugs item #771762, was opened at 2003-07-15 17:40 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=771762&group_id=44253 Category: Debugger Group: Makes DrJ unstable Status: Open Resolution: None Priority: 7 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: Deadlock in debugger/listeners Initial Comment: There is currently a race condition which can cause deadlock in the debugger, because one thread has a lock on the debugger and is trying to notify listeners, and another thread has a lock on the EventNotifier and is trying to call a synchronized method on the debugger. (The debugger is synchronized for obvious threading reasons, and the EventNotifier is synchronized so that listeners cannot be added or removed while a notification is in progress.) This illustrates a much more serious problem. Any code in a listener that calls a synchronized method on an object can potentially cause deadlock, since a different thread could already have the lock on that object and could be attempting to notify listeners of an event (thus attempting to acquire the EventNotifier lock). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=771762&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-14 16:21:36
|
Bugs item #771040, was opened at 2003-07-14 11:21 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=771040&group_id=44253 Category: Debugger Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: James Hsia (jhsia) Assigned to: James Hsia (jhsia) Summary: Debugging local variables initialized to null Initial Comment: Anytime a local variable is initialized to null, the debugger reports its value as <not found> although it should be null. Also, trying to use the variable in the interactions pane in ways such as assigning to it will throw NullPointerExceptions. We have not yet determined if this bug is in our debugger, DynamicJava, or both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=771040&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-11 17:17:09
|
Bugs item #769764, was opened at 2003-07-11 12:17 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=769764&group_id=44253 Category: Debugger Group: Serious Status: Open Resolution: None Priority: 5 Submitted By: Yevgeniy Makarov (emakarov) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger does not stop on a breakpoint Initial Comment: I have a program consisting of two files. File Abcdefgh.java: public class Abcdefgh { public void f() { int i=0; } } File Abcdefghi.java: public class Abcdefghi { public static void main(String[] args) { new Abcdefgh().f(); } } When I set a breakpoint on the line "int i=0;" in Abcdefgh.java in the debugger mode and type "java Abcdefghi" in the interaction window, the program run through and does not stop at the breakpoint. I suspect that the problem is that the first 8 characters of the two file names (and classes) are the same. When I change Abcdefghi to Abcdefgzi the debugger does stop at the breakpoint. Thank you, Yevgeniy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=769764&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-10 21:45:40
|
Feature Requests item #769337, was opened at 2003-07-10 16:45 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=769337&group_id=44253 Category: Other Group: Small (< 1 pair-week) Status: Open Priority: 2 Submitted By: James Hsia (jhsia) Assigned to: Nobody/Anonymous (nobody) Summary: Find/Replace with Multi-line Text Initial Comment: It would be nice for the find/replace fields to support text that consists of multiple lines. One example that I ran into was taking an abstract file with some abstract methods in it ending in semicolons and copy-and-pasting the methods into a concrete subclass. I wanted to replace those particular semicolons with { } but this is currently not possible. We could at least process escape characters such as \n. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=769337&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-10 16:39:09
|
Feature Requests item #769176, was opened at 2003-07-10 08:29 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=769176&group_id=44253 Category: User interface Group: None Status: Open Priority: 3 Submitted By: Neal Horowitz (nrhorowitz) Assigned to: Nobody/Anonymous (nobody) Summary: source root variable in file options Initial Comment: It would be nice if we could reference the source root of the current class from the file option components. For example, I would love to specify that my javadoc should always go to $SRCROOT/doc, regardless of what files I'm trying to javadoc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=769176&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-10 16:17:19
|
Bugs item #769174, was opened at 2003-07-10 08:21 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=769174&group_id=44253 Category: Debugger Group: None Status: Open Resolution: None Priority: 6 Submitted By: Neal Horowitz (nrhorowitz) Assigned to: Nobody/Anonymous (nobody) Summary: cannot debug final local variables from inner class Initial Comment: simple example: public class Foo { public static void main(String[] args) { int x = 0; new Thread() { public void run() { System.out.println("x = " + x); System.out.println("I can't see x in the interactions pane!"); } }.start(); } } This is annoying, since we should be able to access x from the inner class, but we can't. Hopefully, we can find some way from JPDA to access x and alias it into the interactions pane. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=769174&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2003-07-10 06:38:59
|
Bugs item #768923, was opened at 2003-07-10 06:38 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=768923&group_id=44253 Category: Compiler integration Group: Serious Status: Open Resolution: None Priority: 8 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Run Main Method doesn't wait for reset Initial Comment: The new "Run Document's Main Method" feature doesn't wait until after the Interactions Pane finishes resetting before interpreting the "java Classname" command. Depending on the speed of the machine, this means that the main method will start to run before the Interactions Pane is reset, and it will be interrupted when the reset occurs. This is very important to fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=768923&group_id=44253 |
|
From: Charles R. <cr...@ri...> - 2003-07-10 06:28:22
|
The TeachJava 2003 workshop is currently underway at Rice University (http://teachjava.org), and we are actively receiving and responding to feedback from the workshop participants to improve DrJava. As a result, an updated beta release of DrJava, drjava-beta-20030710, is now available from http://drjava.org. This release includes many bug fixes and usability improvements, including type checking bugs in the Interactions Pane and several enhancements to the debugger. We will continue to receive feedback in TeachJava through the end of the week, with the goal of producing a high quality stable release next week. Please be sure to download and test this updated beta in your environment to ensure that no new problems have been introduced. Thanks for your help with DrJava! Charlie Reis |
25 messages has been excluded from this view by a project administrator.
