Menu
▾
▴
drjava-hackers
|
From: Peter C. <cen...@ri...> - 2002-06-12 04:13:22
|
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 |
|
From: Charles R. <cr...@ri...> - 2002-06-12 05:08:35
|
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 |
|
From: Peter C. <cen...@ri...> - 2002-06-12 06:13:25
|
> 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 |
Thanks for helping keep SourceForge clean.
X