7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code

[Andrew Hughes]

----- Original Message -----
> On 15/08/2012 19:29, Andrew Hughes wrote:
> > :
> > It's ok by me.  I'm not sure how common it is either (fairly rare I
> > would
> > have thought).  I would guess it's much more common on *BSD (it's
> > certainly
> > in FreeBSD's ports, as is GNOME), but that platform doesn't seem to
> > be supported
> > anyway.  FileSystemProvider's create method will throw an
> > AssertionError rather
> > than returning the provider, which seems to be there just as a base
> > for the MacOS X
> > one.
> I think most of the BSD port came into the jdk8 and jdk7u forests as
> part of the Mac port but there is a lot of inconsistencies. To my
> knowledge, BSD isn't supported in the main forests and that there are
> still patches and changes in the down-stream bsd porting project. In
> this specific case I think the right thing to do is to add
> src/bsd/classes/sun/nio/fs/DefaultFileSystemprovider.java to create
> the
> BSD provider. At least the assertion error "Platform not recognized"
> will serve as a reminder to porters.

Yeah, that's what I gathered from studying the code.  The BSD bits that
have actually been added are just enough to make the MacOS ones work.

> Of course this also brings up
> the
> topic of having code for several platforms in src/solaris. We've been
> kicking that can down the road for several years but  that's a bigger
> topic.

I don't think this is a huge issue.  I tend to just read solaris in that
context as posix.  It seems we now have a macosx one with plenty of code
in, but then they have all this proprietary GUI stuff.  The POSIX APIs
shouldn't differ that much.  From what I could see, the PPC-AIX folks
have managed to get the JDK building on AIX just by altering the solaris
code slightly.

> 
> > Sure.  It's not so much of an issue with NIO, but GIO/Glib will
> > also need to be used
> > to replace GConf in sun.net.spi.DefaultProxySelector, so perhaps
> > it's worth seeing
> > the two could be unified in some way, rather than having a search
> > for GIO at two
> > different places in the codebase.
> >
> I agree we shouldn't have to duplicate code to search for GIO but we
> also have to be careful with dependencies between given parts of the
> JDK
> code. I would suggest coming up with a proposal and we can discuss it
> in
> more detail. On net-dev there are periodic issues with the default
> proxy
> selector code and I completely agree this needs attention too.

Ok, what I was thinking was something like the following.  I can draft
some code if it helps, but basically the current situation is:

Current situation:

java.awt.Desktop --> GNOME-VFS

sun.net.spi.DefaultProxySelector --> GConf

sun.nio.fs.GnomeFileTypeDetector --> GIO or GNOME-VFS

Proposed solution:

Above classes all depend on a common SystemServiceProvider which determines
whether to use GIO or GNOME2 (GConf/GNOME-VFS) to provide the required functionality (GIO
in newer versions of GLib replaces all three).  We could possibly extend
this to other platforms, but cleaning up the scattered POSIX implementations
would be a start.

I'm not sure of an appropriate package; perhaps sun.misc which already includes
OSEnvironment (a pointless class at present on Solaris & Linux)?

Going through these also highlights the issue that MacOS will also presumably
try to use GConf for proxy functionality at present; I don't see anything overriding
it.  For java.awt.Desktop, support is provided in the Mac AWT implementation.

> 
> -Alan.
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07