PRE-PROPOSAL: Source and Encoding keyword

Mark Mahieu markmahieu at
Wed Mar 18 00:20:52 PDT 2009

2009/3/18 Joseph D. Darcy <Joe.Darcy at>

> A few general comments here.
> While it would be technically possible to add some kind of metadata to a
> Java source file, as such as annotation with a
> javax.lang.model.SourceVersion member, to state its source version, I
> don't find this a compelling problem to solve.  The issue primarily
> occurs when a mixed-version code base is being compiled with a single
> javac invocation:
>    Patient: "Doctor, it hurts when I move my arm like this."
>    Doctor: "Don't move your arm like that!"

The closest I've come to this kind of problem recently was when using GWT,
where some of the code is translated into another language (Javascript) at
build time.  GWT's current compiler attempts to comply with javac 1.5's
behaviour, yet the project as a whole was at 1.6, which is just enough of a
difference to cause problems as IDEs will then happily insert @Override in
places that are fine with javac 1.6 but not javac 1.5.

This scenario was caused by the belief that it's only necessary to worry
about the libraries when mixing 1.5 and 1.6, ending up with the code to be
translated mixed with the code that wasn't, which is a model GWT encourages.

Wasn't serious enough to see a doctor about.

> I don't think this is a worthwhile path to pursue.

I agree - at least in the type of scenario I described above, there are
better ways to deal with it.


More information about the coin-dev mailing list