7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code
Andrew Hughes
ahughes at redhat.com
Thu Aug 23 07:35:20 PDT 2012
----- Original Message -----
> (apologies for the delay replying to you, lots of things on my plate
> at
> the moment).
>
It's ok. There's no rush. I was just wondering if it had got lost in the tubes.
> 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.
True. This actually sounds very much like cleanup work that could be a
good introduction for new OpenJDK developers. There's not any real
code that's got to be written. It just needs someone to find the
Solaris/Linux/etc.-specific code, break it out into new files and
test the result heavily. At least, that's the impression I get.
>
> > :
> > 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).
Sure, I can write something up. I'm pretty much in the dark as the best
package name to choose though (I wasn't aware of the significance of sun.misc
either way). I'm looking for something that would be usable by code in
the NIO, net and AWT packages. Any ideas?
> >
> > 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).
>
Ah, right. I didn't see that.
> -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