Re: [Plastic-devs] file-scheme URLs again

[John T. <jon...@gm...>]

I agree that it's likely that other Java programmers will trip up on 
this, but we could put a prominent note on the core messages page 
warning people (there's already something written there....I'll just add 
a <blink></blink> around it ;-) ).
If they use a plastic client library like yours or mine this feature 
could be built in so application developers wouldn't be aware of it.

I feel it's wrong to ask the C++ers and Perlists to work around Java's 
deficiencies.

John





Mark Taylor wrote:
> On Wed, 10 May 2006, Johan Lindroos wrote:
>
>   
>> Hello Mark,
>>
>> I did some more tests, and get weird symptoms :-/
>>
>> The working version i have is when I create an URL url object from the 
>> incoming string.
>> from that i create a File object new File(url.getPath()); this works nicely
>>
>> But also the following should work.
>>
>> URL url = new URL(incoming)
>> URI uri = url.toURI();
>>
>> File file = new File(uri);
>> //program locks here without any exceptions if the url contained the 
>> localhost part, if you remove the localhost before creating the url obj 
>> it works nicely also.
>>     
>
> Yes, I get the following error there:
>
>    java.lang.IllegalArgumentException: URI has an authority component
>
> If I feed the File(URI) constructor a URI which does not contain the
> authority component (e.g. "file:///path" rather than 
> "file://localhost/path") this problem goes away.  However Java won't
> let you create URLs in this form: the result of
> new URL("file:///path").toExternalForm() is "file:/path".
>
>   
>> It seems as it's actually java that does not follow the URL standards I 
>> think.
>>     
>
> Unfortunately that's true - see 
>
>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6351751
>
> What a mess.  It seems impossible to pass around URL/URI objects 
> in any form which both conforms to RFC1738 and which Java won't 
> choke on under some circumstances.
>
> The only workarounds I can think of for this are as follows:
>
>    1.  Avoid use of the File(URI) constructor.  There may be other places
>        where similar problems crop up - we'll have to watch for these.
>
>    2.  Give in and use non-conformant file-scheme URLs in the form
>        that Java produces them (file:path); this will effectively 
>        require non-java PLASTIC applications to be prepared to 
>        deal with illegal URLs.
>
>    3.  Wait until Sun fixes it.  I suspect that might take a while 
>        because of backward compatiblity problems, and in any case 
>        this doesn't help applications running on older JVMs.
>
> 1 is probably the Right Thing To Do.  However, since new java 
> applications are going to keep tripping over this and in practice 
> it's a lot more fiddly to fix than you might think, I suspect the 
> best thing to do in practice is 2.  This requires the java 
> PLASTICers humbly to ask the non-java PLASTICers to accommodate
> the deficiencies of the J2SE.  Does anyone from either the java or 
> non-java side have an opinion on this?
>
> Mark
>
>   
>>> On Wed, 10 May 2006, Johan Lindroos wrote:
>>>
>>>  
>>>
>>>       
>>>> Hello Mark,
>>>>
>>>> I got the same problem in windows, but the problem is not due to the 
>>>> "8char" directories but the localhost part, that does not work well, 
>>>> when removing the localhost from the url before accessing the temporary 
>>>> file it works well.
>>>>
>>>> Best Regards,
>>>>  Johan
>>>>
>>>> Johan Lindroos, Software Engineer, SAMPO ESO - Data Analysis Project
>>>> P.O.Box 405, 02101 ESPOO, Finland Tel.+358-9-4572121, Mob.+358-50-3819725, Fax. +358-9-4572302
>>>> CSC - Scientific Computing Ltd. http://www.csc.fi Email: Joh...@cs...
>>>>    
>>>>
>>>>         
>>> oh lordy... the URLs generated by TOPCAT didn't used to contain the
>>> localhost part in 'file:'-type URLs, but I've done work to insert it
>>> following discussions on this list last month about correctly 
>>> formed URLs, in accordance with RFC 1738.  Now it seems that they 
>>> are not being parsed correctly.
>>>
>>> Can you tell me exactly what is failing when trying to handle such URLs?
>>>
>>> thanks
>>>
>>> Mark
>>>       
>
>