Bug 842394 - Tracking bug for Java generics in format <1.5 classes
Summary: Tracking bug for Java generics in format <1.5 classes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 842571 842572 842573 842574 842575 842576 842578 842580 842581 842582 842583 842584 842585 842586 842587 842588 842589 842591 842592 842593 842594 842595 842596 842597 842598 842600 842602 842603 842604 842605 842606 842607 842608 842609 842610 842611 842612 842613 842614 842615 842616 842617 842618 842619 842620 842621 842622 842623 842624 842625 842626 842627
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-23 18:04 UTC by Mikolaj Izdebski
Modified: 2017-06-03 07:29 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-06-03 07:29:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mikolaj Izdebski 2012-07-23 18:04:29 UTC
It is possible to compile Java 1.5 code with generics for JVMs 1.4
or earlier, which don't understand generics. This works because Java
generics are implemented using type erasure.

OpenJDK used to support generics in older class file formats,
but since OpenJDK 7 this feature was dropped. See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419
Moreover, the upstream closed this bug as "Not a Defect",
so it will never be fixed. Because of Fedora needs to recompile
all code using or providing Java generics with target 1.5 or higher.
Ignoring this issue can lead to strange and hard to debug errors,
especially build failures. This happened before.

Class format versions for all Java packages as for today (big file):
http://mizdebsk.fedorapeople.org/jsr14-rawhide-2012-07-23.gz

Comment 1 Alexander Kurtakov 2012-07-24 10:21:45 UTC
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.

Comment 2 Mikolaj Izdebski 2012-07-24 11:34:18 UTC
(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).

Comment 3 Hans de Goede 2012-07-25 09:10:33 UTC
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 ?

Comment 4 Hans de Goede 2012-07-25 09:31:41 UTC
(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?

Comment 5 Mikolaj Izdebski 2012-07-25 09:36:16 UTC
(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.

Comment 6 Alexander Kurtakov 2012-07-25 10:03:18 UTC
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.

Comment 7 Alexander Kurtakov 2012-07-25 10:04:19 UTC
(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

Comment 8 Omair Majid 2012-08-02 00:42:23 UTC
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.

Comment 9 Mikolaj Izdebski 2014-04-29 06:07:09 UTC
I did all I could to fix these packages. Reassigning to default component owner.

Comment 10 Alexander Kurtakov 2017-06-03 07:29:06 UTC
Resolve the bug. All deps are fixed.


Note You need to log in before you can comment on or make changes to this bug.