[ImageJ-devel] Regarding Target Java 1.5 for imglib2 core

[Johannes Schindelin]

Dear Tobias,

On Sat, 31 Mar 2012, Tobias Pietzsch wrote:

> This has all been happening a bit too fast for me and I'm kind of lost
> right now about what exactly is going on here.  So could someone please
> explain what happened?

You might have realized that there were quite a ton of mails regarding the
non-compiling Fiji? That is what happened. And it was not exactly fast.
Things did not compile with the default javac shipping with Fiji, which
happens to be compiled from the latest javac sources available form the
jd6/langtools repository at http://hg.openjdk.java.net/jdk6/jdk6/langtools

Personally, I cannot understand how anybody can be happy with their code
not compiling in the standard setup (but only with a compiler that was
written in C++ and that is known to misbehave), so I worked long and hard
to fix the issues.

There was nothing exactly happening a bit too fast. Everything was
happening not at all until I tried and failed to fix things.

The real problem is of course that I need to care. It is not acceptable
for Fiji nor ImageJ2 or their dependencies to be non-compiling. We are
working very, very hard toward a beta1 of IJ2 and now is the least
opportune time to introduce compilation failures.

> There have been ugly "HACK"s introduced like the following:
> 
> -final T buffer = Util.getTypeFromInterval( fftImage ).createVariable();
> +// HACK: Explicit assignment is needed for OpenJDK javac.
> +final T fftImageType = Util.getTypeFromInterval( fftImage );
> +final T buffer = fftImageType.createVariable();

Yes. Outside of Eclipse, there exist other compilers. Some would even go
so far as to claim that the Eclipse compiler is not even standard!

:-)

It is just a wild guess on my part, but I have a hunch that it might be
the OpenJDK javac (the one from which we can legally take the javac
sources and ship them in fiji.git, as we label javac.jar as GPLv2) which
needs an explicit assignment to be able to compile the code.

It might have helped you understand the issue if you had been there when
we tried frantically to get those compilation errors out of our way to do
our real job. The problem is -- as you can see from the Jenkins logs that
are visible from quite a few Jenkins mails on fiji-devel -- that assigning
the thing in one go (basically, x = A.b().c()) triggers a javac bug that loses
the type information. Curtis found out that unchaining that assignment (y
= A.b(); x = y.c()) works around that bug.

> It seems, that this has been limited (fortunately!!!) to
> imglib2-algorithms-gpl.  But why? Surely, there are similar constructs
> in other parts of imglib. Why are they not affected?

If you want to know, please be my guest to git grep/dig into the source
code to find out. My guess is that there are no other such chains. (Note
that it has to do with really advanced and complicated constructs
involving generics such as having a "<S extends A<S, T>" generic parameter
and inferring the return value T. Note also that I fully expect more javac
bugs to lurk waiting for such obscure -- and rarely used -- constructs.)

Happily, Steffi and Curtis actually did something about the issue, so even
if it cost a lot of time, the things are fixed now.

> Are there plans to figure out the performance implications of using the
> old class format?  Is there anything I have to be careful about now, so
> that I don't break anything?  Can I (locally) just remove the
> maven-compiler-plugin section from the pom and have everything working
> as before?

Tobias, I researched what it takes to do the performance tests. Just write
JUnit tests to that extent. I even researched what it takes to have
Jenkins test for performance regressions. I installed the plugin. I tested
it. It works basically. I am fully prepared, even this is not *my* itch,
to extend the Jenkins plugin to support fine-grained performance testing.
What I am not prepared to do is the whole work. Someone who cares *must*
write the unit tests.

> And honestly, I don't like that this was done without any advance
> warning or discussion. This seems to be a big thing with potential
> performance implications.

Sure. There is a potential performance implication.

Show it to me.

Ciao,
Dscho