Issue 121098 - JDK7 : Replace generic type 46 with 49.
Summary: JDK7 : Replace generic type 46 with 49.
Status: CLOSED FIXED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: 3.4.0 Beta (OOo)
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.0.0
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-25 15:59 UTC by Pedro Giffuni
Modified: 2013-07-11 15:05 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 3.4.1
Developer Difficulty: ---


Attachments
Replace the generic type in codemaker/javamaker (571 bytes, patch)
2012-09-25 15:59 UTC, Pedro Giffuni
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Pedro Giffuni 2012-09-25 15:59:08 UTC
Created attachment 79635 [details]
Replace the generic type in codemaker/javamaker

In the Java 5/6 compilers it is possible to compile with an undocumented
-jsr14 option,  However, on JDK 7 the compiler no  longer recognizes the 
generic attributes in these class files. Full explanation is here:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419

We follow the workaround:
"Recompiling the classes but this is unfortunately not always possible.
I expect that it is possible to set the class file version to 49 but
have not tested this."

The issue was detected first by Michael Stahl and Stephan Bergmann and
the solution was based on a commit log posted in a public list.
Comment 1 Pedro Giffuni 2012-10-23 14:31:28 UTC
Comment on attachment 79635 [details]
Replace the generic type in codemaker/javamaker

In file main/codemaker/source/javamaker/classfile.cxx

We use type 46 in function ClassFile::write(FileStream & file).

An alternative would be to use type 49 there which stands for Java5.
Comment 2 SVN Robot 2013-02-25 08:53:55 UTC
"hdu" committed SVN revision 1449622 into trunk:
#i121098# use a classfile format compatible with at least JDK 5/6/7
Comment 3 hdu@apache.org 2013-02-25 11:10:38 UTC
Fixed with the commit above. Please review.
Comment 4 Pedro Giffuni 2013-02-25 13:05:26 UTC
Hmm ...
The extra casting is good but I miss the reason for the decimal point in the #define and the complicated way of calculating 0 to multiply it.

It does fix the issue though :).
Comment 5 hdu@apache.org 2013-02-25 13:19:31 UTC
The naming of the major/minor version of classfile format comes straight from the JVM specification and the calculation of the two fields follows from it too.
Comment 6 Pedro Giffuni 2013-02-25 13:30:49 UTC
I see .. OK, thanks!