The DrJava team released a new stable version of DrJava today, drjava-stable-20100816-r5366.
I therefore created a new release of DrJava with Mint: August 16, 2010 (drjava-r5366-mint-r15665.jar). The latest release is available from the Mint implementation page:
Nothing has changed on the Mint language side.
(Re-posted from The Java Mint Blog.)
We have just released a new stable release of DrJava: drjava-stable-20100816-r5366. You can download it from SourceForge or from the DrJava homepage.
Available for download at http://drjava.org .
DrJava is a lightweight programming environment for Java designed to
foster test-driven software development. It includes an intelligent
program editor, an interactions pane for evaluating program text, a
source level debugger, and a unit testing tool.
In addition to bug fixes, this stable release includes a number of new
features introduced after the last beta release:
These features include improved keyboard shortcuts, improved undo/redo
functionality outside the Definitions Pane, as well as better menus
for detached windows on the Mac.
Note: Java 1.4 compatibility has been dropped. To use DrJava, you will
need Java 5 or newer.
New features since the last beta release:
Bug fixes since last beta release:
New features since the last stable release:
Bug fixes since the last stable release:
Recently, I was asked if there will ever be a new DrC# which is similar to DrJava.
Unfortunately, I don’t expect an improved DrC# in the near future. We don’t have the funding and personnel to work on such a project. We already have trouble maintaining the DrJava Plug-in for Eclipse.
It may be possible to integrate a C# command line compiler into DrJava, though, if there is interest. There are problems with this approach, though: The syntax highlighting wouldn’t be right, and the Interactions Pane wouldn’t be functional.
The Java Mint tutorial lecture called “Agile and Efficient Domain-Specific Languages using Multi-stage Programming in Java Mint“, which Eddy and I proposed, has been accepted at GPCE 2010.
I’m looking forward to being in Eindhoven in October. Before that, on September 20, Eddy and I will have an opportunity to practice the lecture in our COMP 600 Graduate Research Seminar.
Our DrJava website is currently not available under the usual address (http://drjava.org). We are working on fixing this problem as quickly
as possible.
If you need access to the DrJava website in the meantime, please use one of these two URLs instead:
http://drjava.sourceforge.net/
http://www.cs.rice.edu/~javaplt/drjava/
We apologize for the inconvenience. Thanks for using DrJava!
Update
At some point during the morning of August 15, the domain started working again. We are happy to report that our website is available again under the usual address: http://drjava.org .
These are really cool panorama pictures of my university:
Experience Rice University’s 300-acre campus and its urban surroundings by taking our virtual tour http://bit.ly/a7Yt0I
If you click on the fourth image from the left in the navigation bar at the bottom, you can see my office building, Duncan Hall.
Duncan Hall at Rice University
Vincent from the Habanero research group actually asked me to make the change of setting the Polyglot classpath to be the same as the Soot classpath. That involved spending about a day figuring out how to even build Habanero Java, and then finding the best way to access the Soot classpath.
Initially I thought I could call [cci lang=”java”]Options.v().soot_classpath()[/cci], but that literally contains the value of the -cp argument passed in, which may be empty. In the end, I was able to access the exact Soot classpath without any code replication in one line in HjToJimple.java:
[cc lang=”java”]options.classpath = soot.Scene.v().getSootClassPath();[/cc]
That was all that had to be done.
Now I hope the Habanero group agrees that it is the right thing to do to make sure that the front-end (Polyglot) and the rest of the compiler (Soot) use the same classpath and that they commit this change.
Now there are still issues with not being able to compile the same file more than once (“Duplicate values
/home/mgricken/bin/hj-1.1.0-mgricken/examples and /home/mgricken/bin/hj-1.1.0-mgricken/examples for option -sp”), and I also can’t yet run classes (“Error: Can’t find main class”) but I haven’t worked on that yet.
[cci]find . -name \*html -or -name \*inc | xargs grep -l “\.owlnet\.” | xargs -n 1 -i bash -c ‘p4 edit {}; sed -i “s/\.owlnet\./.clear./g” {}'[/cci]
Dung Nguyen noticed that the links for previous semesters that I have on my Fall 2008 COMP 202 page all lead back to my own page.
I looked at the HTML source, and I do redirect to Owlnet, where the COMP 202 page used to be. For Fall 2007, for example, I link to http://www.owlnet.rice.edu/~comp202/04-fall. Something must have happened to the website on Owlnet. I tried to log in, but the SSH password that I have for comp202 does not work anymore. Neither did my comp212 password.
When I logged in with mgricken, though, I was able to see that the comp202 page has been redirected to CLEAR at http://www.clear.rice.edu/comp202 regardless of what actual page was being requested from Owlnet. For example, http://www.owlnet.rice.edu/~comp202 was being redirected to http://www.clear.rice.edu/comp202, which is what I wanted, but http://www.owlnet.rice.edu/~comp202/04-fall was being redirected to the same place.
Once I had figured out how to log into CLEAR, I could see that the CLEAR page at http://www.clear.rice.edu/comp202 redirects to my page… And that’s why all roads lead to me :-)
As a simple fix, I just changed my links to point to the right pages on CLEAR, e.g. to http://www.clear.rice.edu/comp202/04-fall.
I think we should also edit the redirection, which IT must have put in place without talking to us, and make it work as it should. If we don’t, then links that we may have elsewhere and that point to Owlnet don’t working either.
The web is a rather transient place. There really is no point to put up an “under construction” sign, because any website always is under construction.
Update
Changing the .htaccess file to
[cc]RedirectMatch ^/~comp202/(.*)$ http://www.clear.rice.edu/comp202/$1[/cc]
should do the trick.
Update
IT set up the redirection according to my suggestion now. Requests for Owlnet pages are now redirected to the corresponding CLEAR page. Try it:
http://www.owlnet.rice.edu/~comp202/06-fall now redirects properly to http://www.clear.rice.edu/comp202/06-fall/.
README files written by some non-native speakers of English are killing me right now. What is it with all the past perfect tense?!
All of these files had been put into the folder foo/bar, and the build files had been configured to point to these files.
Had been? Not anymore? Argh.
I’m trying to integrate the Habanero Java compiler into DrJava in a way that doesn’t require all the compiler classes to be present in the DrJava jar file. I want it to behave the same as javac, Mint, or NextGen.
In doing so, I noticed that Polyglot wasn’t finding some of the Habanero Java runtime classes, and I suspected that the Polyglot classpath wasn’t set up correctly. I was always getting a [cci lang=”java”]polyglot.util.InternalCompilerError[/cci], [cci lang=”java”]”Cannot find class “hj.lang.Runtime”[/cci].
After looking through the Polyglot, Soot and Habanero Java sources, I inserted a [cci lang=”java”]System.out.println[/cci] call in Polyglot’s [cci lang=”java”]LoadedClassesResolver[/cci], and my suspicion was confirmed: The Polyglot classpath doesn’t have the dynamically loaded jar files on it. When I hardcoded the classpath in [cci lang=”java”]LoadedClassesResolver[/cci] to be the required path, I was able to compile Habanero Java files within DrJava.
When we invoke the Habanero Java compiler from DrJava using [cci lang=”java”]soot.Main.mainEntry[/cci], however, we pass the entire classpath using the -cp option
([cci lang=”java”]testCommand[4][/cci] and [cci lang=”java”]testCommand[4][/cci] in HjCompiler.java, lines 263 and
following).
I think the Habanero Java developers should just be able to pass that classpath to Polyglot as well. It
looks like the [cci lang=”java”]initExtInfo()[/cci] method in HjToJimple.java would be the
right place to set [cci lang=”java”]options.classpath[/cci].
I haven’t confirmed this yet, because building Habanero Java is probably more involved than just compiling Polyglot.
This isn’t really going to be well-formatted, but I want to write down a few things that I have on my mind… This blog is for me anyway, not for you.
I need to rewrite the DrJava JDK descriptors to use the null object pattern instead of the [cci lang=”java”]null[/cci] constant. Checking for [cci lang=”java”]null[/cci] is icky. (Update: This is done now, and it’s so much more beautiful.)
I should try to help one of Prof. Mankoff’s students who has a problem with the Media Computation library. (Update: I emailed back and tried to help as much as I could, but I haven’t heard if it was enough.)
In integrating Habanero Java into DrJava, it seems like Polyglot doesn’t have the right classpath and can’t find [cci lang=”java”]hj.lang.Runtime[/cci].(Update: This is done now, and it’s working.)
It took me forever to find out how the -hj option is defined in Soot, but now I have realized that soot_options.xml defines the options, and the Options.java class is autogenerated. It contains a [cci lang=”java”]hj()[/cci] getter.
I think this bug report we just received is a promising candidate for Dumbest Bug Report of the Month:
Summary: something is missing?
Initial Comment:
i\’ve just download it. haven\’t start yet
(backslashes present in original)
That’s it. No more detail. What is this guy waiting for? Oh, I know! He’s waiting for my mind reading skills, which actually are missing.
A while ago, I introduced what was supposed to be a “Smart Run” feature, a simpler way of running Java programs, ACM Java Task Force programs, and applets. It sort of worked, but it has been difficult to get it right: The code is concatenated in an ugly manner and interpreted, but since it’s still Java with its type system, I sort of get all the problems but none of the benefits of interpretation.
Now Paul Ezust, Professor of Mathematics and Computer Science at Suffolk University, has notified me of another problem: If the class a user is attempting to run is not marked public then an exception is thrown.
With “Smart Run”, the code to start the program is a lot more complicated. DrJava needs to determine whether a program is an applet, and if it isn’t, it needs to check if it is an ACM Java Task Force program. In the last two situations, the main method is then invoked using reflection (come to think of it, I could probably do this without reflection, too… I should try that).
If the class isn’t public, then Method.invoke will throw an IllegalAccessException unless I call setAccessible(true) first. Now I do that, and I also handle the other exceptions better.
Here’s the concatenated command. Unwieldy, hm? I wish Java had multiline quotes.
String command =
"'{' boolean isProgram = false; boolean isApplet = false; Class c = {0}.class;\n" +
// cannot use Class.forName, doesn't work in Interactions Pane (see bug #1080869)
"while(c != null) '{'\n" +
" if (\"acm.program.Program\".equals(c.getName())) '{' isProgram = true; break; '}'\n" +
" c = c.getSuperclass();\n" +
"'}'\n" +
"if (!isProgram) '{'\n" +
" try '{'\n" +
// if this doesn't throw, {0} is a subclass of Applet
" {0}.class.asSubclass(java.applet.Applet.class);\n" +
" isApplet = true;\n" +
" '}' catch(ClassCastException cce) '{' '}'\n" +
"'}'\n" +
"if (isApplet) '{'\n" +
" edu.rice.cs.plt.swing.SwingUtil.showApplet(java.applet.Applet.class.cast(new {0}({1})), 400, 300);\n" +
"'}'\n" +
"else '{'" +
" java.lang.reflect.Method m = null;\n" +
" try '{'\n" +
" m = {0}.class.getMethod(\"main\", java.lang.String[].class);\n" +
" if (!m.getReturnType().equals(void.class)) throw new java.lang.NoSuchMethodException();\n" +
" '}'\n" +
" catch (java.lang.NoSuchMethodException e) '{'\n" +
" throw new java.lang.NoSuchMethodError(\"main\");\n" +
" '}'\n" +
" String[] args = new String[]'{'{1}'}';\n" +
" if (isProgram) '{'\n" +
" String[] newArgs = new String[args.length+1];\n" +
" newArgs[0] = \"code={0}\";\n" +
" System.arraycopy(args, 0, newArgs, 1, args.length);\n" +
" args = newArgs;\n" +
" '}'\n" +
" try '{'" +
" m.setAccessible(true);\n" +
" m.invoke(null, new Object[] '{' args '}');\n" +
" '}' catch(SecurityException se) '{'\n" +
" System.err.println(\"Error: Please turn off 'Smart Run' or use 'java' command instead of 'run'.\");\n" +
" '}' catch(IllegalAccessException iae) '{'\n" +
" System.err.println(\"Error: Please turn off 'Smart Run' or use 'java' command instead of 'run'.\");\n" +
" '}' catch(java.lang.reflect.InvocationTargetException ite) '{'\n" +
" if (ite.getCause()!=null) throw ite.getCause(); else\n" +
" System.err.println(\"Error: Please turn off 'Smart Run' or use 'java' command instead of 'run'.\");\n" +
"'}' '}' '}'";
I should try to rewrite this as Java code that doesn’t get interpreted in our Interactions Pane, but that actually gets statically compiled.
The bugfix is currently only available in our (more or less) DrJava weekly jar.
I just created a new release of Mint and DrJava with Mint: July 28, 2010 (r15665). It’s been over a year since we made the first version of Mint available! The latest release is, as always, available from the Mint implementation page:
Nothing really changed in the Mint language or in the way Mint is implemented; however, we moved our modified javac compiler into subpackages of the edu.rice.cs.mint.comp package, which means that the compiler is now invoked using the edu.rice.cs.mint.comp.com.sun.tools.javac.Main class.
The package and class names got a bit long, but by not using the same class names as Sun/Oracle, we can use our compiler together with other compilers or the original compiler if we want to, and there won’t be any class name clashes.
(Re-posted from The Java Mint Blog.)
From Slashdot:
“In Java 1.6.0_21, the company field was changed from ‘Sun Microsystems, Inc’ to ‘Oracle.’ Apparently not the best idea, because some applications depend on that field to identify the virtual machine. All Eclipse versions since 3.3 (released 2007) until and including the recent Helios release (2010) have been reported to crash with an OutOfMemoryError due to this change. This is particularly funny since the update is deployed through automatic update and suddenly applications cease to work.”
We probably need to check how DrJava behaves, too.
See also the Eclipse bug report 319514 and the Oracle/Sun bug report 6969236.
Update
Oracle now says that the rebranding will not happen until Java 7 is released:
In consideration to Eclipse and other potentially affected users, Oracle has restored the Windows Company Name property value to “Sun Microsystems”. This value will be changed to “Oracle” in JDK 7.
Update
I actually misunderstood the problem. DrJava would not have been affected at this time because the java.vm.vendor property wasn’t changed. It will change with Java 7, though.
WTF… After being on hold with the TX DPS for 19 minutes, they just hung up on me. Thanks, it’s not like dealing with you is a huge waste of time anyway.
I had to renew my TX drivers license again in June because my temporary visitor status expired, even though it really didn’t, because I can legally stay in the US as I’m a student. That was 39 days ago, my temporary license expires in 6 days, and I still haven’t received my new license.
Looks like I’ll have to make a ninth trip to the DPS in less than two years.
Update
Now they’re so busy, they can’t even take my call and put me on hold. It really looks like I have to go to the DPS office again. Vomit.
Update
I received the following email:
Thank you for giving the Department the opportunity to respond to your email inquiry.
Your visitor status has been updated. A request for a new license has been submitted and will be mailed to the address you provided. Allow 2 to 3 weeks for delivery.
I guess I don’t have to go to the office, but I probably still am not allowed to drive with my temporary license once it expires…?
I decided to merge the drjava-guiAvailListener branch into the trunk, even though I said I wouldn’t do this until after the next stable release. Dr. Nguyen and I have used this new version quite a bit already, and we still have a few days before the stable. I’m already confident the new implementation is bug-free.
The GUI availability listeners allow us to tie the state of certain GUI actions, for example the menu item to invoke Javadoc, to the availability of abstract components, for example the compiler. This had become necessary because many of the GUI actions are actually intertwined and mutually exclusive. Running JUnit could invoke the compiler first, and we knew that for a while; but just this spring, we realized that running Javadoc may have to do that too if we are dealing with Language Level source files.
The problem with directly enabling and disabling GUI actions was in some cases, these GUI actions were being re-enabled too early, before the entire action had actually been performed. With these new listeners, actions can specify a set of abstract components that must all be available, and when the status of one of these components changes, the GUI action is enabled or disabled appropriately.
I just created a new release of Mint and DrJava with Mint: July 22, 2010 (r15637). It’s been over a year since we made the first version of Mint available! The latest release is, as always, available from the Mint implementation page:
The DrJava team released a third beta version of DrJava almost two weeks ago, drjava-beta-20100711-r5314.
The only thing that changed on the Mint language side is the implementation of the toString() method for brackets.
There have a been plenty of new features and bugfixes for DrJava, and they have been integrated into DrJava with Mint. In fact, DrJava with Mint includes a few bugfixes that are not yet in the latest beta of DrJava.
(Re-posted from The Java Mint Blog.)
Joseph D. Darcy posted an informative article on writing regression and unit tests for new Java language features using JCK. This would have been useful for the Mint co-author who was supposed to write tests but ended up doing absolutely nothing.
