Image class and paths relative to classpath

Tom Schindl tom.schindl at bestsolution.at
Tue Apr 24 01:11:51 PDT 2012


Having support for stuff like classpath, ... is curcial to OSGi so a big
+1 because when someone uses URL systems can install Protocol handlers.

The problem for OSGi-Applications is that a FQN includes the bundle name
(you can think of it as the name of th jar). I've already put some of
those informations in a more detailed form in to the mail thread "Patch:
issue RT-14177" so my favorite is making use of protocols.

Tom

Am 24.04.12 09:32, schrieb Martin Sladecek:
> I agree, would be also more natural for CSS, as currently we just use
> url() construct when referring to an image in CSS, so it would look like:
> 
> -fx-image: url("classpath:/app/image.jpg")
> 
> -Martin
> 
> On 04/24/2012 09:12 AM, Daniel Zwolenski wrote:
>> True. On the other hand classpath uri does allow you to use an
>> externally configured URL (eg loaded from a properties file) and this
>> can change without code changing.
>>
>> Eg in my app I might have the default image URL load off the classpath
>> but then someone wants to reference an image on the web and they can
>> just change the url setting. No need for a code change.
>>
>> Fairly common scenario for me anyway. I'd love to see classpath uri
>> supported across the board. FXML, image, CSS, etc.
>>
>> There's some interesting stuff on this here:
>>
>> http://stackoverflow.com/questions/861500/url-to-load-resources-from-the-classpath-in-java
>>
>>
>>
>> On 24/04/2012, at 2:20 PM, Martin
>> Sladecek<martin.sladecek at oracle.com>  wrote:
>>
>>> I have no strong preference, classpath URI scheme is one of the
>>> options we may use. The only downside of this approach I see is that
>>> people will have to read through the Image's constructor javadoc to
>>> find out that there's this option.
>>>
>>> -Martin
>>>
>>> On 04/23/2012 05:37 PM, Daniel Zwolenski wrote:
>>>> An alternative to the separate method is to define a 'classpath'
>>>> protocol as part of the URL:
>>>>
>>>> Image image = new Image("classpath:/foo/bar.png");
>>>>
>>>> This is common in Spring and seems quite nice to me. It has the
>>>> advantage of working with constructors and is fully backwards
>>>> compatible.
>>>>
>>>> I could live with a new method if that was the preference though.
>>>>
>>>>
>>>> On 23/04/2012, at 10:58 PM, Martin
>>>> Sladecek<martin.sladecek at oracle.com>   wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> JIRA: http://javafx-jira.kenai.com/browse/RT-18291
>>>>>
>>>>> this JIRA request is about adding support for "URL" in Image
>>>>> constructor that is interpreted as a classpath-relative path when a
>>>>> leading slash is present.
>>>>> However, this is currently interpreted as absolute file URL.
>>>>>
>>>>> In order not to break current behaviour I propose to introduce new
>>>>> set of static factory methods.
>>>>>
>>>>> Image.fromClassPath(String path, double requestedWidth, double
>>>>> requestedHeight, boolean preserveRatio, boolean smooth, boolean
>>>>> backgroundLoading);
>>>>>
>>>>> + overloaded method similar to Image constructors.
>>>>>
>>>>> The idea is to interpret paths with leading slash as absolute to
>>>>> the classpath root (basically the same as
>>>>> Thread.currentThread().getContextClassLoader().getResource(path) ),
>>>>> while relative paths might be interpreted as relative to the caller
>>>>> class. So Image.fromClassPath("duke.jpg") called from
>>>>> myapplication.Application will look for the file in myapplication
>>>>> package.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -Martin
> 


-- 
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 mailing list