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