A Concurrent Affair

I’d like to wish a happy new year to everyone who might be reading this, but since quite likely that’s just me, I want to extend those wishes to all my friends, in particular to those who were kind enough to invite me to spend the past few hours, the end of the old year, and the beginning of the new year together with them. I wish a happy new year to everyone I work with, and I wish as happy a year as possible to my mother. If there is anyone who deserves a happy year, it is her.

May the new year bring good to all of you.

After talking to Michael Ernst about subtyping for annotations and learning of strong opposition against it from Sun and Google, I looked through the archives of the JSR 308 to see if there was a discussion about subtyping that I missed or that occurred before I started reading some time in May. Maybe I still missed it, but there was really only one post by Bill Pugh, entitled “Ideas for Java annotation extension (independent of JSR-30[58])”, that dealt with exactly what I am doing, but also indicating that it wasn’t directly relevant to JSR-308. I think it may be useful to compare Bill’s proposals to mine.

After talking with Josh, I’ve decided to live within one design
constraint of the existing framework: for any annotation location and
annotation class, there is either zero or one matching annotations.
This forbids some things like subtyping between annotations, and
multiple instances of the same annotation on an element.

In my current implementation of xajavac, I have relaxed this requirement, and there can be any number of repeated annotations on a location. With subtyping, however, I believe this becomes less of an issue, since a programmer can always write an annotation that groups certain annotations together, thus in a way allowing repeated instances.

* Proposal 1: An annotation is allowed to extend/implement any number of interfaces.

In xajavac, any annotation is allowed to extend any other annotation (excluding cycles and the usual Java rules). An annotation is really just like an interface: An interface can extend other interfaces; an annotation can extend other annotations. If an interface doesn’t extend anything, its implicit superclass is Object; if an annotation doesn’t extend anything, its implicit superclass is java.lang.annotation.Annotation, as with any annotation right now. Neither an interface nor an annotation cannot extend a class; an interface can extend an annotation, but an annotation cannot extend an interface in my implementation. Classes can implement both interfaces and annotations.

You might want to use this for marker interfaces, or define an interface that defines several elements/methods, and any annotation that implements that interface would be required to implement those methods.

Note that the interface would just be a normal interface that could be implemented by classes as well (although this wouldn’t be recommended practice). interfaces can’t define default values.

This would allow you to define a standard set of element names that were used by by set of specific annotations, and allow internal API’s that worked with any annotation from that set.

I never really thought about interfaces extending annotations, although that’s clearly allowed in my implementation. The interface then can’t use as an annotation anymore, though. I don’t see much of a use here, but on the other hand, I don’t see a reason to forbid this either.

* Proposal 2 (requires proposal 1):

An annotation can define an element that returns an interface that extends java.lang.annotation.Annotation. When applying such an annotation in the source code, the value used there must be some concrete annotation that extends that interface.

Right now, the only values allowed for annotation elements are: primitives, String, Class, enums, specific annotation classes, and arrays.

This proposal would allow you to define annotations that, when applied in source code, accepted as an element value any one of a number of specific annotations. By defining the element to return a value of type Annotation, you can define an element where an arbitrary Annotation can be provided.

I think this explanation is overly complicated. I don’t think it is necessary to achieve what annotations aim to do: annotating parts of a program with data available at compile time.

For example, consider example where the Baz annotation can be applied with either a Foo or a Baz annotation as an element:

public interface AnnotationWithId extends Annotation {
int id();
}
public @interface Foo extends AnnotationWithId {
int id(); // this could be omitted, since it is defined in the interface
String msg();
}
public @interface Bar extends AnnotationWithId {
int id() default 0; // couldn't be omitted, since the interface can't give a default value
String date();
}
public @interface Baz {
AnnotationWithId annotation(); // can supply a @Foo or @Bar here
String reason();
}
public Test {
@Baz(annotation=@Foo(id=17, msg="testing"), reason="because")
public int test() { return 17; }
}

In my implementation, I don’t allow annotations to extend Annotation, because that is an interface. This extension is implicit, however, as it is with any annotations currently. Other than that, everything in this example can be done with my example, as long as all the “interfaces” that are extended are annotations, and all the members are primitives, String, Class, enums, annotation classes — now including subclassing, of course — and arrays.

I considered allowing Annotation as one of the members in an annotation, in addition to String, Class, enums, annotations, and arrays, but I don’t think this is all that necessary. It would allow to have an array of any kind of annotation, but I’m not sure how useful that is. It is more likely that a programmer wants a certain kind of annotation, e.g. any kind of InvariantAnnotation, as in my invariant checker.

I suspect there may be issues I hadn’t considered, so I’d appreciate
your feedback on this.

My current thought is to not make this part of JSR-308, but directly
submit it to the JSE7 effort.

I’m starting to realize what bureaucracy is involved in making any changes to a programming language, even if it is Java, which is not standardized by an official international organization like ISO. So I guess I share Bill’s sentiment of including these changes some time in the future.

Yesterday, on my birthday, I released a new beta version of DrJava. If you have any time, please take a look at it.

After some discussion on December 19, which was a bit limited because only Dan chimed in, I decided to create a branch based on revision 4268, the last version before Dan integrated the new interpreter. Then I merged the last changes I made in revision 4286 into the branch, so the beta has all the bugfixes and features of our latest internal version, but not the new interpreter.

If I don’t hear of any major problems, I will make a new stable release based on the same branch during the first few days of the new year. In mid-January, we will then make a new beta release that also includes the interpreter.

I looked at the release notes for our new beta again, and I think it was very necessary to release a new version. It may not seem like we did much in the last half year, except for Dan’s work on the interpreter, looks can be deceiving. Since the last released stable (and even beta!), we’ve added the
following features:

Drag-and-drop for Java files. It’s really incredibly convenient. If you haven’t tried it yet, do! You’ll be amazed.

Connecting to a running DrJava instance to open files in an that instance. This may not be important for most of you, but it enables me (and perhaps others) to use DrJava as a highly-functional IDE to display code. The deadlock checker I wrote loads the file into DrJava and jumps to the right line at the click of a button. Why write a new display tool when we have DrJava?

‘Automatic import’ dialog to the Interactions Pane. We’re all lazy, and this makes being lazy so much more convenient ;-)

Just two days ago, I made it work with user-defined classes too. It works very well if “Scan Class Files” in Preferences/Display is enabled (by default disabled, because it takes some time on network drives), because then the actual class files that are generated are scanned. If that is disabled, then it uses the names of the Java files, which may not contain all publicly accessible classes. And outside of project mode, if the working directory is set incorrectly, then the package names may be wrong, but there’s not much I can do
about that.

I also do not allow static imports of static inner classes, because that would require me to check for “public static” visibility, and at least with our current reduced model, it’s not easy to do that quickly. I could add that feature by scanning class files internally (the ASM library we now include can certainly do that, and the library I wrote for Concutest can definitely do it as well, and of course I’m very familiar with it), but again, that takes time, especially on network drives.

I hope you agree that drag-and-drop and automatic import are very important convenience features. But we also performed a few bug fixes:

• [ 1773173 ] Find All results with similarly-named files. If the files were named similarly, they were merged incorrectly in the “regions display panel”-type panes.
• [ 1792359 ] when exiting, cancel button does not behave as expected. There was a mismatch among the return types, and users could lose their changes when DrJava quit unexpectedly.
• [ 1831946 ] Error after compilation. This was another concurrency problem, and by changing the way listeners are removed, we hopefully addressed this.

Please try out the new version, and definitely let me know if you run into any problems.