Handling updates to the JavaFX Caspian look
tom.schindl at bestsolution.at
Mon Apr 23 15:43:43 PDT 2012
ServiceLoader is from an OSGi PoV a tough thing to get working. This
blog post provides some background  and a solution but when I read
bytecode manipulation this sounds scary.
The main problem is that there's no TCCL in an OSGi-Context. I think in
equinox one could use so called buddy classloading to overcome the
class-path fences put up by OSGi but I need to check that, felix will
most likely fail to locate external provided themes completely.
But I don't think this is a problem because you are providing an API to
register themes so OSGi people can use OSGi-Services and register
against this API. I can provide as part of e(fx)clipse runtime a central
point to register themes which calls to your Themes#addTheme-API, OSGi
Users can add this bundle and are ready to go.
Some minor question in the API why are you is the API on Application
called setDefaultUserAgentStylesheet and not setDefaultTheme? Would it
be better to pass the themeId to the method instead of the theme and
then the internal code does the lookup for the theme and if not found
falling back to the guaranteed default one.
Am 23.04.12 23:58, schrieb Tom Schindl:
> No - the current threads context classloader is not good! I'll try to
> take a look at the patch but I'm out for 4 days starting tomorrow so it
> might take sometime.
> Am 23.04.12 22:40, schrieb Jonathan Giles:
>> Oh, I should also note that the patch included with RT-19713 uses
>> ServiceLoader to bring in any Theme instances provided by external jars,
>> etc. I would really appreciate if someone more familiar with OSGi, and
>> its classloader complexities, could provide a comment on whether using
>> the default classloader (the classloader of the current thread) is
>> correct, or whether we should be passing in a different classloader.
>> On 24/04/2012 7:59 a.m., Jonathan Giles wrote:
>>> Hi all (again),
>>> I've put up a very preliminary patch attached to RT-19713  that
>>> allows for people to set a default user agent stylesheet for their
>>> entire application. If the default stylesheet is not overridden by the
>>> developer, then they will be automatically updated to the latest
>>> stylesheet - should we ever decide to make another one. The main
>>> driver for this tweak is to prevent JavaFX user interfaces becoming
>>> stale in the same way Swing user interfaces were stuck using Metal L&F.
>>> Please, if you have time, review the comments in the jira issue itself
>>> to understand more of the problem space.
>>> Finally, as noted, this is a preliminary patch - there are tweaks to
>>> be made for sure. Already, David Grieve has commented on the Jira
>>> issue about suggested changes. I look forward to your suggestions too.
>>>  http://javafx-jira.kenai.com/browse/RT-19713
>>> -- Jonathan
>>> On 14/03/2012 12:47 p.m., Jonathan Giles wrote:
>>>> Hi all,
>>>> Today I came across the RT-19713  Jira issue I filed against
>>>> myself recently. This Jira issue basically states that we should have
>>>> API in JavaFX that allows for developers to lock down and specify a
>>>> particular default stylesheet, and if this isn't specified by the
>>>> developer, they will be automatically updated in future releases if
>>>> we ever consider changing the default style sheet. We would always
>>>> ship earlier style sheets as well, so if the preference was set, the
>>>> style sheet would be there in the jar file.
>>>> The reason why I want this feature is that I've seen tweaked caspian
>>>> style sheets (for example the one used in the upcoming Scene Builder
>>>> tool) that I would one day love to be the default style sheet for
>>>> JavaFX as it (in my opinion) is more refined. Similarly, I don't
>>>> think anyone wants to end up in the same situation as Swing, where
>>>> the default L&F is Metal, because moving the default to a more modern
>>>> L&F would potentially break (or at least maim) many deployed Swing
>>>> Ideally we would have had API like this from the get-go, but alas, it
>>>> did not happen. Adding API now that by default auto-updates people is
>>>> of course breaking a contract we have with developers, but I feel
>>>> that it is better to break this contract now than to forever wish
>>>> that we could provide a new style sheet and never be able to do it. I
>>>> think the main thing is to communicate this change as loudly and from
>>>> as many roof tops as possible. Perhaps there are others on this list
>>>> that disagree and have different opinions. Feel free to share them.
>>>> Finally, as of now, there is no intention to ship an updated style
>>>> sheet that would replace the default, but I'm looking ahead to future
>>>> releases where this may be desired. Perhaps JavaFX 3.0 may include a
>>>> visual refresh, for example. If anyone has any thoughts on this
>>>> proposal, please reply on this thread (and preferably also leave a
>>>> comment on the Jira issue). I don't have any proposed API for this
>>>> issue, but if anyone has any thoughts on this, please feel free to
>>>> share them also.
>>>>  http://javafx-jira.kenai.com/browse/RT-19713
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
tom schindl geschäftsführer/CEO
eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833
http://www.BestSolution.at phone ++43 512 935834
More information about the openjfx-dev