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