drjava-hackers — DrJava developers mailing list

[DrJava] [ drjava-Bugs-573767 ] No out/err to console on JUnit tests

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

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

Category: JUnit integration
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Charles Reis (csreis)
Summary: No out/err to console on JUnit tests

Initial Comment:
From Chris Haynes:

When code is run via the test button, standard and
error output doesn't show up on the console. This is a
real drag.

(Any System.err/System.out calls within a test are
currently being printed to the actual console rather
than DrJava's console.)



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

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

[DrJava] [ drjava-Bugs-573207 ] No System.err in Interactions

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

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

Category: Interactions
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Charles Reis (csreis)
Summary: No System.err in Interactions

Initial Comment:
From Chris Haynes:

The interactions window doesn't display standard err.
This is quite
unfortunate and should be easy to fix. Preferably it
would do so in
a distinct color, say orange, but should be the same as
in the console
window. Students should be encouraged to use System.err
but it's very 
confusing if they see System.out stuff in the
interactions window, but
not 
System.err.



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

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

[DrJava] [ drjava-Feature Requests-571812 ] Find/Replace keyboard shortcuts

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

Feature Requests item #571812, was opened at 2002-06-20 20:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=571812&group_id=44253

Category: User interface
Group: Small (< 1 pair-week)
Status: Open
Priority: 4
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Find/Replace keyboard shortcuts

Initial Comment:
Hitting ESC while the focus is on the Find field should
close the tab and return focus to the definitions
window.  Hitting CTRL+F should not only put the cursor
in the Find field, but should also select all text in
the Find field.  Hitting F3 should automatically run
Find Next, regardless of where the focus is.

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

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

[DrJava] [ drjava-Feature Requests-571805 ] Don't use indent logic on non-Java files

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

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

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't use indent logic on non-Java files

Initial Comment:
If a saved document does not have a ".java" extension,
DrJava should not use the indent logic on it.  This
would make it easy to open other files (eg. the
".drjava" config file) without starting another editor.
 Note that the indent logic should still be applied on
new files (without any filename).

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

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

[DrJava] [ drjava-Bugs-571702 ] Invalid configuration files crash DrJ

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

Bugs item #571702, was opened at 2002-06-20 11:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=571702&group_id=44253

Category: Config Framework
Group: Crashes
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher McGraw (cmcgraw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid configuration files crash DrJ

Initial Comment:
If a novice or absent-minded user inadvertantly
includes any illegally formatted values within their
configuration file, DrJ is unable to parse them into
their respective Option objects, so it throws an
IllegalArgumentException and crashes before loading the
GUI. This is a rather serious flaw, considering how
confusing such behavior may be to someone who doesn't
understand what might have gone wrong.

DrJ should probably recover from this trammel by
catching the exception, and then "throwing out" any
loaded config values and simply resetting to defaults.
After successfully loading, it could report that an
error had occurred in parsing the config file and even
inform the user of which option, along with its
malformed value, had been deemed invalid. 

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

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

[DrJava] [ drjava-Bugs-571699 ] paren matching breaks

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

Bugs item #571699, was opened at 2002-06-20 09:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=571699&group_id=44253

Category: Definitions (source editor)
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: paren matching breaks

Initial Comment:
Paren highlighting breaks when a series of {,},(,),[,]
are added to the middle of an acceptable file. When
these characters are deleted, the parens will not match
again until a properly placed brace is inserted.

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

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

[DrJava] [ drjava-Ease of use Issues-571058 ] Save Dialog Strings

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

Ease of use Issues item #571058, was opened at 2002-06-19 05:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=571058&group_id=44253

Category: Platform Independent
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: Save Dialog Strings

Initial Comment:
The message and title on the save-before-closing 
prompt dialog were reversed.  I swaped the 
parameters on the call and that fixed it.  I'll submit 
the changes once I have half an hour to run the 
commit tests.

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

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

[DrJava] Beta Release Announcement

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

   There is now a beta release of DrJava available from the SourceForge
site.  Please download it and use it as your primary copy, submitting
any bugs that you find.  We'll release a stable version based off of it
in a week or two, depending on the feedback we get from beta-testing.

   For development, ALL new features at this point MUST be enclosed in a
conditional block based on the CodeStatus.DEVELOPMENT flag.  Regular
commits (which set this flag to true) are fine, but the stable release
will have it set to false again, leaving any new features out.  At the
moment, only the integrated debugger is disabled based on this flag.

   Bug fixes are the only code that will not be in conditional blocks
until after the stable release.

   Let me know if you have any questions on how this process works...

Charlie

[DrJava] Support for Stable Release Process

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

   After the most recent commit, everyone will need to run "cvs update 
build-common.xml" in their edu/rice/cs directory, since this file has 
been updated to support the new stable release process.  Theo has also 
added a useful "compile-tstamp-gmt" target for the util code (to 
simplify the process of setting up a new build).

   In the new release process, we have a CodeStatus class with a boolean 
DEVELOPMENT constant.  Any features which are not ready to be included 
in a stable release for all mainstream users (eg. the debugger) MUST be 
surrounded in conditional blocks based on this constant:

if (CodeStatus.DEVELOPMENT) {
   // My new feature code
}

   Similarly, test cases for these new features will also need to be 
surrounded in conditional blocks, so that the tests will pass when the 
development features are disabled.

   The CodeStatus.java file should never need to be changed by hand-- 
like Version.java, it is modified by ant.  We now have "development" and 
"stable" targets that you can call from ant which set the constant 
appropriately.

   IMPORTANT:  Since our usual process has been producing 
development-quality builds, the "commit" target automatically calls the 
"development" target, setting CodeStatus.DEVELOPMENT to true.  This is 
fine for use in most cases.  When releasing a beta or stable version, 
however, the "commit-stable" target must be used, which sets the flag to 
false, disabling any new features and their corresponding tests.

----

   If you have any questions on this process, please let me know.  We're 
actually in a very good position to start a beta test after today's 
work, so I'll prepare a beta version shortly.

Charlie

[DrJava] Re: DrJava Stable Release Process

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

I am fully in favor of the proposed process.  I think occasional house-cleaning and testing sessions are a very good idea.  A lot of user annoyance can be avoided by a few narrowly-targetted fixes.

In particular, I would like to request that no "Stable" release be made until the obvious OS X scrollpane bug is fixed.  I haven't had a lot of time to devote to it recently, and it is a very stubborn bug, but I don't think we can release a version of DrJava that contains this bug and still call it finished.  Just my two cents.

--
Peter

[DrJava] DrJava Stable Release Process

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

   After some of the discussions we've been having about the release 
process, I'd like to suggest an approach to see if there's any feedback...

Some key goals and issues:
  - We periodically want a "stable," beta-tested milestone that we can 
point to as a release for users who don't want to deal with bugs in new 
features.

  - We want to keep releasing development builds frequently for users 
who want to keep up with new features.

  - We have the ability to create CVS branches for stable releases (with 
no intention of merging them back with the main branch), expressly for 
disabling features which aren't ready for mainstream users yet. 
However, we don't want to duplicate bug fixes between stable branches 
and the main branch.


   In order for "stable releases" to make any sense, we need to have a 
period of beta-testing before a stable release.  But since we don't want 
to duplicate bug fixes between branches, work during this period will 
need to be done on the main branch.  This leads me to reject the idea of 
branches altogether, since the beta version should not include any 
(unstable) features that the stable version won't.

   Instead, James Sasitorn has suggested using periods of "feature 
freeze," where all development is focused on bug fixes until the stable 
release.  (Perhaps if there is additional feature development underway 
already, the new features can be disabled in any beta/stable release.)


The process would be as follows:

  - Prepare for a beta release by disabling any features not ready for 
mainstream users.

  - Announce a beta release by posting a "drjava-beta-DATE-TIME" build 
to the "DrJava Stable Releases" category on SourceForge and posting a 
news item requesting all users to download and use the beta version, 
looking for bugs.  A "feature freeze" begins here.

  - For the next week, fix any bugs that come in.  If we have time to 
work on new features as well, leave them disabled in any commit.

  - About a week after the beta release, create a 
"drjava-stable-DATE-TIME" build in the "DrJava Stable Releases" category 
on SourceForge and announce for all users.

  - Re-enable any new features that weren't in the stable release, and 
post a traditional "drjava-DATE-TIME" build to the (now-renamed) "DrJava 
Development Releases" category.

  - Continue working on new features until some arbitrary time when we 
decide to prepare another beta release.



   This approach would not use any CVS branches at all.  It's also sort 
of subjective and arbirtrary for when we decide to do a stable release, 
but I guess that's ok.  We should also make it clear that even 
development releases are usually very stable, but that users can expect 
to occasionally find bugs there with newer features.  (This is the 
objective of full unit-testing, though of course it isn't perfect in 
practice.)

   Please let me know what you think.  If there aren't any objections or 
additional suggestions, I'll plan on starting this process in the next 
few days, since we are currently at a convenient point to start a beta 
release.

Charlie

[DrJava] Other Java Runtime Tools

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

This site has a listing of non-Java languages and scripting extensions that can interact with a JVM or compile to bytecodes.  DynamicJava is listed along with several other Java-syntax-like scripting languages.  In particular, BeanShell looks promising.  CVS commits have been made at least as recent as 3 weeks ago, and Sun has decided to include it in a future version of Forte/NetBeans.  Since DynamicJava appears to be a dead project, we might want to keep an eye out for other promising contenders. . . .

http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
http://www.beanshell.org/home.html

--
Peter

[DrJava] Testing Hosts

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

Are there any publicly-accessible OS X machines on the Rice 
network?  It would be nice to have a machine setup with a VNC 
server so that team members without direct access to OS X could 
perform remote build testing.  I'm not sure if this is possible 
behind the Rice firewall, but it might be worth investigating.   
A similar setup for Linux and/or Win32 would also be nice.  
Those of us at Rice already have Owlnet or CS Solaris access, 
which is probably sufficient.  This is probably a pipe dream, 
but I thought I should put the idea out there.

--
Peter

[DrJava] OS X Image Target

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

I recently posted a command-line method of creating Mac OS X dmg 
images that could be turned into an ant build target.  The 
process is at this link:

<http://sourceforge.net/tracker/?func=detail&atid=438938&aid=520124&group_id=
44253>

There is a more general issue in that the process described can 
only be run on OS X, since it relies on tools only available on 
that platform.  If there is a strong feeling against making 
platform-specific build targets, OS X packages could be made 
with raw gzip archives instead.  Perhaps both options should be 
available so that non-OS X team members could still make some 
kind of packaged release.  What is the general opinion on this?

--
Peter

[DrJava] [ drjava-Bugs-568593 ] Line-wrapping/Horiz. scrollbar

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

Bugs item #568593, was opened at 2002-06-13 11:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=568593&group_id=44253

Category: Definitions (source editor)
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher McGraw (cmcgraw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line-wrapping/Horiz. scrollbar

Initial Comment:
When loading a file, DrJava automatically wraps lines
that extend past the given width of the JTextPane (??)
on to the following line. DrJava is also able to
reevaluate its wrapping when the window is widened,
e.g. sufficiently widening the window may allow the
user to fit all of their previously line-wrapped text
on to a single line. However, when narrowing the
window, line wrap is not reevaluated, and a horizontal
scrollbar automatically appears. 

Perhaps the line-wrapping should never occur in the
first place, and the horizontal scrollbar should be
employed instead. The importance of this possibility is
highlighted by the most recent release's ability to
accommodate custom sized fonts (which will more than
likely send lines of text WAY off the side of the
screen). Line-wrapping over several successive lines
would be ugly and impractical in this case,
underscoring the need for a horizontal bar right when
the file is loaded.

I must confess that I haven't inspected all of the
relevant code concerning this bug yet, but it seems to
me that it must occur because one panel is contained
within another, and the scrollbars of the containing
panel kick in only when the window is being narrowed
because it doesn't resize the contained panel. Of
course, none of that will matter in our implementation
using horiz. scrollbars, because I believe the
contained panel will simply have its own scrollbar from
the start, or it will be automatically resized to the
necessary dimensions at which point it would rely on
the containing panel's scrollbars

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

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

[DrJava] [ drjava-Bugs-568587 ] Test command hangs

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

Bugs item #568587, was opened at 2002-06-13 11:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=568587&group_id=44253

Category: JUnit integration
Group: Crashes
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Test command hangs

Initial Comment:
In 6/12 release, the test command hangs DrJava if 
the class is not public.

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

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

[DrJava] [ drjava-Bugs-568245 ] anonymous class indentation

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

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

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

Initial Comment:
   addWindowListener(new WindowAdapter() {
         public void windowClosing(WindowEvent e) {
         dispose();

The last line should be indented again.

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

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

[DrJava] [ drjava-Bugs-568201 ] editor motion keys

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

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

Category: Definitions (source editor)
Group: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: editor motion keys

Initial Comment:
It would be nice if the editor, like a number of others,
supported emacs motion keys:
forwards ctrl-f
backwards ctrl-b
up ctrl-p (conflicts with print command, could do w/o the 
latter)
down ctrl-n
delete ctrl-d
beginning of line ctrl-a
end of line ctrl-e

Of course it would be great if key bindings could be 
customized, even in the .drjava file, but that's probably 
asking too much at this point.

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

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

[DrJava] [ drjava-Bugs-568195 ] indentation error still there

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

Bugs item #568195, was opened at 2002-06-12 15:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438935&aid=568195&group_id=44253

Category: Definitions (source editor)
Group: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Haynes (chaynes)
Assigned to: Nobody/Anonymous (nobody)
Summary: indentation error still there

Initial Comment:
Foo f = {
   bar
};
  baz;

baz shouldn't be indented.

This is with the 6/11 release, which was supposed to 
have fixed this.

PS I really appreciate the rapid response your team has 
made to by reports!


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

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

[DrJava] [ drjava-Feature Requests-568004 ] Specify Initial Working Directory

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

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

Category: Definitions (source editor)
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Specify Initial Working Directory

Initial Comment:
From Jean-Paul Roy:

Could you add a property (or menu ?) specifying the
default directory to open files when launching DrJava.
It starts in its own directory, and I'm obliged to
follow a long path to open my files.  On the Mac, I
have a cute little tool to enhance the usual "open
file" dialog within Mac apps, but it does not work with
DrJava, as you don't call Apple built-in dialogs.

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

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

Re: [DrJava] JSwat Integration + DrJava "Trust"

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

> I agree that the JSwat integration is not where it should be, 
> which is why it is disabled by default.  The fatal flaw is the 
> lack of user documentation which should explain that this 
> feature is currently for the adventurous only and that more 
> work on it is planned.  We currently have essentially no user 
> documentation framework, and that needs to change.  Translating 
> some of the French documentation might be a good place to start 
> (which has been one of the issues discussed in the group 
> meetings), but I think we need to include some sort of docs 
> directory in the repository that people can update as they 
> add/modify features.  I'm going to go out on a limb and suggest 
> LaTeX/LyX for the format, since we can then easily generate 
> HTML, PDF, or PS docs.  I'm probably going to start putting 
> together a framework soon, so send me any suggestions.

I agree that we need a public help repository, and CVS is a good 
place to store it.  I doubt that full LaTeX is necessary, 
though.  LaTeX has the edge if print is a primary destination 
medium, but it isn't very accessible for users outside of 
academia.  I suspect that HTML will be the primary medium in 
which the docs will be viewed, either on SourceForge, from the 
local user drive, or within Java Help.  Plus, there are numerous 
editors available, so I think there would be more potential 
contributors.  Some of the docs could also be repurposed for 
spicing up the JavaDocs, and direct HTML format would aid in 
this.  I admit that this is mainly just my personal preference, 
though.  I'd be happy to see any kind of documentation.

>> We shouldn't allow end users to see unhandled exceptions, 
>> especially such basic ones.   On the command line, there is no 
>> specific error
>> message, just a raw stack trace of the exceptions.
>
> I agree whole-heartedly.  Exceptions (especially 
> UnexpectedExceptions) should be caught at the top level and 
> presented to the user in some sort of alert, perhaps with 
> information on how to submit a bug report for it.

I've submitted this as an ease of use issue (#567848).

> The counter-argument to this is the release-early/release-often 
> philosophy in both XP and open source, but I think a balance 
> can be found.  One possibility is maintaining a both "stable" 
> and "development" packages on SourceForge-- most of what we've 
> been releasing would go in the "development" category, and we 
> would periodically refine, test (with our own hands), and 
> prepare a "stable" release for less adventurous users.  Just a 
> thought-- I'm sure there are other possibilities.

Something like that is what I had in mind.  There have been 
points where the code has been very stable and reliable, but not 
since the major projects of last semester were rolled in.  It 
seems like it's almost accidental when a particular release is 
mostly problem free, but the general rule is that you can't 
trust it 'til you've tried it first.  I think we owe it to our 
users to occasionally commit ourselves to one polished version 
with some kind of stamp of approval.

I still want DrJava to have a quick release schedule of minor 
updates, but maybe we need a major and minor version number, or 
perhaps three tiers.  That way we can keep track of the 
fine-grain CVS level but also let our users know when it's 
really worth downloading the new release.

> Other thoughts and suggestions?

I definitely don't want to move away from JUnit.  You're right - 
it has been extremely useful thus far, and I think it will grow 
in usefulness as DrJava becomes more complex.

I think that the move to a GUI-testing package has to be tied to 
a platform-specific build system.  Several of the bugs that I've 
fixed are Mac OS X-specific, and testing on any other platform 
would fail to find the problem.  This is one of the things I am 
most concerned about.  Java is really a write once, test 
everywhere platform.  With our current release system, we only 
know that the tests pass on one individual developer's 
workstation.  Other platforms, JVM versions, etc. could be 
utterly broken, but the release would still go forward.  At the 
very least, we should make sure that the tests pass on all of 
our "supported" platforms before we make a full release.

Once we have a platform-specific build system, we'll be free to 
move ahead with other improvements that make use of classes 
which may or may not be present on all systems.  For example, 
this might allow someone to build DrJava without debugger 
support on a workstation without JSwat.  This would require 
additional support in DrJava itself, but I think it would be 
worth the effort.

--
Peter

[DrJava] [ drjava-Ease of use Issues-567848 ] Visual "UnexpectedException" Handler

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

Ease of use Issues item #567848, was opened at 2002-06-12 00:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=460211&aid=567848&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: Visual "UnexpectedException" Handler

Initial Comment:
As of 20020612-0105, whenever an UnexpectedException is thrown, a raw stack trace is printed to standard output.  Since some platforms ignore standard output, this means that some errors are never reported to the user in any form.  Even when they can be seen, the messages are verbose and unhelpful for end users.

A visual indication of some kind could be used to report these errors to users in a more friendly fashion.  My suggestion would be to use a message dialog with a simple, generic error message.  The dialog would have a default button of OK and a second button which allows the user to save the stack trace to a file.  The dialog could also be enhanced with an expandable pane to display the stack trace within a text box, or perhaps with a mechanism to create a new email message containing the data.

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

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

Re: [DrJava] JSwat Integration + DrJava "Trust"

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

You bring up several very good points...

Peter Centgraf wrote:
> I recently enabled the JSwat integration in my copy of DrJava with the 
> properties file options.

I agree that the JSwat integration is not where it should be, which is 
why it is disabled by default.  The fatal flaw is the lack of user 
documentation which should explain that this feature is currently for 
the adventurous only and that more work on it is planned.  We currently 
have essentially no user documentation framework, and that needs to 
change.  Translating some of the French documentation might be a good 
place to start (which has been one of the issues discussed in the group 
meetings), but I think we need to include some sort of docs directory in 
the repository that people can update as they add/modify features.  I'm 
going to go out on a limb and suggest LaTeX/LyX for the format, since we 
can then easily generate HTML, PDF, or PS docs.  I'm probably going to 
start putting together a framework soon, so send me any suggestions.


> We shouldn't allow end users to see unhandled exceptions, especially 
> such basic ones.   On the command line, there is no specific error
> message, just a raw stack trace of the exceptions.

I agree whole-heartedly.  Exceptions (especially UnexpectedExceptions) 
should be caught at the top level and presented to the user in some sort 
of alert, perhaps with information on how to submit a bug report for it.


> I'd like to hear from the other developers and users of DrJava about 
> this issue.  Do you think the way we currently develop DrJava is 
> sufficient to ensure that we release a user-ready system?  Are there 
> ways to extend the unit-test framework to catch more unanticipated 
> problems, or do we need a new method of testing?  How valuable is it to 
> provide a more polished system, and is it worth taking some development 
> effort away from core features to achieve it?  Am I barking up the wrong 
> tree?

The counter-argument to this is the release-early/release-often 
philosophy in both XP and open source, but I think a balance can be 
found.  One possibility is maintaining a both "stable" and "development" 
packages on SourceForge-- most of what we've been releasing would go in 
the "development" category, and we would periodically refine, test (with 
our own hands), and prepare a "stable" release for less adventurous 
users.  Just a thought-- I'm sure there are other possibilities.

I agree that the unit tests sometimes give over-confidence as to the 
quality of a commit, but it's tough to really nail down.  One step in 
the right direction might be identifying a good JUnit compatible GUI 
testing framework (there are a few on SourceForge).  But testing it by 
hand is also important, because there are just some things that are too 
difficult to test correctly.  And frequent releases are actually good 
for this, since identified bugs are quickly resolved.  As long as we 
write tests that show each existing bug is fixed, we won't move 
backwards.  For what it's worth, I don't think moving away from JUnit is 
a good idea, because we already have so much invested in it and because 
it has actually been quite useful.

Other thoughts and suggestions?

Charlie

[DrJava] JSwat Integration + DrJava "Trust"

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

I recently enabled the JSwat integration in my copy of DrJava 
with the properties file options.  However, when I try to enable 
and then disable the debugger, I get FileNotFoundExceptions for 
~/.jswat/settings and ~/.jswat/breakpoints.  It's not hard to 
figure out what those files are supposed to be, but since there 
is no user documentation for DrJava, I would have to search out 
the details from outside sources.  There is also no visible 
indication in the app itself that there was a problem with the 
debugger or what the problem was.  The check mark is simply 
removed from the menu item as normal.  While the debugger is 
enabled, it is also possible to trigger IllegalStateExceptions 
by trying to Run Current Document or Toggle Breakpoint on a new, 
unsaved file.

We shouldn't allow end users to see unhandled exceptions, 
especially such basic ones.  On the command line, there is no 
specific error message, just a raw stack trace of the 
exceptions.  For Mac OS X users who double-click the jar file or 
run a .app package, there is no indication of an error 
whatsoever.  I don't know whether this is a "ease of use issue" 
or a bug.

<rant>

Perhaps we are being too dependent on our unit tests and not 
doing enough of the direct kind of beta testing that finds 
unexpected errors.  Small things like this make our work seem 
amateurish and unpolished, no matter how good the 
functionality.  Perhaps we should make the release process more 
structured and infrequent, adding more time for testing before a 
public release.  The current system allows changes to be 
released with scarcely hours of use and no formal testing.  
There have been several recent examples of released 
functionality being removed or rolled back due to major problems.

DrJava is getting bigger and more complex.  It's very close to 
becoming a one-stop lightweight IDE, with many of the key 
features necessary for regular development needs.  However, I'm 
not confident that it is mature enough to be trusted.  I think 
this will be a key consideration for our users, who are mainly 
hobbyists and college students who are not ready to fight with a 
flaky system.

I'd like to hear from the other developers and users of DrJava 
about this issue.  Do you think the way we currently develop 
DrJava is sufficient to ensure that we release a user-ready 
system?  Are there ways to extend the unit-test framework to 
catch more unanticipated problems, or do we need a new method of 
testing?  How valuable is it to provide a more polished system, 
and is it worth taking some development effort away from core 
features to achieve it?  Am I barking up the wrong tree?

</rant>

--
Peter

[DrJava] [ drjava-Refactorings-567635 ] Redo Debugger without JSwat?

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

Refactorings item #567635, was opened at 2002-06-11 21:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=451586&aid=567635&group_id=44253

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Charles Reis (csreis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redo Debugger without JSwat?

Initial Comment:
Most of the debugger functionality (currently hidden by
default, but enabled with "debugger.enabled" in config)
seems to be things directly supported by JPDA,
suggesting that using JSwat is not necessary.  We
aren't using any of JSwat's GUI elements or advanced
features (aside from the text console for experimenting
with it), and given the apparent buggy behavior in some
cases and large Jar file, it might be good to stop
using JSwat.  At the least, this will make setting up
DrJava for using the debugger easier.  (Only need
tools.jar on the classpath, rather than both tools.jar
and correct version of jswat.jar.)

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

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