Image class and paths relative to classpath

[Kevin Rushforth]

One thing to be aware of for a classpath URI, is that untrusted 
applications would not be able to take advantage of it. That doesn't 
mean we shouldn't do it, though.

-- Kevin


Tom Schindl wrote:
> 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
>>>>>>             
>
>
>