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

Andrew Hughes ahughes at redhat.com
Thu Aug 16 09:32:11 PDT 2012

----- 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

More information about the nio-dev mailing list