On May 31, 2013, at 11:38 AM, Daniel Zwolenski <zon...@gmail.com> wrote:
> 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. 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. > > >> 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. > > >> >> 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? >>>>>> >>>>>> >>>> >>
