Project Proposal: BSD port

[Volker Simonis]

Yea, these are good points.

If we take into account that the code in the j2se directory is
maintained by several different groups (i.e. AWT, Core Libraries,
Networking, Sound, ...) it may be perhaps even usefull to rearrange
the platform dependant code in such a way that the first level of
subdirectories inside the "j2se" directory denotes the specific group.
Every group could than decide for itself, how it wants to handle the
platform specific differences. Otherwise, all groups involved would
have to agree on a new schema which I imagine could be quite
difficult...

I know this means even more changes, but perhaps it's the right time
to do them now, if there is a common consense on changing the
structure of the j2se project anyway.

Regards,
Volker

On 8/6/08, Mike Swingler <swingler at apple.com> wrote:
> On Aug 5, 2008, at 4:01 PM, Dmitri Trembovetski wrote:
>
> > Rob Ross wrote:
> >
> >
> > > I can't comment on whether it's better to have all *nix statement
> variants be wrapped in #ifdefs or placed in their own platform-specific
> folder. It's probably a judgment call on whether platform-specific
> variations are different enough to warrant their own directory structure.
> > >
> >
> >  I agree, but they don't need to have different roots as they are now.
> >
> >  Currently we have weird stuff similar to this:
> >
> jdk/src/windows/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp
> >
> jdk/src/windows/classes/sun/awt/windows/Win32GraphicsDevice.java
> >
> >  It seems that it could as easily be
> >   src/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp
> >   src/classes/sun/awt/windows/Win32GraphicsDevice.java
> >   ...
> >  (I'd even remove 'shared')
> >
> >  The native code for the most part mimics the java packages
> >  names, so if a package is platform-specific, it should probably
> >  have the platform in its name (sun.awt.windows in this case, or
> >  sun.awt.nix or whatever). The native code's structure would
> >  naturally follow the java package naming.
> >
> >  For cases where the package name is the same on different
> >  platform but the native code is different we could follow
> >  Kelly's approach and/or use ifdef-ing.
> >
> >  I do realize that such changes would be a huge pain though.
> >  Especially for those of us who still need to support
> >  earlier releases and port fixes from one tree to another.
> >
>
> I think the ideal thing to do would be to clearly discriminate in the
> directory structure exactly what difference is between the platforms. If the
> difference is X11, then create an x11 directory (because not all *nix's are
> going to be based on X11). If the difference is Win32 vs. Posix threading
> and file system operations, there should be a win32 and posix directory for
> that sub-system. The same should be true for fonts, OpenGL work, or any
> other system where discrimination does not cleanly cleave down platform
> lines. #ifdef'ing should only be reserved for situations where the code is
> largely similar, but requires just a tweak one way or the other (like 32 vs.
> 64-bit).
>
> Glomming all the classes together in the same pot and removing the 'shared'
> directory will encourage everyone to just "compile all the classes", and
> toss them into the same jar, and ship classes that make no sense on for that
> platform. Any accessory or utility classes that don't result in a runtime
> link error only increase the security surface area of attack.
>
> Thoughts?
> Mike Swingler
> Java Runtime Engineer
> Apple Inc.
>