|2087||0||DEFECT||triage||P4||stevenknight||Jar builder cannot handle local classes|
|Gary||1.x||Could even expose some method for users to fix this themselves if/when Java changes their naming. Otherwise this will just be ongoing maintenance.|
|Greg||1.x||???||Rob?||It wouldn't surprise me if the naming conventions were different with each version of Java, so it might be useful to make this work by only tracking the primary class file and picking up the other names dynamically with a pattern match.|
Steven: I don't believe Mark Flacy is a Python programmer.
|Steven||1.x||Mark Flacy?||Possibly a difference in names with different Java versions, like the difference in the file names for anonymous classes between 1.4 and 1.5 (IIRC). I like very much Gary's idea about exposing an API to let users configure this.|
|2088||0||DEFECT||triage||P4||stevenknight||5 and 6 as well as 1.5 and 1.6 should be valid Java versions in Java builder|
|Gary||Greg: Not me, I'm not a Java guy at all. What's the impact of this not working?|
|Greg||Gary?||This is only to be compatable with Java tools, so I can't see much urgency. If Gary can take it, let him set the priority, otherwise I'd think 1.x p5 or 2.x p2.|
Gary: didn't you just fix the logic having to do with the valid Java version IDs? If so, that makes you the expert. The impact of it not working is that SCons won't recognize '5' as a alias for '1.5' as Java tools apparently do, i.e., a nuisance, not a defect.
|Steven||1.x||p4||anyone||This is pretty trivial, just about anyone could do it. Just have to add "5" and "6" as aliases in the right dict (and add appropriate tests/doc of course).|
|2089||0||DEFECT||triage||P4||stevenknight||Java source and target versions appear not to work|
|Gary||This looks very related to 2088. Is it just a matter of passing the version as a compiler option?|
|Greg||I don't know what this would require or how much effort it would take, so I'm clueless. There is some logic in the code that makes 1.4 a special case, so maybe the fix is as simple as making it '1.4 or later' (we know from the 2088 that 1.5 and 1.6 now exist), or it could be something open-ended between versions, so that we'd have to track which version created a give .class file and recompile when it changes. Maybe Rob could research it and report back?|
Gary: I believe it has to do both with selecting the compiler and with version-specific differences in the .class files (guessed from looking at how JAVAVERSION is used within the code).
|Steven||research||russel||This really needs more info. I think russel expected it to select one version of the compiler vs. another, but the documentation says very specifically that it does *not* select one compiler or another, but you should set it to reflect the version that your compiler is. He implies that the same code can work on 1.4/1.5, which is kind of true, but the issue is that our Java parser needs to know the version so it gets the anonymous class file names right. If you don't have anonymous classes, then it will work on either. I'll update this with a request for Russel to provide more specific info, and this should ultimately go to him or Mark Flacy or whoever gets to be the Java guru.|
|2090||0||DEFECT||triage||P4||stevenknight||Java builder forces an incorrect file encoding.|
|Gary||1.x||Agree w/ Greg that we shouldn't depend on external env where possible, but these days LANG is expected to be set just like HOME, so various tools are starting to count on it. Doc at least I guess, but maybe even a warning: "Compiling Java without LANG set may produce incorrect results. Please set it in your SConscript to avoid this warning." But I think 1.x is OK.|
|Greg||doc 1.0?||???||After thinking about this, I think LANG should be explicitly set by the SConscript, but it would be worth mentioning in the manual that it should be set to the encoding used (i.e., set to 'utf-8' instead of os.environ('LANG')).|
Gary: I considered a scenario where a program is created with one LANG and then someone with a different LANG tries to build it. The SConscript had better set the correct LANG specifically or the package may not build.
|Steven||1.x||p3||Looks like we need to split this into multiple issues: one for general documentation of the LANG issue w.r.t. Java (part of that section of the User's Guide, probably), and one for what we need to do. I like the idea of a warning if they're building Java and not setting it.|
|2091||0||DEFECT||triage||P4||stevenknight||Shouldn't AppendUnique remove the leftmost instead of the rightmost ?|
|Gary||1.x||p3||I think AppendUnique should always keep the rightmost, and PrependUnique should keep the leftmost, and all uses of these should be inspected to see which to use. To append but only if not in the list, use python. Or if it's decided that's too hard e.g. because of looking inside sublists, then Append/PrependUnique could take a new arg "keep_existing".|
|Greg||My opinion is in the issue. Depending upon what we choose to do, this could be triaged in a number of different places.|
Gary: Unless you're proposing to change existing semantics, I think you got it backwards, but an optional argument is a good idea.
|Steven||1.x||p3||Optional argument++. Agree with keeping the current semantics (AppendUnique keeps leftmost, that is, doesn't append if the value already exists, andPrependUnique keeps rightmost, that is, doesn't prepend if the value already exists).|
|2093||0||DEFECT||triage||P4||stevenknight||discrepancy in scons doc for LDMODULESUFFIX on darwin (set to $SHLIBSUFFIX , not NULL)|
|Gary||1.0||Gary||I'll take it. It should not be .bundle, that's for the top-level bundle dir, and this is for building the binary that goes into the bundle. There are actually no name restrictions on what the binary should be called. I think the doc should just be adjusted.|
|Greg||1.0 if possible||???||Gary?||Gary wrote LoadableModule(); he should know what it's supposed to do. (And I thought it did set the suffix to '.bundle' at one point; has this changed?) It shouldn't be destabilizing, so we should try to get it in 1.0 if we can, otherwise 1.x p2.|
|2094||0||DEFECT||triage||P4||stevenknight||cannot interrupt printing of --tree= output|
|Gary||1.x||p3||Not a huge issue for most users, 1.x is fine.|
|Greg||1.x||???||Benoit||Potentially very destabilizing; not a candidate for 1.0. I'm glad I'm not slogging through this terrain!|
|Steven||1.x||p5||Benoit||Minor annoyance, so P5.|