[Plastic-devs] file-scheme URLs again

[Mark T. <m.b...@br...>]

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

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/