The problems with the interpreter that has been included since the last development release are much worse than I thought. Today, I realized that the for problem issue reported in [ 1954403 ] Pre-Increment/Pre-Decrement Throws Exception in For Loop is much worse than I initially thought.
It’s not only pre-increment/pre-Decrement, but also post-increment, post-decrement, assignment, add-and-assign, and subtract-and-assign. THERE IS ABSOLUTELY NO WAY TO WRITE A NORMAL FOR LOOP!
> for(int i=0;i<10;i++) System.out.println(i); 0 > for(int i=0;i<10;i++) System.out.println(i); 0 > for(int i=0;i<10;i+=1) System.out.println(i); 0 > for(int i=0;i<10;i=i+1) System.out.println(i); 0
This issue is so critical, it will kill DrJava. The problem with 1.6.0 Update 4 is bad, and it needs to be taken care of because it inconveniences users, but at least there is a simple work-around.
The problem with the for loop, and many of the other interpreter problems, however, will make most users abandon DrJava. Our user base will run away from DrJava. We need to deal with these problems before we make the next release.
If we can’t fix these bugs, I think we need to roll back to the old interpreter. It doesn’t do generics, but at least it does simple Java statements correctly! We need to know now which of the bugs we can fix within the next month.
It is embarrassing that we released a development version, and we weren’t aware of any of these problems. It’s even more embarrassing that the development release has been out there since April, and we haven’t realized how bad the problems were. What happened to our unit test coverage for DynamicJava? I assumed we had unit tests for it. How did we not notice that something as simple as a for loop does not work?
Why haven’t any of the bugs that have been on the tasks list since January been fixed? It’s almost ridiculous to call this blog posting “Problems with the New Interpreter”. The interpreter isn’t new, it’s half a year old! I’m terribly disappointed by all these problems and how they are not being handled. I have worked too hard on DrJava to see it fail because of sloppy code and lack of action. We have about a month before we should release the next beta, and the developer who created the new interpreter has been AWOL for the last two weeks.
It’s really pissing me off. I can’t release bug fixes since the version with my bug fixes and additional features is so horribly crippled by the buggy new interpreter.
As per Corky’s request at today’s JavaPLT group meeting, here is the list of interpreter bugs. The bugs are in the order of importance, as I perceive it.
I labeled those bugs that absolutely must be fixed before the next release as “CRITICAL”. If one of those bugs cannot be fixed in time, I think we should revert to the old interpreter and put the new interpreter into a branch, so we can merge it later, when the bugs have been taken care of.
The bugs labeled “IMPORTANT” are bad, but perhaps not bad enough to make us revert to the old interpreter, as long as the “CRITICAL” bugs have been fixed.
The bugs in the “WOULD BE NICE” section can be annoying or confusing, but I don’t think many people use them.
CRITICAL:
- [ 1954403 ] Pre-Increment/Pre-Decrement Throws Exception in For Loo
for loops don’t work at all! It’s not only pre-increment and pre-decrement, post-increment and post-decrement, assignment, add-and-assign and subtract-and-assign do not work either! This is horrible. - [ 1914486 ] length field of array types not supported in new interpreter
- [ 1914487 ] private constructors in classes are accessible
Not only private constructors are accessible, private and protected methods and fields are accessible as well! - [ 1986669 ] Case-Insensitivity Problem with Class Members
- [ 1992394 ] Interpreter does not support methods with varargs
- [ 1151966 ] Interactions pane doesn’t process nulls in varargs correctly
IMPORTANT:
- [ 1004730 ] NullPointerException when passing null paramter
- [ 995715 ] local methods, return value
- [ 1266716 ] array declaration in interface yields error
- [ 1585210 ] “Run Document’s Main Method” allows non-void return type
WOULD BE NICE IF FIXED BEFORE NEXT RELEASE:
- [ 992535 ] Inner enum declaration fails
- [ 994688 ] Incorrect DynamicJava error for inner class instantiation
- [ 1080869 ] Class.forName() doesn’t work in interactions pane
- [ 1239169 ] Reflection in Interactions
- [ 1953827 ] Invalid escape character causes error
Update: I checked the line counts for unit tests, the old interpreter had over over 9000 lines of test code, the new interpreter has only about 4500! The number of tests should increase over time, not decrease. Leveraging the old tests is crucial, especially in a task like replacing the old interpreter with the new interpreter. The old interpreter’s tests would have ensured that the new interpreter can do everything the old one did, and then some.
Update: I’m in the process of reverting the changes made by the developer of the new interpreter, just so we have a stable revision to release in case we need it. Now I’m noticing how much worse our test coverage got with his changes. In addition to cutting the interpreter tests in half, as mentioned above, he also deleted two test files, while he kept other test files but commented out the tests in them so as to not cause suspicion. Sneaky!
Deleted:
src/edu/rice/cs/drjava/model/repl/JavaDebugInterpreterTest.java src/edu/rice/cs/drjava/model/repl/newjvm/InterpreterJVMTest.java
Tests removed:
src/edu/rice/cs/drjava/model/debug/jpda/DebugTest.java - 9 tests removed src/edu/rice/cs/drjava/model/debug/jpda/DebugContextTest.java - 8 tests removed src/edu/rice/cs/drjava/model/GlobalModelOtherTest.java - 2 tests removed src/edu/rice/cs/drjava/model/repl/JavaInterpreterTest.java - 26 tests removed
The developer has now pledged to fix the bugs in the next couple of weeks, but I have created a branch and will try to revert to the old interpreter nonetheless. Better safe than sorry, for “Wer sich auf andere verlaesst, ist verlassen” (who relies on others ends up left alone).
