Summary: | dev-java/qdox-1.12.1-r1 : Exception in thread "main" java.lang.UnsupportedClassVersionError: java_cup/runtime/Scanner : Unsupported major.minor version 51.0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
dev-java:qdox-1.12.1-r1:20151107-190808.log
emerge-history.txt environment |
Description
Toralf Förster
2015-11-07 19:12:56 UTC
Created attachment 416242 [details]
dev-java:qdox-1.12.1-r1:20151107-190808.log
Created attachment 416244 [details]
emerge-history.txt
Created attachment 416246 [details]
environment
This kind of bug is surprisingly slippery. If the virtual/jre version for a package (javacup in this case) gets bumped then all the revdeps will need at least that version, and then all the revdeps of that, and so on. In theory, upstream should already be using at least that version, which is probably why we haven't seen this problem all that much. In practise, we sometimes use newer dependencies than what upstream use. Now that Java 6 is quite old and Java 7 (or even 8) is often required, we may start seeing this more often. Fixing this particular case properly is a pain. Users are unlikely to encounter it because I've not come across anybody deliberately choosing icedtea 6 over 7. While I appreciate your thorough testing, we're on the verge of dropping 6 entirely so most existing cases of this problem will no longer be an issue. I will make a note about the problem in the wiki so that we can avoid it going forwards. I'll also think about whether we can add a QA check for it because it's very easy to miss. Java 6 is gone now so this particular instance of the problem has disappeared. I don't think we'll ultimately get on top of this until Java 9 though. |