Re: Backwards compatibility issue?
On 01/06/2013, at 1:23 AM, David Grieve david.gri...@oracle.com wrote: I won't take you up on that bet. I hate to lose. If the jar file has the .css file in it, you can disabled the loading of binary css by setting the property binary.css to false. I don't know if there is a way to set logging on the command line. This is not so much a question of what can I do to fix this, as highlighting the fact that an app built on b13 and then run on b23 is utterly broken. With auto updating jre's this means someone who has an app in the wild will suddenly have it break for all their customers. Massive backwards compatibility problem between minor build releases is not good for any of us. As an aside, from memory I don't think the original CSS is included in the jar by the packaging tools but I haven't checked. What's so horrid about css to bss compiling? A) It's broken B) What's the point? Not trying to be unduly critical but is it for some performance gain or something? Surely the load time is minimal. Given that I have a dozen XML config files, a handful of property files and a thousand FXML files that are being loaded by my app it seems like a whole lot of extra complexity and space for bugs to crawl in for no gain. Maybe I'm missing some benefit of this? On May 31, 2013, at 11:11 AM, Daniel Zwolenski zon...@gmail.com wrote: Can I set this using a system property or similar? This is a built jar and the fact that it was built with an older version of the jdk is part of the scenario. The packaging tools were used to assemble this jar and by default they do that horrid CSS to BSS compiling. If I was betting man, my money would be on that. As a side comment, I defaulted this to false in the maven plugin as people reported problems with the BSS files. Note that the jar is linked to in the post if you want to do your own testing on it. On 01/06/2013, at 12:57 AM, David Grieve david.gri...@oracle.com wrote: 512 is the localized message of the exception that is being thrown, which in itself is odd. You might get more info if you set the CSS logger to INFO. Assuming this is JavaFX 2.2.x, you can set the CSS logging level via: com.sun.javafx.Logging.getCSSLogger().setLevel(com.sun.javafx.logging.PlatformLogger.INFO) On May 31, 2013, at 12:27 AM, Daniel Zwolenski zon...@gmail.com wrote: No stack trace, just this: C:\tempc:\apps\java\jdk1.7.0_21-32bit\bin\java.exe -jar defender-jfx.jar Cannot add stylesheet. 512 If there's an easy way to turn on more debugging info let me know. On Fri, May 31, 2013 at 2:07 PM, Richard Bair richard.b...@oracle.comwrote: Possibly, what is the stack trace? On May 30, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote: While trying to narrow down the rendering/performance/whatever issues with the game, I just opened up the JAR that I'd previously built for it: https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar If I run this with java version 1.7.0_13 it works fine. If I run this with java version 1.7.0_21 none of the styles get loaded. Massive backwards compatibility fail between minor build versions?
Re: Backwards compatibility issue?
Hmm. I see this from the very first build of 7u21 (only available internally) whereas the latest build of 7u17 is fine. I did find one CSS fix from David that looks like it was in that build and relates to the way CSS is doing class lookups. So I think that is the most likely culprit. -phil. On 5/30/2013 9:27 PM, Daniel Zwolenski wrote: No stack trace, just this: C:\tempc:\apps\java\jdk1.7.0_21-32bit\bin\java.exe -jar defender-jfx.jar Cannot add stylesheet. 512 If there's an easy way to turn on more debugging info let me know. On Fri, May 31, 2013 at 2:07 PM, Richard Bair richard.b...@oracle.comwrote: Possibly, what is the stack trace? On May 30, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote: While trying to narrow down the rendering/performance/whatever issues with the game, I just opened up the JAR that I'd previously built for it: https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar If I run this with java version 1.7.0_13 it works fine. If I run this with java version 1.7.0_21 none of the styles get loaded. Massive backwards compatibility fail between minor build versions?
Re: Backwards compatibility issue?
This is not so much a question of what can I do to fix this, as highlighting the fact that an app built on b13 and then run on b23 is utterly broken. With auto updating jre's this means someone who has an app in the wild will suddenly have it break for all their customers. Massive backwards compatibility problem between minor build releases is not good for any of us. As an aside, from memory I don't think the original CSS is included in the jar by the packaging tools but I haven't checked. I can confirm that there was a change in the format of the bss file. I can only promise to be more careful in the future. Sounds like this needs to be fixed in the next 7 update because as Daniel says, we're completely breaking existing apps. Also, we need to get a test in place to catch this in the future (will need to check into the repo a bss file produced on, say 2.0 and then we just have a test which deserializes it during the test run). Richard
Re: Backwards compatibility issue?
the JIRA mentioned is not public - we the e(fx)clipse project are working on such a feature as well for one of our next releases - so if openjfx does provide it we could spend our time on other important improvements! Tom On 31.05.13 19:54, Richard Bair wrote: What's so horrid about css to bss compiling? A) It's broken B) What's the point? Not trying to be unduly critical but is it for some performance gain or something? Surely the load time is minimal. Given that I have a dozen XML config files, a handful of property files and a thousand FXML files that are being loaded by my app it seems like a whole lot of extra complexity and space for bugs to crawl in for no gain. Maybe I'm missing some benefit of this? The benefit is performance. It is much faster to deserialize the binary format than to invoke the parser. And we're talking orders of magnitude here. And don't forget about iOS / Android / PI / Beagle / and friends. We didn't do bss because we thought it was cool, I can promise you that. Neither are we looking at compiling FXML into class files (RT-23527) for the fun of it ;-).
Re: Backwards compatibility issue?
Possibly, what is the stack trace? On May 30, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote: While trying to narrow down the rendering/performance/whatever issues with the game, I just opened up the JAR that I'd previously built for it: https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar If I run this with java version 1.7.0_13 it works fine. If I run this with java version 1.7.0_21 none of the styles get loaded. Massive backwards compatibility fail between minor build versions?
Re: Backwards compatibility issue?
No stack trace, just this: C:\tempc:\apps\java\jdk1.7.0_21-32bit\bin\java.exe -jar defender-jfx.jar Cannot add stylesheet. 512 If there's an easy way to turn on more debugging info let me know. On Fri, May 31, 2013 at 2:07 PM, Richard Bair richard.b...@oracle.comwrote: Possibly, what is the stack trace? On May 30, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote: While trying to narrow down the rendering/performance/whatever issues with the game, I just opened up the JAR that I'd previously built for it: https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar If I run this with java version 1.7.0_13 it works fine. If I run this with java version 1.7.0_21 none of the styles get loaded. Massive backwards compatibility fail between minor build versions?
