Re: Project Proposal: BSD port
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Project Proposal: BSD port
by Dalibor Topic-5
::
Rate this Message:
Rob Ross wrote:
> So one could download OpenJDK and build it on a Mac (with the suitable > hardware and OS version), and run it there as well? But this would be > totally in "unix" land, e.g., using X11 for the UI, BSD libraries for > the system calls, etc? > > Is this correct? Yes. > If so, what would be the logical next steps (after this project has a > stable build) in order to add a native Mac OS X port to the OpenJDK, > using for example, native Cocoa code (or Core Graphics?) for rendering > the UI? I'm not an AWT guy, but Roman Kennke and Mario Torre hacking on the Cacciocavallo project may be able to help figure out how to plug into the existing architecture. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic@... Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring |
|
|
|
|
|
Re: Project Proposal: BSD port
by Volker Simonis
::
Rate this Message:
On 8/2/08, Rob Ross <rob.ross@...> 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. > So one could download OpenJDK and build it on a Mac (with the suitable > hardware and OS version), and run it there as well? But this would be > totally in "unix" land, e.g., using X11 for the UI, BSD libraries for the > system calls, etc? > > Is this correct? > > If so, what would be the logical next steps (after this project has a stable > build) in order to add a native Mac OS X port to the OpenJDK, using for > example, native Cocoa code (or Core Graphics?) for rendering the UI? > > > 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 1, 2008, at 11:27 AM, Dalibor Topic wrote: > > > In accordance with the OpenJDK guidelines for projects [1], > > I hereby propose on behalf of Greg Lewis, Kurt Miller and Landon Fuller > > an OpenJDK Project "BSD port of OpenJDK". > > > > This Project will be used for the development of a port of OpenJDK to > > the BSD family of operating systems, including FreeBSD, OpenBSD, NetBSD > > and MacOS X.[2]. > > > > I propose this project be sponsored by the Porters Group [3] and > > that I be the initial moderator of the project. > > > > cheers, > > dalibor topic > > > > [1] http://openjdk.java.net/projects/ > > [2] > http://mail.openjdk.java.net/pipermail/porters-dev/2008-July/000170.html > > [3] http://openjdk.java.net/groups/porters/ > > > > -- > > > ******************************************************************* > > Dalibor Topic Tel: (+49 40) 23 646 738 > > Java F/OSS Ambassador AIM: robiladonaim > > Sun Microsystems GmbH Mobile: (+49 177) 2664 192 > > Nagelsweg 55 http://openjdk.java.net > > D-20097 Hamburg mailto:Dalibor.Topic@... > > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > > Amtsgericht München: HRB 161028 > > Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer > > Vorsitzender des Aufsichtsrates: Martin Häring > > > > > > > > |
|
|
Re: Project Proposal: BSD port
by Martin Buchholz-3
::
Rate this Message:
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@...> wrote: > On 8/2/08, Rob Ross <rob.ross@...> 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. |
|
|
Re: Project Proposal: BSD port
by Kelly O'Hair
::
Rate this Message:
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@...> wrote: >> On 8/2/08, Rob Ross <rob.ross@...> 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. |
|
|
Re: Project Proposal: BSD port
by Rob Ross-3
::
Rate this Message:
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@...> wrote: >>> On 8/2/08, Rob Ross <rob.ross@...> 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. |
|
|
Re: Project Proposal: BSD port
by Dmitri Trembovetski
::
Rate this Message:
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. Thanks, Dmitri |
|
|
Re: Project Proposal: BSD port
by Mike Swingler
::
Rate this Message:
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. |
|
|
Re: Project Proposal: BSD port
by Kelly O'Hair
::
Rate this Message:
Good points.
A while back I changed code that was ifdef'd on the platform changed to being ifdef'd on _LITTLE_ENDIAN, just made more sense and the code was easier to understand. Changing the ifdef's to specific features rather than making it a platform thing makes sense. So I agree with your X11 comment. And also agree that we don't want to deliver classes to a platform that doesn't need them. -kto Mike Swingler 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. |
|
|
Re: Project Proposal: BSD port
by Volker Simonis
::
Rate this Message:
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@...> 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. > |
|
|
Re: Project Proposal: BSD port
by gnu_andrew
::
Rate this Message:
2008/8/7 Volker Simonis <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 > Better to agreed than have a different schema per group to contend with, which would just add to confusion, especially with those outside Sun where these groups aren't as established concepts. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
| Free Forum Powered by Nabble | Forum Help |
