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

[Alan Bateman]

(apologies for the delay replying to you, lots of things on my plate at 
the moment).

On 16/08/2012 17:32, Andrew Hughes wrote:
> :
>> 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.
It's a not major issue but it is one that comes up regularly, mostly 
because src/solaris requires a lot more than POSIX and because it also 
contains both Solaris and Linux specific code. If OpenJDK is going to 
take on more platforms then I do think some clean-up is required 
although it's hard to spend time on such things, and of course there is 
never a right time.

> :
> 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)?
So are you thinking about something relatively high level that hides 
whether the underlying implementation is GIO or GConf or whatever?  Or 
maybe you are thinking about a simple shim over all the above that the 
classes in the JDK could use? I think once you have some code to discuss 
then it will become clearer as to possible naming and location (my 
preference would be to not add it to sun.misc, mostly because so many 
developer think it's fair game to use anything in that package, it's 
really hard to actually remove or change things in sun.misc as a result).
>
> 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.
>
The Mac port picks up the proxy settings from the system 
(java_props_macosx.c). It's a bit different to the other platforms in 
that "use system proxy settings" is essentially enabled by default 
(which on the surface is great but also causes problems, particular for 
tests that make local connections).

-Alan.