Project Proposal: BSD port

Tue Aug 5 22:43:00 UTC 2008

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.

But if you think about the differences between Windows, Mac OS, and  
*nix X11 native code for things like GUI or file-system access, I  
think these kinds of differences probably warrant their own  
directories. The code to render a native window is going to be quite  
different on these three platforms. It's not just a platform  
statement variation, you're calling native APIs that may only exist  
on one platform. So in cases like these, it makes sense to me to keep  
the code separate. I do like that the actual "low level" Java  
implementation is defined by private Java classes, that then call  
native methods to do to actual platform specific work. Thus there  
would still be need of having Java classes in these platform-specific  
directories, as the bridge between the higher level public Java APIs  
and the low-level native methods that eventually implement them. GUI  
code is the obvious example here, and there are certainly others -  
audio perhaps? But then again, maybe this list isn't actually as long  
as I think it is right now.

Rob Ross, Lead Software Engineer
E! Networks

---------------------------------------------------
"Beware of he who would deny you access to information, for in his  
heart he dreams himself your master." -- Commissioner Pravin Lal

On Aug 5, 2008, at 11:11 AM, Kelly O'Hair wrote:

> I think I'm mostly in agreement with Martin here.
> Hotspot is different, and I'm not speaking to that, just what is
> in the jdk7/jdk repository.
>
> I have tried over time to make any C code I see be standard conforming
> and avoided using the src/windows and src/solaris directories,  
> favoring
> using the src/share area for as much as possible.
> I don't have the history on why the share vs. solaris vs. linux vs.  
> windows
> separations were originally created and populated, I think someone  
> with some
> ancient jdk history might speak to the real meaning of "share".
> I've treated "share" as "generic" code.
>
> I myself would prefer to have one implementation source file with a  
> clean
> #ifdef approach rather than copied sources, but that's just me.
> I prefer to see all the implementations of a function in one file.
>
> However, I've adapted and over the years have experimented with many
> ways to do this.
>
> A couple of small examples in the OpenJDK sources I am familiar with:
>
> hprof, hprof_md.h is in the share area, and it's implemention is  
> split:
>
> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/demo/ 
> jvmti/hprof/hprof_md.h
> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/demo/ 
> jvmti/hprof/hprof_md.c
> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/demo/ 
> jvmti/hprof/hprof_md.c
>
>   Note the #ifdef LINUX used in the solaris file.
>
> backend (backend to debugger), has different *_md.h files and  
> implementations:
>
> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/back/
> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/back/
>
>   Note that the share source is actually #including different files  
> and could
>   be influenced by those files doing different #includes.
>   I liked the hprof approach better, but I ended up with ONE file  
> in each
>   of the src/windows/demo/jvmti/hprof and src/solaris/demo/jvmti/hprof
>   directories. And I'd hate to see this file replicated again.
>
> How valuable is it to have completely different root source trees  
> for windows and solaris?
> Could one file with a huge #ifdef in it been any better?
> Or just *_windows.c and *_posix.c names on the files and keep them  
> in one src tree?
>
> Just making the observations, I have no great answers...
>
> -kto
>
>
> Martin Buchholz wrote:
>> I mostly agree with Volker.
>> The JDK code base has historically been targeted at a
>> small number (like 10) of very specific build environments.
>> The "must be windows or solaris or linux" assumption
>> is a big one, but just one of many.
>> Introducing a configure step is probably the right idea.
>> The BSD port is a fine time to make OpenJDK at least
>> more generally portable to any kind of Unix.
>> BSD porters: Please don't just add else-if-BSD everywhere.
>> On the other hand, I don't dislike #ifdefs as much as
>> others (e.g. Volker) do.  They need to be isolated, certainly,
>> but with careful coding they have their place.
>> I think #ifdefs are very much preferable to copying the
>> entire src/solaris tree to src/bsd, for example.
>> Unfortunately, there seems to be no way to change the
>> portability layer of OpenJDK without introducing some instability.
>> Good pre-integration testing is key.
>> Martin
>> On Sat, Aug 2, 2008 at 1:14 AM, Volker Simonis  
>> <volker.simonis at gmail.com> wrote:
>>> On 8/2/08, Rob Ross <rob.ross at gmail.com> wrote:
>>>> I'm trying to clarify my understanding of what this means for a  
>>>> Mac-native
>>>> version of OpenJDK.
>>>>
>>>> One of the implementation details of this project will be, for  
>>>> example, the
>>>> addition of a "BSD" directory under .../jdk/src/, to go along  
>>>> with the
>>>> existing "linux", "solaris", "windows", folders.
>>>>
>>>> Is this correct?
>>>>
>>> I think this is a crucial question and the answer is not as clear as
>>> it may seem at a first glance. The problem is, that currently the
>>> "linux" directory contains only the Linux man-pages while the
>>> "solaris" directory contains all the "*nix" coding. While Linux and
>>> Solaris obviously share a great amount of code, the differences
>>> between the systems are factored out by numerous "ifdef" cascades.
>>> There are also a lot of places in the code which implicitely assume
>>> that the code is onlycompiled on Solaris and Linux (e.g. "ifndef
>>> SOLARIS" is used as a marker for Linux).
>>>
>>> Now that many new ports are created, I think this code organization
>>> should be seriously reconsidered, because:
>>>
>>> - if every port just changes the existing "solaris" source tree and
>>> inserts just one more cascade of platform specific macros it will
>>> become impossible to merge two or more of these ports together (i.e.
>>> to have one source repository which builds on every supported
>>> platform). But I think t his must be the final goal - having one
>>> source repository which contains as many ports as possible.
>>>
>>> - if every port makes a copy of the current solaris directory (i.e.
>>> the "bsd" directory in this context) this would make merging  
>>> different
>>> ports easier. But it would also lead to a considerable amount of  
>>> code
>>> duplication and maintaining the new ports would be a nightmare,
>>> because any changes to the original "solaris" directory, would  
>>> have to
>>> be integrated in all the copies for the different ports.
>>>
>>> So in my opinion, the right way to go would be to factor out the
>>> common "*nix" code into a generic, say "Posix" directory and let the
>>> different platform directories ("solaris", "linix", "bsd", "haiku",
>>> ...) only contain the differences with regard to the common "Posix"
>>> directory (much like the "hotspot" directory is organized into a
>>> "shared", "cpu", "os" and "os_cpu" part).
>>>
>>> The drawback of this solution is that it would require a  
>>> considerable
>>> amount of work (and a lot of work from Sun) because the code for the
>>> Solaris and Linux ports would have to be changed.
>>>
>>> Probably it would be wise, if the porters group would sponsor  
>>> such an
>>> effort in the first place, if it is really interested in having many
>>> stable platform ports in the future.