Summary: | dev-java/stringtemplate-3.2.1 fails tests with java 7 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Patrick Lauer <patrick> |
Component: | New packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 417895 | ||
Bug Blocks: | 483018 | ||
Attachments: | emerge =dev-java/stringtemplate-3.2.1 |
Description
Patrick Lauer
2012-02-20 15:46:59 UTC
Works fine with java 6, fails with java 7. Actually stringtemplate-3x is little bit outdated (see bug 417895). The latest version is 3.2.1 released on September 22, 2009. Possible, java7 users should use stringtemplate-4x. (In reply to Mike Limansky from comment #2) > Possible, java7 users should use stringtemplate-4x. We'll see, but bug #417895 comment #1 explains that they are not compatible. (In reply to Tom Wijsman (TomWij) from comment #3) > (In reply to Mike Limansky from comment #2) > > Possible, java7 users should use stringtemplate-4x. > > We'll see, but bug #417895 comment #1 explains that they are not compatible. Yes, it was my comment. But it looks like stringtemplate-3.x is unmaintained. So, it's upstream issue which possible will not be resolved. Also, it looks like there are no packages depends on stringtemplate. So, it's bit strange to block java7 stabilization because of this bug. IMHO, the only thing required here is to set DEPENDS on <java7. (In reply to Mike Limansky from comment #4) > So, > it's bit strange to block java7 stabilization because of this bug. IMHO, the > only thing required here is to set DEPENDS on <java7. There are already such versions stable, please note this blocks <java7 removal. It's not true that nothing depends on stringtemplate. The most notable is antlr. antlr-4 uses stringtemplate-4 and antlr-3 uses stringtemplate-3. I would therefore say drop stringtemplate-3 but antlr-4 requires antlr-3 to build and includes it in the final result. Confused yet? I need to look at antlr anyway because antlr-3 doesn't build with Java 8 and we haven't yet provided a fully working antlr-4 solution. Created attachment 410678 [details] emerge =dev-java/stringtemplate-3.2.1 (In reply to Ralph Sennhauser from comment #1) > Works fine with java 6, fails with java 7. And does fine with =dev-java/icedtea-3.0.0_pre04-r1::java (In reply to charles17 from comment #7) > And does fine with =dev-java/icedtea-3.0.0_pre04-r1::java That is interesting but we can't rule out Java 7 yet. antlr has almost bubbled to the top of my list now. So here's a strange thing. I've been revamping the entire antlr/stringtemplate situation and trying to resolve any remaining issues like this one. Both in the original 3.2.1 and my local rewrite, the above test failure occurs on icedtea-bin-6, icedtea-bin-7, and oracle-jdk-bin-1.8. The latter also fails two other tests, whereby the order of some result is reversed. I don't have icedtea-3 to hand at the moment. I can't really explain this yet but I'll continue investigating. Okay, the tests were written for junit 3 so if I use that instead of junit 4, it passes under 7, only has two failures under 8, but still fails the same way under 6. Seriously, WTF? This appears to be a race condition. At least on 6 and 8, I've seen it randomly pass and fail. I've yet to see 7 fail. Race conditions suck. Sorted! https://github.com/antlr/stringtemplate3/pull/3 I'll include this patch in my round of improvements. Dealt with in 3.2.1-r1. I'll close when stable. Now stable. |