New Mint Release: r15716

As mentioned before, Eddy and I discovered a problem with type variables in code generated by the Mint compiler. We have now fixed this problem in the new release of Mint ^[1] and DrJava with Mint ^[2]: August 30, 2010 (r15716). The latest release is, as always, available from the Mint implementation ^[3] page:

• JavaMint-r15716.tar.gz ^[4]
• JavaMint-r15716-binaries.zip ^[5]
• drjava-r5380-mint-r15716.jar ^[6]

The problem occurred when the programmer used a type variable inside a bracket. An example of this would be a generic method like this:

[cc lang=”java”]public separable Code fun(Code c1, Code c2) {
return <| ( `(lfTest.eval(e,f).booleanCodeValue()) ? `c2 : `c1 ) |>;
}[/cc]

This caused Mint to generate 2nd stage code that contained the type variable [cci lang=”java”]X[/cci] unbound. Unfortunately, the types are erased, and there is no way to find out what type [cci lang=”java”]X[/cci] actually refers to at runtime, e.g. by writing something like [cci lang=”java”]X.class[/cci] (this generates the Java compiler error “cannot select from a type variable”).

To get around this problem, we now require a final instance of type [cci lang=”java”]Class[/cci] to be in scope for every type variable [cci lang=”java”]X[/cci]. For example, in the generic method above, there is a type variable [cci lang=”java”]X[/cci] that is being used in the bracket. Therefore, we now have to have a final instance of [cci lang=”java”]Class[/cci] somewhere in scope, for example as a method parameter.

[cc lang=”java”]public separable Code fun(Code c1, Code c2,
final Class xc) {
return <| ( `(lfTest.eval(e,f).booleanCodeValue()) ? `c2 : `c1 ) |>;
}[/cc]

That’s all that is necessary. The variable [cci lang=”java”]xc[/cci] is not actually used in the code, it just needs to be in scope.

(Re-posted from The Java Mint Blog ^[7].)