[jira] [Comment Edited] (BEANUTILS-413) Compiler Compliance level creates bad bytecode

["Benedikt Ritter (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BEANUTILS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585153#comment-13585153 ] 

Benedikt Ritter edited comment on BEANUTILS-413 at 2/23/13 4:22 PM:
--------------------------------------------------------------------

Hello Christian,

changing the compiler level for a commons components requires (ASFAIK) to create a new major version. We can not simply fix this in 1.8.4. This is, because when releasing beanutils compiled against JDK 6 Java 1.3 users can't simply use the new version as a drop in replacement. They would get a BadVersionNumberInClassError if they do.

So we will have to postpone this issue until after 1.8.4.
                
      was (Author: britter):
    Hello Christian,

changing the compiler level for a commons components requires (ASFAIK) to create a new major version. We can not simply fix this in 1.8.4. This is, because when release beanutils compiled against JDK 6 Java 1.3 users can't simply used the new version as a drop in replacement. The would get a BadVersionNumberInClassError if they do.

So we will have to postpone this issue until after 1.8.4.
                  
> Compiler Compliance level creates bad bytecode
> ----------------------------------------------
>
>                 Key: BEANUTILS-413
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-413
>             Project: Commons BeanUtils
>          Issue Type: Bug
>          Components: Bean / Property Utils
>    Affects Versions: 1.8.3
>         Environment: All
>            Reporter: Christian Lewold
>             Fix For: LATER THAN 1.8.4
>
>         Attachments: CleReflectionDefect.zip
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> There is a problem with bytecode generated with jdk 1.3 compliance settings. The problem is, that public methods of package private classes cannot be accessed using reflection. 
> This happens for example with ResultSetDynaClass which extends JDBCDynaClass. Why is this important? Well, because problems occur in case e.g. ResultSetDynaClass.getDynaProperties is accessed through EL. 
> The problem is easily solved by re-building beanutils using "1.6" compliance settings. 
> This unit test shows the problem. I mocked the creation of ResultSet. 
> -) testUsingMethodCall always succeeds 
> -) testUsingReflection fails with commons-beanutils-core-1.8.3.jar in classpath. This is the version you get from official downloads or maven repositories!!!!! 
> -) testUsingReflection succeeds with commons-beanutils-core-1.8.3_jdk6.jar. I built this jar using mvn package, but changed compliance settings to 1.6 in pom.xml. 
> I also provide 2 decompiled (using jad) ResultSetDynaClass.jad_version files. The difference makes the real problem obvious. The public volatile methods exposing the public methods of the package private base class are missing in the byte code created with older compiler compliance settings.
> Bottomline - this problem happens often in case e.g. Tomcat 6 is used to show ResultSetDynaBeans using expression language. Likely these classes are not the only ones affected. 
> Actually I'd have a complete unit test, and a eclipse based test project (or if you prefer ant build.xml) easily showing the defect. I simply don't know how to attach the file right now. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira