Are the build instructions same as linux or could someone help with the build instructions for Mac OS X
Usually it's not the garbage collector that is the main work needed for a port. Mostly it's the interpreter and the runtime compiler, then the parts of the code that interact with the operating system, then all the native libraries that have to be written for new graphics cards, etc. The garbage collectors are essentially platform-independent, with a few constants that change when going from 32-bit to 64-bit platforms.
while HotSpot is available if you are planning on using Java 1.4.2 or 5.0 on a release of Max OS X. However, the source code to build and compile hotspot on the PPC architechure is [b]propritary code belonging to Apple[/b]. This is what folks are "talking about". Unless of course you know where this source code exists or you've already got a code handy so we can all build and compile Mustan on OS X ;)
I don't need the whole of Java updated lockstep on OSX, but for the love of God DO NOT release another J2ME SDK that doesn't run natively on OSX!
> There is a BSD porting project, but the biggest problem
> with trying to build Mustang on Mac OS X is that first > you'll have to port HotSpot to the PowerPC
> architecture. Not a small project...
Huh... what are you talking about? Hotspot already is on Mac OSX Java. For confirmation, see:
@wholder: Wow, it seems you haven't understood whats going on at all!
2.) Apple uses Java to press money out of their customers, since otherwise they would be able to run cutting-edge java software even on OSX-10.0. Since Java-ports are dependant on newest OS's, you have no choice at all!
Looking at the difficulties that Apples got on releasing a 1.5 J2SE for their "tiger", I am realy worried about the future of Java on Mac platforms.
As discussed in a previous post, ss there any plan to go and ask Apple if they would contribute their code to the Mustand developement tree ?
I realy thing that Apple will be glad if we could get a bit of their load.
This is an really major point if we plan to revive the client side of Java with mustang.
Please, give me your mind on that.
I understand your concern about the state of Java on MacOS X. We at Sun are
planning to work more closely with Apple going forward so that future J2SE
feature releases can be ported to MacOS in a more timely fashion.
As to the possibility of the MacOS port being merged into the Mustang
source tree, I don't think that's likely to happen any time soon, largely for
business reasons although there would be some big technical obstacles too.
Thanks your your answer.
IMHO, if you plan to work more closely with Apple, at one point, somebody from the J2SE RI will have to care about the issues of OSX integration.
This means for me, integrating some (or lots) contraints from the OSX that Apple has already solved in their port. So, actually this means integrating (directly or indirectly) some of the code changes Apple has already produced. So, why not get those changes directly from them ?
Plus, strictly speeking most non-UI OSX features are unix- like. So, I don't understand what are the big deal in taking care of those issues as they could benefit Solaris and Linux build as well.
What I am think of is not a "commit them all" but a "commit your change for the RI to build on OSX in a basic mode".
As you said, for busines reason Apple might want to keep some of their genuines bricks out of this process. That is fine as we do not needs to have tight Quartz or Aqua integration as part of RI for instance. Any such "advanced" feature will still be of their perogative.
I think it is a win-win situation for both Sun and Apple :
Apple get more easy migration path to latest Java technologies (and try to compete with its arch-rival MS as a developper platform and a premium client platform), Sun get more client-side support for Java camp (more momentum for Java, more rich application in enterprises,...) .
Obviously, there are legal/IP concerns that need to be addressed but nothing that can not be solved with the existing well-define legal/IP Java context.
All is a question of motivation to revive the client side at both Sun and Apple side.
It's not porting it to *Darwin* that's the big problem. It's porting the garbage collector to the *PPC processor architecture* that takes all the work.
That's why there's no Java 5 for Linux/PPC (not even Java 1.4 yet!); it's not porting it to the OS--Java already works on Linux/x86--it's porting it to the processor that's the problem.
Well, Kaffe's GPLd GC works just fine on powerpc-linux and powerpc-darwin. If someone can convince Sun to release the RI under the GPL Sun is most welcome to merge it in and share the code.
> Are the build instructions same as linux or could
> someone help with the build instructions for Mac OS X
We dont support building on Darwin, although being a
BSD system, it may be possible, although I have no
idea what to do. There are also bigger problems like
needing X11 headers for AWT etc.
I have heard of people trying to build JDK on BSD,
but I am not sure what the outcome was. You might
try google for more info on these projects.
There is a BSD porting project, but the biggest problem with trying to build Mustang on Mac OS X is that first you'll have to port HotSpot to the PowerPC architecture. Not a small project...
Did anybody of you had contact with Apple to ask them to release their source code diff for OSX with the same kind of license that the J2SE is already pushed ?
Doing so, it could ease the port of mustang to OSX.
If not, is there anybody that have good contact with apple that could be the negociator.
I think that apple could bring lot of value if they join mustang snapshots.
Personally, I was expecting Mac mini to become a nice lightweight J2EE home server machine, but as mustang is not available for OSX, I am stuck to my "good old" Qube3 that has been EOLed.
Thanks and Rgs,
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.