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:\temp>c:\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.com>wrote: >>>> >>>>> 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? >>>>> >>>>> >>> >
