dev build 200407270649
JDK 5.0 beta3-b59
1) Open Project
2) Exception is thrown (attached)
Created attachment 16490 [details]
Exception that is thrown
Upgrading to P1 since exception is shown every time you go down a
directory in the file chooser dialog. Highly annoying!
Gili, please attach the log file <userdir>/var/log/messages.log
Created attachment 16491 [details]
The relevant messages.log
Added additional message.
Revision 1.104 /cvs/openide/src/org/openide/filesystems/FileUtil.java
Please test with this revision of FileUtil and then attach log file.
I'm not able to reproduce. Messages in you log file has only
informative character and shouldn't be harmful. Then priority
decreaesed to P2.
*** Issue 45629 has been marked as a duplicate of this issue. ***
*** Issue 46706 has been marked as a duplicate of this issue. ***
JFileChooser impl. on Windows provides
sun.awt.shell.Win32ShellFolder2. Folowing assertions are true for some
instances of Win32ShellFolder2:
Win32ShellFolder2.toURI ().getAuthority() == null;
Win32ShellFolder2.toURI ().toURL ().getAuthority() != null;
Then following call fires IllegalArgumentException because no
authority is excpected:
URI.create(Win32ShellFolder2.toURI ().toURL ().toExternalForm())
The problem occures for files with path defined according UNC (at
least I think it is so called e.g. \\saaaf004\homes\olscha2\My Documents)
Sorry, IllegalArgumentException is fired if you need to get back File:
new File (URI.create(Win32ShellFolder2.toURI ().toURL
In other words. The problem occures if you get Win32ShellFolder2
convert it to URL and then back to File.
Correct me if I'm wrong, but isn't this a JDK/specification bug?
Shouldn't this be impossible? If so, we should file a bug against JDK
5.0 immediately because as far as I can tell they are about to release
the final version.
Maybe but I think its a though thing because UNC pathes has difficult
URL interpretation with file protocol. (e.g.
Definitely current MasterFileObject isn't designed to support UNC
pathes anyway (and there isn't planned to support it ). Now there
isn't possible conversion from File to FileObject + reported exception
is fired for informative purposes. If there was urgently needed to
acces files on different hostes via our filesystems then there is
possible use UNC path and map it to regular windows drive just in
I think that sufficient fix is to suppres exceptions that uselessly
/cvs/openide/src/org/openide/filesystems/FileUtil.java,v <-- new
revision: 1.105; previous revision: 1.104
Radek it sounds to me like a JRE bug if a URL such as
is created from File.toURI. Shouldn't it be e.g.
or something along those lines?
At least, it sounds like a JRE bug if
Radek, in my case \\saaaf004\homes\olscha2\My Documents is a local
offline folder, if I'm connected to the network in our company these
files will be syncronized with the share on the server. Unplugged I
can use it as normal local folder (My Documents), but I can't access
those files to map it to some drive letter, as you suggested.
So working offline I won't be able to access those files via
Netbeans, what works well with 3.6
This is a common scenario among companies working with Windows-
Clients, so this issue isn't fixed for me.
gaucho72: your problem should probably be filed as a fresh bug, just
mention this one by number.
Guys, how is this issue "fixed"? Supressing exceptions is nice and all
but it does not fix the underlying problem. Shouldn't someone in the
Netbeans team file a JDK bug before JDK 5.0 goes final?
Gili, I file JDK bug (moreover there is definitely possible to
workaround it) but impl. of MasterFileSystem doesn't support UNC names
anyway and I don't plan to add this support for promo-D because I
don't want to destabilize MasterFileSystem code. Its stability is
relatively crucial for the whole product and I think we can live
without support for "Make available offline" functionality on Windows.
Again: a separate bug report should IMHO be filed about lack of
support for UNC names, so this can be tracked separately.
it already was
Issue #46813, specifically.
*** Issue 45882 has been marked as a duplicate of this issue. ***
*** Issue 46975 has been marked as a duplicate of this issue. ***
verified in NB 5.0