Bug 842394

The fact that one jar from package is using generics doesn't mean that all the rest are using generics. Hence they can still use the old classformat, some of the bundles from upstream eclipse are supposed to even run on Java 1.2. 
Also the comment added about using -target switch is totally not true in eclipse world as the target level is set based on the Bundle-RuntimeExecutionEnvironment which is defined by upstreams to the corresponding level.
Also in the future don't mass open such bugs but please includes details, e.g. in eclipse-gef - which jar(bundle) contains generics and is compiled to old classversion? Or even it might not be a bug if the jar using generics properly compiles to newer class version and the jars not using are compiled to old are properly using older class version? Anyway without all the details there is not much use from the bug reports.

(In reply to comment #1)
> The fact that one jar from package is using generics doesn't mean that all
> the rest are using generics. Hence they can still use the old classformat,
Obviously.

> Also in the future don't mass open such bugs but please includes details,
> e.g. in eclipse-gef - which jar(bundle) contains generics and is compiled to
> old classversion?
I don't know which classes contain generics. It's impossible to see that from the bytecode file if it's in old format (type erasure removes any generics information). Looking for that would require me to write a full-featured Java source parser. And even then I wouldn't be sure because (for example) some files might be excluded from the build process. Since maintainers should know their packages better than I do, I left the manual bug evaluation to them.

> Or even it might not be a bug if the jar using generics
> properly compiles to newer class version and the jars not using are compiled
> to old are properly using older class version?
Of course, as with any bug report, there may be some false-positives. It's up to maintainers to evaluate the reports and take appropriate actions.

> Anyway without all the details there is not much use from the bug reports.
All the details are in the linked jsr14-rawhide-2012-07-23.gz file (and the packages themselves).

Erm, not all of us package-maintainers who happen to maintain a java package or 2 are hardcore java jockeys, can you please provide some generic instructions for often used java buildsystems (ie ant) how to modify the buildsys input files to get the buildsys to pass the necessary parameter to javac ?

(In reply to comment #3)
> Erm, not all of us package-maintainers who happen to maintain a java package
> or 2 are hardcore java jockeys, can you please provide some generic
> instructions for often used java buildsystems (ie ant) how to modify the
> buildsys input files to get the buildsys to pass the necessary parameter to
> javac ?

Looking at the build.xml files for bolzplatz2006, I see the following there:
<javac debug="yes" srcdir="${lwjgl.src}/java/" destdir="${lwjgl.bin}" includes="org/lwjgl/*.java" source="1.4" target="1.4"  taskname="lwjgl" /> 

And similar lines, I assume that changing the target="1.4" to target="1.5" there is all that is needed?

Also about the http://mizdebsk.fedorapeople.org/jsr14-rawhide-2012-07-23.gz file, it seems that .class files with a version of 49.0 or higher are ok, correct?

(In reply to comment #4)
> Looking at the build.xml files for bolzplatz2006, I see the following there:
> <javac debug="yes" srcdir="${lwjgl.src}/java/" destdir="${lwjgl.bin}"
> includes="org/lwjgl/*.java" source="1.4" target="1.4"  taskname="lwjgl" /> 
> 
> And similar lines, I assume that changing the target="1.4" to target="1.5"
> there is all that is needed?
Yes, that should be enough.

> Also about the http://mizdebsk.fedorapeople.org/jsr14-rawhide-2012-07-23.gz
> file, it seems that .class files with a version of 49.0 or higher are ok,
> correct?
That's correct.

For ant builds it's enough to call ant with -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5 without patching the build.xml at all.

(In reply to comment #6)
> For ant builds it's enough to call ant with -Dant.build.javac.source=1.5
> -Dant.build.javac.target=1.5 without patching the build.xml at all.

Heh, unless someone set it explicitly like in comment#4

I take it that stubs classes generated by rmic are false positives? Looking at the code for rmic and the result of rmic -keep, rmic never generates any generics in the classes it creates.

I did all I could to fix these packages. Reassigning to default component owner.

Resolve the bug. All deps are fixed.