[
https://issues.apache.org/jira/browse/BEANUTILS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated BEANUTILS-413:
--------------------------------------
Fix Version/s: (was: 1.8.4)
LATER THAN 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
