We found more user sites for DrJava and another review, but SourceForge’s shell is apparently down right now, so we cannot update the DrJava website.
The last week was still spent catching up from Ike. I got lucky, I got power back early, but until pretty much today, the area of Houston that I see on my bike commute to work had been without power. There are still lots of uprooted trees that need to be cleared, and the trash bags are piled high along the streets. Traffic lights seem to be working a bit better, and grocery stores are stocked again.
I was supposed to give a presentation right after Ike, but that day Rice was closed, and not only I was affected, so my talk got pushed back by a week. I finally gave it this Monday, on September 22, in the RAP seminar. It was titled Java Annotations for Invariant Specification and was about Java annotations in general, how I used them to specify and check program invariants, and how much easier that got once I had extended Java to support subtyping for annotations as well. The talk was generally well received, but many of the comments said I should have given a clear definition of what annotations are at the beginning, not interspersed throughout the lecture. I didn’t want to make it so syntax-heavy at the beginning, but I guess I was wrong. I also ran out of time towards the end.
After that, I spent the last two days configuring the JSR 308 prototype compiler on my Mac and my PC at home. It’s not as easy as it sounds, but I finally got it to work, except for the tests. Yesterday I also transferred the changes from xajavac that allow subtyping for annotations into the JSR 308 compiler. But that’s still a work in progress.
Java Annotations for Invariant Specification
Where: Rice University Computer Science Department, RAP Seminar
When: September 22, 2008
Java annotations allow programmers to attach metadata to programs. During normal execution, the annotations are ignored, but in contrast to comments in the source code, annotations can be manipulated programmatically at compile- or run-time.
In this talk, I provide a brief introduction to Java annotations and show how limited their use currently is. I then describe a framework for specifying program invariants using Java annotations, and how extending Java to support subtyping for annotations allows programmers to write the invariants in a succinct manner.
It’s hard to believe that two weeks have truly passed since I last wrote. That’s two weekends, four lectures and one lab I’ve given, a small conference, and one big storm.
On Friday, September 5, I talked about generics and wildcards in my COMP 202 lecture. In the end, I unfortunately had a problem describing lower-bound wildcards. I couldn’t show the contravariant relationship. I corrected that on Monday. I noticed that there’s a big difference between being able to use wildcards and being able to clearly explain them.
Right after the COMP 617 seminar, Walid, Hashim, Jun, Cherif, Angela and I left for Abilene, TX to attend the Middle Earth Programming Languages Seminar. Walid did most of the seven-hour drive in both directions, but I somehow ended up doing most of the navigating, even though I was sitting in the left third-row seat. That sometimes made it hard to hear. Next time, if I navigate, I’ll want to sit closer. I also had some trouble with my allergies and my contacts during the trip — my eyes were getting really dry towards the end of the trip, but all in all the trip was fun. On Friday night, we watched a production of “Moonlight and Magnolias” at Abilene Christian University, and it was simply amazing. That’s one of the reasons why “Gone With The Wind” is in the title of this post.
The trip, and returning just before midnight on Saturday, did take a bit of energy out of me, though, so I had a hard time to get my part of COMP 202 homework #1 graded. Fortunately, the grading went well, thanks to our TA. On Monday, I corrected my mistake about wildcards from Friday, and then started talking about generic lists and algorithms on them.
We also had a lab on Monday so we could help the students with the GUI side of the Hangman game. Our TA was there, but I was a little disappointed about his knowledge of the assignment and Java. Dr. Wong and I plan to get him more involved and ultimately responsible for teaching the labs (as it should be), but this will be difficult.
On Wednesday, we finished talking about lists, and then started using some operations, like getting the first, removing the first, removing the rest, and removing the last x elements of a list to discuss how expensive these operations were. I didn’t quite introduce big-oh notation yet, but we generalized the number of operations to lists of length n. We still had a bit of an argument about which operations should count, so our counts were usually n, 2n, 3n, etc. It was a good discussion. Sadly, the video camera ran out of battery on this day.
On Friday I wanted to formalize this and introduce big-oh notation fully, but on Friday and Monday classes were canceled because of hurricane Ike — the other reason why “Gone With The Wind” is in the title, but more about that later. That made us lose two lectures and got the schedule in a bit of trouble. Today, I moved the exam and homework assignments around a bit. The university ruled that no assignments should be due this week, so I had to move homework #2 to next Monday. But in order to keep lectures and assignments together, I had to move them anyway.
In class today, only half of the students were there; I assume the others evacuated and hope they will be back soon. We finished talking about big-oh notation, and we cleared up why the constant factor in counting didn’t matter.
These entire two week seem like a blur, though, thanks to hurricane Ike. Starting late last Wednesday. we pretty much knew that this would be a close one. I went out to buy some more supplies on Wednesday night already. Some time on Thursday, a notice went out that classes are cancelled on Friday. After work on Thursday and early on Friday, I prepared my apartment for the storm: I taped cardboard covered in plastic bags to my windows again, a ghetto replacement for plywood. I know it couldn’t protect the window, but it should keep shards of glass out and give me a few more minutes to save valuable items. Then came the big wait.
The wind started getting pretty bad around 11 PM on Friday, but I went to bed at 2 AM, around the time “the Eyke” (the eye of Ike, as one newscaster accidentally called it) made landfall just east of Galveston, as a strong category 2 hurricane, just a couple of miles short of category 3. I woke up again at 2:30 AM when my UPSes started beeping. I had lost power. I quickly saved and and copied some files, then shut everything down. It was incredibly dark.
I woke up several times between 4 AM and 7 AM, when either bigger branches hit my apartment walls and windows, or when it sounded like there was hail. The hail probably scared me the most, because one of the meteorologists had said hail might indicate that there is a tornado nearby. A couple of times I was close to grabbing some blankets and moving into my bathroom, but I ended up sleeping through the entire hurricane in my bed.
When it had stopped raining hard in the early afternoon, I went outside and surveyed the damage. My apartment was not damaged, but there were lots of trees turned over. Some had fallen against other apartments or on cars. The fences around my apartment complex were gone. The Braes Bayou was a raging stream. I had expected something like I had seen after hurricane Rita, but this was much, much worse. Rita was nothing against this. And my power was still off. Rita just made it flicker.
Fortunately, I got my power and water back relatively quickly. There were still about 2 million people as of this morning who are without power. Biking or driving through Houston feels strange, because just one street separates apparent normality from chaos without power, water, gas, traffic lights, ATMs — everything we take for granted. It will take weeks before all Houstonians have their utilities restored, and probably months until the scars Ike made have been undone.
Today we started our discussion of Java generics. I motivated generics by showing Friday’s source code, which used Object... p varargs, and where p[0] had to be an IListFactory and p[1] an IList. Confusing the indices or passing the wrong value would lead to a ClassCastException.
We then looked at how to make a Box<E>, a wrapper that could contain any kind of value, but you had to specify its type. Later we worked out on the board what a generic ILambda would look like, including an Equals example that compared two Integer values. Then we made another Equals<P> that could compare any two values of the same type, so we specified one of the type variables of ILambda<R,P>, but left the other one open.
The last thing I mentioned was that SpecialBox<Integer> was a subclass of Box<Integer> when SpecialBox<E> extends Box<E>, but I’ll have to revisit that again, because the important thing is that Box<Integer> is not a subtype of Box<Object> even though Integer is a subtype of Object.
We also ran into an interesting problem with boxing when we write Equals: p[0] and p[1] are Integers, so p[0]==p[1] does an identity comparison, not an integer equality test, so we had to do p[0].equals(p[1]), but that lead well to the exercise Equals<P>.
I also wasn’t sure about whether primitive types could be used in generics; I correctly said no, but I wasn’t sure, so I’ll reiterate that. I’m pretty happy with this lecture. We’ll see how well my students understood the concepts, because on Friday we’ll talk about upper and lower bounds and wildcards.
Today, we talked about higher-order functions, which also are also called lambdas and commands. Initially, I presented the code for Reverse and Append from last lecture again. Then I added other things that you can do to the mix, such as generating a string representation, adding numbers or dividing them. The latter is important, because division is not commutative. I asked the students what is different between these operations and what is the same.
We came to realize that, depending on whether they use forward or backward accumulation, they all follow the same structure. In forward accumulation, they start with an initial value, perform some kind of operation with the initial value and the first of the list, then recur into the rest, using the result of the operation as initial value for the next level of recursion. In backward accumulation, they start with an initial value that is passed all the way to the end of the list. Then, for the empty list, that initial value is returned, and on the way out of the recursion, for each non-empty list, an operation is performed with the first of the list and the return value of the recursion that just finished, and the result is returned to the next level outward.
I then showed this in a more mathematical way, using a binary function f(x, y), and how forward accumulation yields f(f(f(f(i, l1), l2), l3), l4) for forward accumulation and f(l1, f(l2, f(l3, f(l4, i)))) for backward accumulation.
Unfortunately, I had written out our sample list from left to right, beginning with the empty list, as “empty-1-2-3”, instead of “1, 2, 3”, and that caused me to confuse fold left and fold right.
Another small problem occurred during the discussion of lambdas, the way we implement these different operations. The lecture notes provided code for an Add lambda. In fold left and fold right, the lambdas are binary; however, Add could process an arbitrary number of parameters. It would even add zero or one numbers. I wanted this to be exactly two — I should have previewed the lecture notes better, beyond the point of checking what code is there, but also precisely what it does. Fortunately, the Cons lambda was binary.
After we had discussed lambdas and worked out the code for FoldL and FoldR, we talked about how to do Reverse and Append using fold left and fold right, respectively. We arrived at the interesting result that the operations for both algorithms are the same!
new ILambda() {
public Object apply(Object... params) {
return new NEList(params[0], ((IList)params[1]);
}
}
The two things that differ between Reverse and Append is that they fold in different directions, and that they use different initial values (empy list and the list to append, respectively).
I thought the material was interesting today, and my motivation and the general arc through the lecture was good, but it was marred by the two mistakes, mostly confusing fold left and fold right.
At our group meeting today, we discussed the delays I had been seeing when Find All results were open and being updated, and I pasted text. A profiling session showed that a large percentage of the time was spent constructing the tool tips for the items in the RegionTreePanel. I don’t quite know why this was never an issue before, perhaps we simply didn’t update them.
The implementation was admittedly rather dumb, though, and created all tool tips at the time an item was inserted into the tree, even if the the tool tip was never displayed. I made the generation of the tool tips lazy by replacing the strings with thunks. Unfortunately, it’s impossible to subclass String in Java as it is final, but fortunately Swing was flexible enough to accept any object as property, as well as allowing me to override both setToolTipText() and getToolTipText().
I think this is actually a valuable addition that could be part of a future version of Swing, so I’d like to make the required changes easily available.
Today I finally got the camera set up correctly, I talked some more about the encapsulation issues that came up in the lab, I used index cards for some role-playing for the word list algorithms, and we talked about list algorithms.
I think the role-playing went well, although next time I should perhaps let the students do all of it. This time, I was the “visitor”, so a lot of what was going on was decided by me. On the other hand, this allowed me to mix the role-playing exercise with telling what the algorithms did.
For the list algorithms, we talked about reversing and appending. For appending, I could not find an algorithm that required a helper; my algorithm didn’t need a helper, but it wasn’t tail-recursive. We briefly talked about tail-recursion optimization.
In general, I’m quite happy with today’s lecture, although the video showed that I do have quite a few “uh”s as speech disfluencies, and that I could vary my pitch more. I still couldn’t get into the lab using my ID card, but I’ll check again on my way home.
Using index cards and role-playing to teach the visitor design pattern in lecture 2.
In lab 1, we went over the general design of the word list and the body part list. We discussed the need for a state pattern so the objects can change behavior yet remain the same class. Then I let the students recreate the code from the UML diagrams.
Besides some questions that had to do with getting “back into Java programming”, there was an interesting question about encapsulation, whether the visible and invisible states should be implemented as anonymous inner classes. I recommended that EmptyWord and NEWord be nested classes of the concrete word factory, and that AWordState, the visible state and the invisible state be nested inside NEWord, but I hadn’t considered implementing the latter two as anonymous inner classes. When I did that on the projector, it turned out that the visible state was an anonymous inner class defined inside toggleState() of the anonymous inner class for the invisible state. That was interesting, but perhaps made things more complicated.
I didn’t talk much about the algorithms run on word list and body part, so I ended up being a bit worried that not everyone knew what to do. I decided to revisit the encapsulation issue and the algorithms.
As everyone was leaving, there was a question about static as it applies to nested/inner classes. It took a little bit of effort, but I think I was able to explain how static nested classes do not have a reference to the enclosing class’ this, while non-static inner classes do, although I could not come up with a really compelling reason why non-static inner classes cannot have static members, except that static would not convey any advantage, because it could not be called in a static context anyway, but that would not have prevented Sun from just ignoring the static modifier.
I also found out that I’ll have a TA this semester, and I’m already very grateful for that already.
This doesn’t fit with anything really except that I’m teaching a college course this semester, but I found this discussion on Ask Metafilter quite interesting: If I want to drop into college courses, should I ask the professor for permission or should I just sit in?.
I’m sure my view has been expressed as a blend of the various responses. If the course cap has been reached, sorry, auditors need to get in line. If it hasn’t, and the presence of people auditing the course has no negative consequences for the registered students, I’d be happy to let them stay. I wouldn’t grade their assignments and exams, though, and I would prefer registered students during office hours and in-class discussion. I wouldn’t stay late to answer an auditor’s question; I would, for a registered student.
If someone were to “sneak into” my course, I’d be feeling a mixture of things: I’d be flattered that someone wants to hear what I have to say, just like with every student. I’d be irritated by the person not asking for my permission or following official protocol. And finally, and this would probably be the overwhelming feeling, I’d be confused why it didn’t occur to the person to ask.
In the end, I’d probably kick a person who “sneaked in” out of the class. Even if I give something away freely and with joy, taking it behind my back is stealing.
The first lecture went well, even though I initially had problems with the projectors. I couldn’t get my notebook hooked up, so I used the podium PC. I also did not yet have card access to get into Symonds 1, but I could not set up early anyway because there was a class in the lab. My time is sandwiched between two other classes, so I really can’t start much before 10 AM and need to be out by 11 AM.
We went over the general information. Here I should have mentioned that the students can anonymously complain to Dr. Wong if they have a problem with me.
We did a quick review of IList and LRStruct and the design patterns involved. Then we already started with the lab material, talking about how to set up words. Composite, state and visitor with three cases came up. We will continue that in class.
On Friday, we might talk about the games they did at the end of COMP 201.
After a summer of waiting, I failed to consciously register one of the most anticipated things: the number of students. I think there were six or seven.
Also, I’m terribly disappointed by the clumsy interface of my video camera. I failed to record my first lecture on video.
It’s 9 AM now, and a new school year has begun. I don’t think I have been this nervous in a while.
But there’s a reason for that: In just an hour, I will be delivering the first lecture of the first course that I am teaching by myself, COMP 202 – Principles of Object-Oriented Programming II.
I’ve re-worked and re-ordered some of the past lectures, switched out a few assignments, and added a new one, Hangman Refactored. It uses the Janus principle and fits in really well after the Programming for Change lecture and the Temperature Calculator assignment. At least that’s what I think. We’ll see how it goes.
On Saturday, I went to a wonderful workshop that the School of Engineering set up for TAs. I was on their list because this year I get paid by the School of Engineering. The discussion of different learning styles prompted me to ask the students to fill out a Learning Styles Questionnaire.
During the last three or four days, I also improved the external process facility of DrJava a bit. Clearer error messages are now printed to the external process panes, there are ${and}, ${or}, ${not} and ${neq} (not equal) properties, and simple search-and-replace can be done using the ${replace.string;text="...";old="...";new="..."} property.
I then approached the NextGen and xajavac compiler addons for DrJava again. Fortunately, Dan had told me about javac argfiles, which elegantly solve the long-command-line problem. However, I discovered that some problems, like keeping together file names with spaces in them, reappear when printing to text files, even though I had solved them for the command line. I got around that by adding quoting options for file properties.
Now we have two working DrJava Addons (“djapps”) that integrate NextGen and xajavac into DrJava.
Okay now, I’m going to get ready for COMP 202. I hope my Rice ID card will finally let me into the room. Wish me luck.
I fixed one issue that had come up again: Competing modal dialogs. For some reason that I’ve already forgotten, we couldn’t use real modal dialogs that come in the form of Dialog or JDialog, so we just used a JFrame and listeners, and stole the focus back whenever someone took it from us. It worked for a while, because DrJava rarely used windows except for the main window.
In the last couple of years, though, we have added more and more windows: The predictive input dialogs to help you search or find Javadoc pages, the error dialog to collect and better display error messages while making them appear less critical, and now even the bottom panes and the debugger can be detached.
I handled most of this by creating a cooperative first-come-first-serve scheme of being modal. Every window that was trying to be modal, asked for modal status, but only one could have it. I considered moving making windows modal that were initially denied modal status, but left it there.
However, there were still other windows that could modally pop up, and those were real modal dialogs out of my control. In his bug report, [ 2040862 ] Modal dialog flicker: Project Properties/Increase Heap, Dan had one of my pseudo-modal dialogs (Project Properties) compete with a real modal dialog (Increase Heap).
Now I check whether the opposite window, the one that stole our focus, is a real modal dialog. If that is the case, we concede modalness. However, we install a listener that will make us modal again when the real modal dialog has been closed.
I have tried to simulate the problem with two windows competing, but I never quite succeeded, so I hope Dan or someone else can reproduce the problem and confirm that the issue has been fixed.
Shifting gears: I have been thinking and working a lot on the COMP 202 lecture notes, and website in general. I am taking over most of what was there from the previous year, but I am making a few changes. For example, I have decided to take more time for a few of the more difficult topics. I have also replaced two unpopular assignments with two assignments of mine, and I have replaced another assignment with one that I am more familiar with. I hope to maintain the level of teaching in general, but I also have to make sure I don’t completely overload myself. Better a little bit less but well done, than more with lots of confusion.
One thing I have to confess here, though: Please, please, no one edit HTML pages with Microsoft Word. Or some other very high-level editors. It pains me. I still edit HTML with emacs, and seeing all the superfluous tags hurts my eyes. Sometimes there is a separate tag around every letter of a word.
Just to do:
I guess the previous students never looked at the HTML source (why should they have?), so I’m not surprised there were no complaints from them. But honestly, the computers rendering the HTML should have thrown up.
End rant.
For the last couple of days I have been contemplating buying another fire-proof security file. I currently have two Sentry KS-4100 files.
I keep a lot of records: Some are important, like identification documents for three countries, my last will and testament, lease agreements, insurance policies, deeds of ownership, computer backups, and, yes, even tax records. Others hopefully aren’t so important: Receipts for many of the items I have purchased. My credit card has a nice benefit that extends the manufacturer’s warranty by up to a year, and to claim that benefit, I need the receipt. Also, in case of a disaster that destroys my property, my renters insurance will want to examine the receipts so I can be reimbursed for the purchase or replacement costs, not just what the lost items were worth at the time.
Unfortunately, I’m running out of room for these receipts. While looking at buying another KS-4100, I more closely inspected its UL-72 certification. This particular Sentry file is manufactured to keep the interior at or below 350°F (177°C) for a fire that rages at 1550°F (855°C) for half an hour, which is apparently typical for an apartment fire.
As we all know, paper burns at 451°F (233°C) and it singes a bit sooner, at about 405°F (207°C), so keeping the interior of the file at or below 350°F keeps paper safe. Sentry also states that “CDs, DVDs, USB drives and memory sticks” are protected.
CDs and DVDs are mostly made of polycarbonate, with a melting point 513°F (267°C); jewel cases are mostly polystyrene that melts at 464°F (240°C), so CDs, DVDs and their cases are protected. I didn’t check the material of memory sticks and USB drives, although I’m a little worried about my portable hard drives now.
However, I also keep credit cards and ID cards in there, and they are usually made of polyvinyl chloride (PVC) (@I have since been corrected that credit cards are usually produced from polyvinyl chloride acetate, or PVCA, but I haven’t found the melting point of that yet.@), (@Apparently, the properties of PVCA can vary a lot, but one low figure that was provided to me was 257°F (125°C), which is still too low to be protected in the KS-4100 security file; PVCA cards would probably be safe in the expensive Sentry 6720 media file mentioned below.@), and I organize the receipts in nice colorful transparent polypropylene (PP) draw-string envelopes. PVC products, and therefore nearly all ID and credit cards, melt at a mere 176°F (80°F), and my PP envelopes melt at 338°F (170°F), just below the temperature the safe could reach while working as certified.
I’m really experiencing mixed up feelings right now, and I am considering switching to paper envelopes for organization, but the PP envelopes are so much more resilient and practical, and the temperature difference from 338°F to 350°F isn’t that great. That’s perhaps a risk I’m willing to take.
With IDs and credit cards, however, that’s a completely different matter. I’m fairly certain that in an apartment fire, the inside of the safe could easily reach 176°F and melt my passports, my international driver’s licenses and ID cards, and my credit cards (oh shucks, I’ll just get new ones, Washington Mutual willing, but that’s another rant for another hour).
I could get a data-storage security file like the Sentry 6720, which keeps the interior at or below 125°F (52°C). Apparently that’s good enough for floppy disks, and assumeably for hard drives as well, but unless I’m mistaken, it’s still too hot for credit and ID cards! And more importantly, it retails more than ten times the cost of the KS-4100.
How do protect your documents? Am I paranoid? Am I a “filing rat”, and you simply don’t have documents to protect? Please send me your ideas, if you like.
Today, Rice, UTH, and many other places in Houston were closed in preparation of the tropical storm Edouard. This was the first storm since Rita that was expected to hit the Houston area directly, although it never reached the sustained winds speeds of a hurricane.
It remained a tropical storm, not a category 1 hurricane, with sustained wind speeds of about 65 mph. A hurricane has sustained wind speeds of 75 mph or more, and Rita made landfall with winds almost twice as fast, at 115 mph. Edouard also veered to the East and hit the coast near High Island, Texas, not in Galveston.
Tropical Storm Edouard Landfall 2008-08-05
Overall, this storm was far less dangerous than predicted. Today was just a rainy day, and in fact not even the worst, even when compared to regular thunderstorms. There was a lot of media attention, and perhaps more caution than necessary, but that’s still a good thing. I got the impression that feelings of preparedness and control permeated the public, I did not get a sense of panic (except from some people on the MyFoxHouston.com chat who lived in Pasadena, feared a storm surge and had never learned to swim). It’s definitely better that people over-prepared for this storm and now have supplies that they didn’t need. But it’s still early in the hurricane season, so this “storm drill” may have been useful.
I haven’t written much in the past few days. I spent most of my time reworking the lecture notes for COMP 202, the course I’ll be teaching next semester.
I just upgraded the blog software to WordPress 2.6. Fortunately, this time the upgrade was much easier than the last time, and I didn’t have to mess with the email and print features separately. Everything seems to be working fine, and I’m keeping my fingers crossed.
With my Google Alert set for “DrJava”, I was notified about another website that mentions DrJava. It’s a blog post about the Alice summer camp. Here’s an excerpt:
The Alice Summer camps concluded last week. Starting from this week, we have the Java, Robotics and Graphics summer camps for High School children. The students who attend this Robotics summer camp are those who attended the Alice summer camp last year.
Well what do I say? I have enjoyed this week a lot. Students are taught Java on a very interactive IDE called Dr.Java. Also they are taught Java concepts using “Picturesâ€. In the sense, they have to write programs to modify pictures. “For†loop is taught in context of producing a mirror image of a picture, “If†loops are taught in the context of reducing the “red eye†effect in an image. I feel this is the best approach to teach children programming because they are excited working with pictures. So they have both fun and learning. However since it is just one week of Java, it is not much that they can do but definitely a good starting point to encourage them in the field of computer science.
We also got a response to a comment I left:
@Mathias Ricken:
I am very glad that you took the time to drop in a comment. Dr. Java was very user-friendly and easy to use by High School children. We have not had any problems till now. Kudos to the Dr. Java team of developers.
Thanks for the offer to help. I will surely get in touch with you if we need any help in the future.
I’m always happy when instructors choose DrJava, the best little IDE I know.
This past week was a bit chaotic. Fortunately, the problems about the new interpreter that I had bemoaned in the last posting are going away at a fast pace. Dan really dug into his work on DrJava again, so I’m not worried that we’ll still be plagued by embarrassing bugs in the Interactions Pane anymore by the time we make the next release.
There were also three problems with unintended commits to the trunk that should have gone into a branch. I reverted one of them immediately, but against my gut feeling, the consensus about the other commits was that we don’t revert but instead try to fix it. We’re making progress, but I still have an uneasy feeling. In the case of an unintended large commit, the best thing to do, in my opinion, is always a quick revert. Now, five days later, it would of course be a lot of work to backtrack to the point where the unintended commit was made, and then redo all the changes that were intended, but I have this lingering feeling that, while we’re probably running very close to our intended path, we may not actually be on it.
Out of the three problems, at least one of them seems to have gone away, at least when I run it on Windows in a VM on my MacBook. When I get home from the office, I’ll re-run the tests on a real Windows machine.
There was also a very strange problem with dozens of reported RejectedExecutionExceptions. Corky managed to find out that this was a bug known to Sun. I’m still not sure if it’s good to leave our code in a state where these exceptions can occur, even though they are not our fault. Before the unintended commits, these problems did not occur. I am going with the group consensus, though, and will try to not worry too much.
I have also begun to update the documentation for DrJava, in preparation of the new release. I don’t exactly know what other developers should add to the documentation (and it’s unlikely they’ll add anythin — in close to three years, I’m the only one to ever have updated it), but here are the new features I introduced since the last stable, features that have to be documented:
java.lang.Object instead of just ObjectThe 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:
IMPORTANT:
WOULD BE NICE IF FIXED BEFORE NEXT RELEASE:
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).
Using Google Alerts, I found a nice, short review of DrJava on a blog called “Return to Java”:
Dr.Java is an interesting little IDE that helps newcomers develop Java code. Although aimed at newcomers, it seems to have lots of advanced features. It could be a useful alternative to the larger IDEs like Eclipse and NetBeans.
I found it useful to create small projects and play around with compiling and easily interacting with Java code, without the hassle of creating a large project in a full featured IDE.
Thank you kindly!