According to an update to the Eclipse bug report 308256 I filed when I was working on integrating the Eclipse Java compiler into DrJava, the bug will have been fixed in 3.6M7.
That milestone doesn’t seem to be available yet, but soon we won’t need to maintain a modified copy of the Eclipse compiler in our own SVN repository.
The second DrJava project I’m working on is a simplified Language Level facility. As stated before, this is mainly Corky’s work, but I’m helping to integrate it into DrJava.
In revisions 5225–5227, the Java Language Levels were changed. Once these changes are integrated into the trunk, there will only be one Language Level called dj (or “Functional Java”), which was created by combining and modifying dj0 and dj1. The dj2 Language Level has been eliminated and the Language Level converter merely copies the unmodified text from a dj2 file to a java file.
The new Language Level facility can still compile dj0 and dj1 files as dj files. Compiling dj2 files is currently broken.
Here is what we need to do to properly support the new Java Language Level facility:
We will wait until the semester at Rice is over, though until we make a new release. We don’t want our students in COMP 211 run into problems because DrJava suddenly behaves differently than before. I have also disabled building weekly jars for the same reason.
This week, I have worked on a couple of DrJava projects:
The second project, a simplified language level facility, is mainly Corky’s work, I’m just helping to integrate it into the main part of DrJava.
The first project, the ability to bundle other libraries and classes with DrJava, was a request by Barbara Ericson for use with the Media Computation classes at Georgia Tech.
As of revision 5232, this feature has been implemented and merged into the trunk.
"DrJava Version : drjava-20100423-r5230 with foo.jar, bar.jar".I’ll still have to do more specific tests with the Media Computation classes. As Mark Guzdial explained to me: “Right now, we include jmusic, javazoom, and various class files into our classes — see http://mediacomputation.org for either the Java CS1 or Data Structures classes.”
This is probably also of interest to anyone who uses the ACM classes.
I just found a picture of myself on Carl Alphonce‘s website for the 3rd "Killer Examples" Workshop, held at OOPSLA 2004 in Vancouver, Canada. Wow, did I look young.
Dung Nguyen, Owen Astrachan and I at the OOPSLA 2004 Poster Session
According to the DrJava statistics on SourceForge, we’ve had 988,013 downloads of DrJava so far.
If this summer is similar to last summer, we’ll hit a million downloads towards the end of July!
The DrJava team released a new beta version of DrJava today, drjava-beta-20100415-r5220.
I have integrated the February 17, 2010 of Mint with the new DrJava beta release and am happy to provide to you a new version of DrJava with Mint: drjava-r5220-mint-r15362.jar.
Nothing has changed on the Mint side, but there have been plenty of bugfixes for DrJava, as well as a few new features. In particular, the persistent compiler preference will make it easier to use DrJava with Mint: Just select the Mint compiler as default!
(Re-posted from The Java Mint Blog.)
We have made a new beta version available: drjava-beta-20100415-r5220. 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 in anticipation of the next stable release, this beta release includes a number of new features introduced after the last stable release:
These features include JUnit 4 support, ConcJUnit support, and the ability to use the built-in Eclipse compiler, the OpenJDK and JavaMint compilers.
Note: Java 1.4 compatibility has been dropped. To use DrJava, you will need Java 5 or newer.
New features since the last stable release:
Bug fixes since the last stable release:
I just read a blog post by Tor Norbye called How to Write a Memory Leak Unit Test. In it, he describes how code from the NetBeans team can be used to find memory leaks. It seems like it’s a more advanced, user-friendly way of doing what I described before. In particular, the chain of references preventing garbage collection is actually printed out during the test.
I definitely have to take a closer look at this. Thanks, Tor!
With two weeks left in the semester, we should think about what work
needs to be done on DrJava to make a beta release, followed by a
stable. Should we make these releases even if we don’t fix some of the
serious bugs we currently have?
We have received several comments that our release schedule isn’t
convenient, since we typically make stable releases at the end of the
summer, but larger universities need to install the software at the
beginning of the summer already. It would therefore be advantageous if
we could make a new release soon.
We’ve had one reoccurrence of the “Cannot undo” problem, but it’s
difficult to track down. Most serious problems are in the interpreter.
There are some problems with language levels, but since we do not have
many customers that use language levels in the Fall, fixing those
isn’t as urgent.
Here’s a list of important bugs:
DrJava:
Interactions:
This one makes me wonder if there are other class loader issues in the
interpreter:
These two are not show stoppers, but should be easy to fix:
Not so important:
Language Levels:
These are also not show stoppers for this release, since we don’t have
many customers that use Language Levels in the Fall. We should attempt
to fix these before the next Spring COMP 211 class, though.
Update
Dan fixed a bunch of bugs.
I finished integrating the Eclipse Java compiler into DrJava. This
made the DrJava executable about 1.1 MB bigger, but it has the benefit
that DrJava users don’t necessarily have to have the JDK installed
anymore: As long as they run DrJava with Java 6, they will always at
least have the Eclipse Java compiler available (but not the debugger).
I think this is an important improvement since getting the “No
compiler available” error was one of the most frequently reported
problems.
The Eclipse compiler I’m using is a modified version 3.6M6. I could
not use the latest release 3.5.2 because of a bug that prevented any
errors from being reported to a DiagnosticListener. After I had
diagnosed that problem, I found out that the bug had been fixed for
milestone 3.6M3. I discovered that this release has another bug,
though, which prevents a DiagnosticListener from receiving information
about the source file that contains a compiler error.
I filed a bug report with Eclipse and fixed the
bug in a modified copy of the Eclipse Java compiler 3.6M3 currently
kept in our repository. It works in *our* case, but the Eclipse
developers won’t be able to use the exact same solution without losing
some generality. I’ll see what they do, and when they fix the problem,
I’ll replace our modified version with their solution.
Please take a look at our latest weekly release. If you are
running Java 6 or later, you should be able to select the Eclipse
compiler. It still prefers the other compilers, but on systems with
the Java 6 JRE but without JDK, users of this version now at least
have a compiler available.
I still have to include the Eclipse license text in the program, the source and on the website, but I’ll get to that.
Let me know what you think! Thanks.
I got compiling in DrJava using the Eclipse compiler to work last night, except that the errors never provided a source location. I thought this was because I hadn’t set the source path in the file manager, but it turned out that is not the issue. There is another bug in the Eclipse compiler: The developers use a file name in a place where a class name is expected, and because of that, the look-up of the source location always fails.
I filed a bug report for it: Bug 308256 – DiagnosticListener always supplies Diagnostic.getSource()==null
Build Identifier: ecj-3.6M6.jar
When compiling with a DiagnosticListener and encountering an error, the
provided Diagnosticalways returns null for the getSource()
call.This is because originatingFileName is being passed to
JavaFileManager.getJavaFileForInput, even though the method expects a class
name. For example, “/home/username/temp/Foo.java” is being passed as a class
name, not “Foo”.
@Override
public JavaFileObject getSource() {
try {
if (EclipseCompilerImpl.this.fileManager.hasLocation(StandardLocation.SOURCE_PATH)) {
return EclipseCompilerImpl.this.fileManager.getJavaFileForInput(
StandardLocation.SOURCE_PATH,
new String(originatingFileName),
JavaFileObject.Kind.SOURCE);
}
} catch (IOException e) {
// ignore
}
return null;
}
Instead of using getJavaFileForInput, which expects a class name, you could use
getJavaFileObjects, which works for a file name.Reproducible: Always
Steps to Reproduce:
1. Just compile code using a DiagnosticListener
2. Encounter an error in a Java file.
3. Look at the return value of Diagnostic.getSource(), it is always null.
Now I don’t quite know what to do. Should I fix this bug locally and use a modified version of the Eclipse compiler in DrJava, until this bug gets fixed by the Eclipse people?
I’m working on integrating the Eclipse Java Compiler into DrJava (see feature request), but error reporting doesn’t work correctly yet.
After some confusion during debugging, I found out that this is because of an Eclipse bug (Eclipse bug report 290470):
In revision 1.45 of DefaultProblemFactory.java, the createProblem method was overloaded to include an elaborationId. But until revision 1.11 of EclipseCompilerImpl.java, the new method wasn’t overridden.
The bugfix isn’t in the in the 3.5.2 release yet, but it is in the 3.6M6 milestone. I guess I will use that for now and then update to release 3.6 when it’s available.
The last few days summed up:
I got Soot’s “may happen in parallel” (MHP) analysis to work, but only on a very small, completely unrealistic example which I used to test my “shared volatile” code (source below). Even for this, I needed to set the heap size to 2 GB (which, if I remember correctly, won’t work on Windows machines). Anything a little bit bigger either exhausted
memory or caused the JVM garbage collector crash.
They must be horribly inefficient with their static analysis. In one of the theses I read today, the biggest benchmarks had 3,800 lines of code. Maybe I am doing something wrong, because they used 1.5 GB heap, but as of now I have doubts their analysis scales to real applications like DrJava.
Furthermore, Soot’s MHP analysis doesn’t take the event thread into account, but this is probably a smaller issue.
package testers.volatileVarsThread;
public class VolatileVarsThread {
public static volatile int vsField;
public static int sField;
public static volatile int vsField_notShared;
public static int sField_notShared;
public static void main(String[] args) {
doStuff();
try {
new Thread(new Runnable() {
public void run() {
++vsField;
++sField;
System.out.println("Foo");
int i = doStuff() + doStuff();
System.out.println("i = "+i);
I c = new C();
c.doSomething();
}
}).start();
}
catch(java.lang.Exception e) { }
++vsField_notShared ;
++sField_notShared;
B b = new B();
b.doSomething();
}
public static int doStuff() {
return new A().foo() + 2;
}
}
class A {
public int foo() {
return bar() + 1;
}
public int bar() {
return 123;
}
}
interface I {
public void doSomething();
}
class B implements I {
public volatile int vField_notShared;
public int field_notShared;
public volatile int vField_notSharedButDynamicTarget;
public int field_notSharedButDynamicTarget;
public B() {
++vField_notShared;
++field_notShared;
}
public void doSomething() {
++vField_notSharedButDynamicTarget;
++field_notSharedButDynamicTarget;
System.out.println("B.doSomething");
}
}
class C implements I {
public volatile int vField = 3;
public int field = 4;
public void doSomething() {
vField = 0;
field = 0;
System.out.println("C.doSomething");
}
}
While looking for information on Soot, I found this little gem here by Chris Pickett: swd, Subversion Word Diff.
This is perfect for writing LaTeX papers in a group. For example, when I do an svn diff on our Mint paper, I might get something like this:
A key issue for MSP is type safety, which ensures statically that all
-programs generated at runtime will be well-formed. Unfortunately,
-although it is known how to ensure type safety for MSP in the purely
-functional setting \cite{taha98,taha03,calcagno04}, it remained an
+programs generated at runtime will be well-formed. Although it had
+been known how to ensure type safety for MSP in the purely functional
+setting \cite{taha98,taha03,calcagno04}, it previously remained an
open challenge how to extend this guarantee to mainstream languages
such as Java. In particular, standard features of mainstream
languages
When I use Chris’ svn wdiff, I get something much cleaner:
A key issue for MSP is type safety, which ensures statically that all
programs generated at runtime will be well-formed. Unfortunately,
although Although it is had
been known how to ensure type safety for MSP in the purely functional
setting \cite{taha98,taha03,calcagno04}, it previously remained an
open challenge how to extend this guarantee to mainstream languages
This could have been really useful during editing before submitting the camera-ready version.
I bought a RadioShack 12 V, 1.5A power supply today to replace the one that died yesterday. I had written down the voltage and current, but hadn’t bothered with the actual tip because I expected to just buy the cheapest power supply, cut and strip the wires and attach the tip from the original power supply.
I forgot that RadioShack has the “adaptaplug” power supplies, and that I’d get one tip for free. I just picked a tip from memory.
I picked right.
A while ago I found an article entitled Top Ten One-Liners from CommandLineFu Explained, and I liked the example to quickly create backup files. Well, today I had some kind of Perforce problem after I renamed a couple of files, and I couldn’t submit the changelist, but I also wasn’t allowed to resolve anything.
So I decided to use my new CommandLineFu to make a backup, revert, checkout and copy the backup back over. It was amazingly simple:
cp FindReachableMethods.java{,.save}
p4 revert FindReachableMethods.java
p4 edit FindReachableMethods.java
mv FindReachableMethods.java{.save,}
Line 1 copies FindReachableMethods.java to FindReachableMethods.java.save. The {,.save} part expands to two arguments, the first one being just the preceding file name, the second the preceding file name with .save attached. In line 4, I move the files, but in the opposite direction.
I received a bug report yesterday that Class.getPackage() wasn’t working for user-defined classes and classes written in the Interactions Pane:
I was trying to run one of our assignment projects on DrJava and kepts getting a NullPointerException because getPackage() returns null. Corky said it was best to contact you about this.
To reporduce:
1. Load the attached project in DrJava
2. Run the following on the interactions pane:
new edu.rice.comp211.laundry.Main().getClass().getPackage()You’ll see null get printed.
This was a bit confusing for me because of several quick tests that I made: I tested it in the default package, and for the default package, the return value of Class.getPackage() is supposed to be null. I also compared DrJava’s Interactions Pane to running programs in DrJava using the “Run” button. I should have compared it to running programs on the command line.
I hadn’t heard of having to call ClassLoader.definePackage before. Somehow, it had never been mentioned in any of the documents I had read about class loaders. The documentation seems to say that
package information is optional (“It may be null if no package information is available from the archive or codebase.”).
I figured out that we needed to call getPackage() in the class loader and check if it is null. If it is, and we are defining a class outside the default package, then we need to define a package by calling definePackage() before we call defineClass() (“Packages must be created before the class is defined”).
I just don’t understand why this isn’t done automatically with default values. My call looks like this:
definePackage(packageName, null, null, null, null, null, null, null);
There isn’t any more information being provided, except to say that this package exists. After a class in the package has been loaded, a package cannot be defined anymore, so there is no reason for not defining a package without information.
This morning, my uninterruptable power supply (UPS) for my computer went poof. It really made that sound, and then there was a chemical smell in the room. It had acted up a few times in the last couple of months, but I thought the worst that could happen was that my computers would lose power. Well, this smelled a bit more dangerous, so I decided to replace it. I already picked up a new UPS from Office Depot (who wanted to sell it in the store for $99.99, but I matched it to $89.99 on the website) and it’s charging, but I haven’t switched the old one out, which is unplugged now. I didn’t want to risk an electrical fire while I was at work.
Update
It seems like there was another casualty: The reverse converter that I had been using to power the German flatbed scanner is apparently dead. That’s actually not so bad, I should have replaced that with a regular power supply anyway and then just cut the wire and attached the original power connector on the scanner side. The reverse converter probably ate 30 W just by itself all the time.
This afternoon, I submitted the final camera-ready version of our Mint paper that was accepted to PLDI 2010, Mint: Java Multi-stage Programming Using Weak Separability.
Eddy and I incorporated some more suggestions we had received from Julia Lawall and Sam Kamin, who sacrificed their valuable pre-OOPSLA submission time to proof-read our paper again. Thank you so much!
I’m glad that I could sign the copyright release form by myself, and that I didn’t need to get the signatures of my five co-authors. That could have been a big headache: Walid is here, but I didn’t see him today; Eddy and Jun are in Oxford; Yilong is an undergrad at Rice, and I haven’t seen him in months; and Tamer is in Egypt. I enjoy signing other people’s rights away.
All of that is done now. I think the paper got better still, and we even managed to stay six lines under the limit of twelve pages!
Camera-ready version: Mint: Java Multi-stage Programming Using Weak Separability (PDF)
(Re-posted from The Java Mint Blog.)