| Summary: | commons-beanutils-1.8.3.redhat-3.jar was built with Class version 47 / JDK 1.3 | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Rostislav Svoboda <rsvoboda> |
| Component: | Build | Assignee: | David Walluck <dwalluck> |
| Status: | CLOSED EOL | QA Contact: | Petr Kremensky <pkremens> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1.1 | CC: | csuconic, fnasser, jason.greene, rsvoboda |
| Target Milestone: | --- | Flags: | fnasser:
needinfo?
(csuconic) |
| Target Release: | EAP 6.2.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-19 12:46:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1020878 | ||
|
Description
Rostislav Svoboda
2013-08-21 11:31:12 UTC
Can you tell me the reason for reporting this as an error? I know that this can be seen as a regression, but the upstream classes are actually built with Java class data, version 47.0 (Java 1.3). So I would argue that the current build is actually more correct now. As far as I know, it is not our policy to remove existing source and target information from either the local pom or any of its parents. Please advise. Hi David. This was reported because EAP 6 is supported on JDK 6 and JDK 7. So it would make sense to target build to Java 6 and take advantage of bytecode changes. What about JDK 5 clients? HornetQ for instance makes us ensure their client is JDK5 bytecodes. I believe the jboss parent sets the bytecode as 1.4 as Jason Greene and others did not see any perf improvement with newer bytecodes. Asking Jason for guidance. There is no performance difference between 4 and 5 when it comes to bytecode. Java 6 however added something called stack map frames which marginally improves classloading time. Actually there is one runtime difference I forgot about, which isn't related to bytecode but API usage. If you compile code using Java 1.4 it will turn string1 + string2 into StringBuffer calls. Java 1.5 will use the introduced StringBuilder which saves unnecessary locking. The latest jboss-parent sets version 1.6. But, if this stands, it would mean not only checking/removing the source and target from any local POMs, but from their parent POMs as well. The apache POM currently sets version 1.4 and the commons-parent POM currently sets 1.3. Any of these settings will override the setting in jboss-parent. Actually, there is some strange behavior with multiple versions being set due to the use of <compilerArguments> in jboss-parent, but that is another issue. (In reply to Fernando Nasser from comment #3) > What about JDK 5 clients? HornetQ for instance makes us ensure their client > is JDK5 bytecodes. JDK 5 is not supported for EAP 6. So there is no problem. JDK 5 clients for HQ are valid for EAP 5 only. Based on Jason's comments about Java 6 improvements in classloading time and StringBuilder usage for string concatenation (comment 5 and comment 6) I'm asking to line up builds for EAP 6 to Java 6. I have filled BZ for inconsistency in build last week - BZ 1020878 - Class Version of EAP jars not synced to Java 6 (Version 50.0) Fix for commons-beanutils should be tracked here, the rest in BZ 1020878. |