Project Proposal: BSD port

Mike Swingler swingler at
Wed Aug 6 16:11:31 UTC 2008

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/
>  It seems that it could as easily be
>    src/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp
>    src/classes/sun/awt/windows/
>    ...
>  (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 ( 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.

Mike Swingler
Java Runtime Engineer
Apple Inc.

More information about the discuss mailing list