Forgot your password?
typodupeerror
OS X Operating Systems Java Programming

Java 6 Available on OSX Thanks to Port of OpenJDK 202

Posted by Zonk
from the can't-believe-we're-denied-coffee dept.
LarsWestergren writes "Many Mac users have been upset that Apple has not made Java 6 available on the platform. Landon Fuller posts that there is a developer preview release available of Java JDK6 on Mac OSX, Tiger and Leopard. It is based on the BSD port of Sun's Java 6 and is made available under the Java Research License. Charles Nutter posts about impressive JRuby performance gains using Java 6 on his Mac."
This discussion has been archived. No new comments can be posted.

Java 6 Available on OSX Thanks to Port of OpenJDK

Comments Filter:
  • Not Open JDK based (Score:5, Informative)

    by bafio (879076) on Tuesday November 27, 2007 @12:27PM (#21493281)
    It is not OpenJDK, but "based on the BSD Port of Sun's Java 6 JDK, and is made available under the Java Research License"
  • Re:Why Apple? (Score:5, Informative)

    by scheme (19778) on Tuesday November 27, 2007 @12:52PM (#21493609)

    Many Mac users have been upset that Apple has not made Java 6 available

    Shouldn't they be upset at Sun? Why is Apple getting the flack?

    Because Apple told Sun not to work on a jdk for mac os x since apple would produce and maintain it.

  • Re:Why Apple? (Score:5, Informative)

    by el_chupanegre (1052384) on Tuesday November 27, 2007 @12:53PM (#21493637)

    Shouldn't they be upset at Sun? Why is Apple getting the flack?

    Because Apple have shot themselves in the foot with this one. Apple decided they wanted to make Java themselves and offer it through Software Update and all the other Mac niceties. However, Sun releases Java 6 and us Mac Java developers are still waiting. That's why Apple gets the flack and not Sun.

  • Re:Maybe it's me (Score:5, Informative)

    by AmaDaden (794446) on Tuesday November 27, 2007 @12:55PM (#21493675)
    That does not mean that other people would not benefit from it. Java 6 has a number of performance and GUI improvements. http://en.wikipedia.org/wiki/Java_version_history [wikipedia.org] Anyone would be happy if their programs were faster, better looking and more responsive.
  • Re:Why Apple? (Score:1, Informative)

    by Anonymous Coward on Tuesday November 27, 2007 @12:56PM (#21493687)
    Is not this, is because the JDK for Mac OS was always provided by Apple.
    JDK releases for Mac OS by Sun doesn't even exist. In fact if you go
    searching for it at the Sun site you will be directed to use Apple own
    JVMs/JDKs.
  • Clueless (Score:5, Informative)

    by FranTaylor (164577) on Tuesday November 27, 2007 @12:58PM (#21493715)
    Apple integrates their Java into the OS, but a standalone JDK exists within its own directory tree and doesn't interfere with anything else. I have 4 different JDKs installed on my machines and they don't interfere with each other or the resident JDK.
  • Re:Why Apple? (Score:5, Informative)

    by 0racle (667029) on Tuesday November 27, 2007 @01:01PM (#21493741)
    Apple does provide, and always has, Java for OS X. It has always been an integrated application environment, hence the collective 'Huh?" when Java 6 didn't show up with Leopard.

    http://www.kernelthread.com/mac/osx/arch.html
  • by TheNarrator (200498) on Tuesday November 27, 2007 @01:03PM (#21493777)
    JRuby is actually faster on a lot of benchmarks now then straight C Ruby (see the link in the above article to the blog post). This is because Jruby turns ruby into Java bytecode. Java's JIT can do lots of special runtime optimizations to the compiled bytecode that C Ruby can't. With each version, the JVM has been getting better and better at doing these optimizations. It's nice because if I wrote a program in C it would always be the same speed unless I upgraded the hardware. With Java the software just gets faster and faster with each version because the JVM gets smarter.
  • by Anonymous Coward on Tuesday November 27, 2007 @01:12PM (#21493893)
    Correct. It'll based off OpenJDK as soon as we've got the project instantiated within the porters group in OpenJDK.

    The porters group should be created this week, I hope, and then it shouldn't take long to get the BSD port into OpenJDK, and after that Landon's work.

    cheers,
    dalibor topic
  • by AmaDaden (794446) on Tuesday November 27, 2007 @01:17PM (#21493969)
    If the programs know to use the new version of Java it should. Java 6 is faster then Java 5(http://en.wikipedia.org/wiki/Java_version_history [wikipedia.org]). According to some other posts the JDK for OSX is built in. With any luck this JDK will replace that one. There is also a chance that the programs will need to be recompiled to take full advantage of it.
  • Nope (Score:4, Informative)

    by apsmith (17989) * on Tuesday November 27, 2007 @01:19PM (#21493993) Homepage
    Here's the text from the "release 6" developer preview 1:

    Java for Mac OS X 10.4, Release 6 delivers improved reliability and compatibility for Java 2 Platform Standard Edition 5.0 and Java 1.4 on Mac OS X 10.4.10 and later. This release updates J2SE 5.0 to version 1.5.0_13 and Java 1.4 to version 1.4.2_16.


    No J2SE 6 there.
  • Re:Maybe it's me (Score:1, Informative)

    by Anonymous Coward on Tuesday November 27, 2007 @01:20PM (#21493995)
    FYI, Azureus a well known Java based BitTorrent Client is extremely popular.

  • Re:Who needs Java 6? (Score:3, Informative)

    by AmaDaden (794446) on Tuesday November 27, 2007 @02:13PM (#21494671)
    http://en.wikipedia.org/wiki/Java_version_history [wikipedia.org] The main improvements are not what has been added to the language but the improvements that make the whole thing faster. Where I work we recently switched our JSP server from Java 3 to Java 5 and went from having 60% of our pages take under 2 seconds to having 95% of our pages take under 2 seconds. No code changes. Hell, I don't even think we recompiled it. With Java you need to keep in mind that things like memory management that Java does on it's own can always be improved.
  • by setagllib (753300) on Tuesday November 27, 2007 @02:17PM (#21494725)
    Quite the opposite - at least with C you have absolute 100% control of the code you're running until you reach actual system calls, and then the kernel might allow you to make modules to extend those too. Since the very best the JVM can do is make C-like code, doing it yourself will make it faster.

    The cost is having to do all of the intelligent JVM-like optimization manually, which means you'll spend years micro-optimizing C code instead of macro-optimizing Java code or moving on to new features or another project entirely. And the micro-optimized C code will be nearly unreadable because high-level constructs have to be resolved into their implementation details because the compiler can't do it for you. For a large application you'll probably end up with a garbage collector in the C code anyway, and chances are it won't be anywhere near as optimized as Java 6's.
  • Re:Java whiners (Score:5, Informative)

    by mgkimsal2 (200677) on Tuesday November 27, 2007 @02:30PM (#21494905) Homepage
    I'm not sure the entire issue was that it wasn't released day 1 with Leopard, but that there wasn't any information on it. Had Apple said "we will release a Java6 Q1 2008", people who *do* write Java software would have a target date for when their businesses could do what they needed to. And had Apple said "we will never support Java6 on Leopard or in the future versions of OS X", people could also have made appropriate changes. Instead, Apple had preview releases of Java6, then removed all mention of them and made no mention of Java at all when Leopard was released. When asked about Java plans, Apple has not responded.

    It's the not knowing which is causing *most* of the frustration, not the fact that it's not here right now. Sure, some people might be playing the 'taking my toys home' attitude, but I think the issue is bigger than that. People have staked their careers on Java and on Macs, and now there's a disconnect. When your livelihood is at stake, you might get a bit bitchy. When it's being caused by Apple, a company people get very passionate about, you might get a bit more bitchy.
  • Re:Maybe it's me (Score:3, Informative)

    by AmaDaden (794446) on Tuesday November 27, 2007 @02:37PM (#21495005)
    It seems simple but it gets very messy very quickly. They started out doing that. http://en.wikipedia.org/wiki/Java_version_history [wikipedia.org]. AWT [wikipedia.org] would use what ever GUI system was native to the OS. The result was the Java app looked like it fit right in. But it was a mess. From Java 1.0 to Java 1.1 they tried to fix it but it still did not help. So with Java 1.2 they said fuck it all and just made Swing [wikipedia.org]. Swing still kinda sucks but it's way better then AWT was.
  • Re:Maybe it's me (Score:3, Informative)

    by jilles (20976) on Tuesday November 27, 2007 @02:58PM (#21495271) Homepage
    By design that is not possible. But you might run into an exploitable bug in the native code of the vm that allows people to bypass security measures. This is true for any native software on your system. These exploits are getting pretty rare in Java though and I can't actually recall any major Java related exploits in recent years. There have been security related patches of course from Sun and most of them for good reasons. Additionally, you could install a Java application with bugs that are exploitable (but you can write buggy software in any language of course).

    But by design Java is more secure than a typical native application because it protects against most memory and pointer related bugs that are used for installing worms or viruses. Additionally there is a security mechanism that provides fine grained access over which parts of the APIs are accessible to developers. This mechanism is used in applets to prevent developers from doing things you wouldn't want them to do. I'm not aware of any major applet related exploits in recent years and aside from flash and pdf, Java is still one of the most common browser plugins.

    Browsers are of course a common vector for all sorts of malware but Java is rarely the cause of the misery. More common is buggy javascript parsing (by the browser); poor handling of URLs and other bugs in the decade old rendering architectures of IE and Mozilla which both are full of obscure C and C++ code that nobody really understands in full. Mozilla has spent the last two years re-architecting their browser backend to refactor memory usage and get rid of countless memory leaks, bugs and other things that didn't entirely work as designed. They did some great work there. So if you are comfortable running that on your system it would be downright irrational to have any concerns running Java. Your system is only as secure as the weakest component on it. If you are running windows 9x, it doesn't really matter what you install on it from security point of view.

    BTW. Inherent security of the Java platform is also a good reason to run many serverside scripting languages inside a Java VM. For example Php has a history of many exploits, many of which simply don't work inside caucho php port to java (http://www.caucho.com/). Similar advantages apply to using jruby instead of ruby. And of course you might be able to gain a little scalability and manageability.
  • by cmburns69 (169686) on Tuesday November 27, 2007 @03:00PM (#21495293) Homepage Journal
    Java is not particularly concerned with being the fastest language on the block. They're more concerned with being fast enough. Java is not suitable for things where every ounce of performance is necessary. They are also moving closer and closer to being truly write/compile once, run anywhere.

    Java is for business applications where performance is nice, but not critical.

    But of course, they will market any performance gains, as that's just icing on the cake.

  • by Headius (5562) on Tuesday November 27, 2007 @03:09PM (#21495437) Homepage Journal
    JRuby itself uses only about as much memory as Ruby does for most apps we test. But we do pay a one-time cost for the JVM itself, which adds 25-30MB to the process. However on a server deploying Rails, this is insignificant compared to the memory eaten up by Ruby runtimes, and we're smaller there by most measurements.

    Startup...yeah, it's an issue. But JRuby 1.1 will ship with Nailgun as part of the release, which enables you to run JRuby in a background persistent process and execute command-line scripts with startup times in the hundredths of a second range. Quite acceptable.
  • by mean pun (717227) on Tuesday November 27, 2007 @03:48PM (#21496021)

    Strikes me as an indictment of human behavior. Do you praise apple for all of the previous times that they ported java, or condemn them for the one time that they don't?

    Apparently, you're not in possession of all the facts. Apple has provided a beta of Java 6 that is now more than a year old. They dropped heavy hints that Leopard would include a release version of Java 6. Despite these promises, Apple has until now not delivered. Is this reason to be angry with Apple? That's a bit strong, but I am disappointed, and I'm certainly not the only one. If Apple don't intend to release a new version after all, it would be nice if they would just say so. If they did, Sun just might jump in and release their own version, who knows.

    Obviously, I am happy that some people were enterprising enough not to wait for Apple, and release their own version. Unfortunately, they can't take advantage of all the work Apple has put in their Java release to integrate it better in Mac OS X. And again a little help from Apple would be welcome: if Apple doesn't want to release new versions on their own, it would help if they would at least open up some of their code to help these kinds of third-party implementations.

  • Re:Maybe it's me (Score:5, Informative)

    by nostriluu (138310) on Tuesday November 27, 2007 @05:08PM (#21497207) Homepage
    Azureus, Limewire, LightZone and Cyberduck are all popular applications written in Java, along with a large number of mobile device apps (see http://mobits.com/jad/ [mobits.com]). What Java tries to do - generalize the runtime and provide a programming language for all operating environments - is quite a task, and after a decade it has considerable success in some fields. It is really a shame that it has been subject to bad impressions and innumerable political moves that in the end just take away another choice from the end user.
  • by 0xABADC0DA (867955) on Tuesday November 27, 2007 @05:39PM (#21497601)
    What's so interesting about it is that Microsoft's copy of Java, C#, was concerned about being the fastest language so they make a lot of hacky choices purely based on what they thought would be fastest. Things like:

    * value types - now java can often automatically put objects on the stack and this makes the complexity cost of value types hardly worth the benefits.

    * jit-only - C# thought that a jit would always be used because jit is 'faster', so their bytecode is not able to be interpreted effectively. This prevents the very efficient mixed-mode interpret followed by hotspot compile (for instance, Java can optimize the program using another core while it is running interpreted).

    * 'real' generics - C# thought real generics would be faster by avoiding casts, but the complexity cost of following generic instance types prevents many optimizations such as method inlining that now save more time than casts (iirc CLR only inlined single methods less than 32 instructions and only if not overridden, vs Java inlining multiple method calls deep)

    * embedded native code - C#'s bare-metal native code interface allows for faster access to small bits of native code, but it locks objects in place in memory a lot more making the gc more complicated. .. and so on.

    In all these cases C# chose the way it thought was fastest but this made the CLR very complex. Java chose the way that was simplest but fast enough. And the end result is that Java is much faster than C# and a much simpler implementation.
  • by ndykman (659315) on Tuesday November 27, 2007 @10:10PM (#21500265)
    Firstly, I think your conclusion that "Java is much faster than C#" is very difficult to support. Of course, there are lies, damn lies, statistics and benchmarks, but the overall picture I see is that the performance of C# is in fact quite competitive with Java in terms of runtime performance.

    As for some of the decisions, they are not just about pure speed. There are more considerations.

    Value types: This allows the choice of the best semantic match is. Also, this does help with native interoperability, as in some cases, you can model a C struct in C# and pass it back and forth with a lower cost. Also, the complexity cost you note is small, as even Java still has value types. If you have to deal with both, then adding in structs isn't that costly, from a language and runtime view.

    JIT-only: The ability to pre-compile to native code helps with native interoperability and performance. It can affect startup time, but there are techniques to deal with this a bit. I think MS thought the added complexity of interpretation+hotspot compliation wasn't worth it for them. It was a tradeoff, but I don't see it as a drastic one. Also, C# can still code-pitch if needed. It is probably harder.

    Real Generics: To be honest, I can't say that Java Generics are all that great, from a programming model. Sure, they don't technically cost anything, because they go away. Which causes real problems and limitations. For example, C# 3.0 can do a ton of type-inference and more functional-like program as the type information of a delegate (or lambda expression) is kept and passed. Also, I'd like to see the reference for the CLR only inlining one deep.

    Embedded Native Code: Well, faster access to native code can make a huge improvement in performance, and this is a real problem with the Java runtime. JNI has some real issues in terms of usability from a programming standpoint. The CLR makes it must easier to call into a native function if you need to, and that's often a really useful point. Not just for Windows, but for OS/X, for Linux, etc.

    The GC: Sure, it is more complex, but there isn't much evidence that it is slower because of it. Again, if fast native interoperability is a goal, then this may be a cost, but it may be a good one.

    Yes, the CLR is more complex. That is because it can actually model more aspects of an executable. It has pointers. It has "unsafe" code. You can compile any C/C++ program that compiles in Visual Studio 2005/2008 to the CLR with a few switches. In some cases, the performance hit is surprisingly small versus the native code. With the Phoenix [microsoft.com] project, the .Net CLR has access to the same optimizations that the native C/C++ compiler has.

    All in all, the CLR, C# do represent some interesting ideas and is a very valid platform. The MS equals sucks argument just doesn't hold here. But, it's just an opinion.

  • by ClassMyAss (976281) on Wednesday November 28, 2007 @12:41AM (#21501249) Homepage

    value types - now java can often automatically put objects on the stack and this makes the complexity cost of value types hardly worth the benefits.
    And this is definitely a good thing. However, it is being touted as if it's the solution to the entire heavyweight object problem. It is not - plain and simple, objects are too bloated to use if you need to shuffle around and process large amounts of data. If I want to store a list of half a million vectors and do some geometry with them, in Java the only real solution is to break the vectors apart and store them as floats, because there is just too much data manipulated if you use objects, which takes both a time and a storage toll. It also forces all your helper routines to take plain old float arrays - you might as well be writing C code, for all the type safety that gives you. You end up forced to give up all the great things about OO programming, all because you're forced to make do with the pathetic set of lightweight value types that Java provides. [No complex type? Come on, guys...] And then we're told that to add a feature like value types would hurt the OO-nature of the language? I suppose making an int a full-fledged object would be reasonable, then, right?

    I'm not saying that this is a huge problem - I still use Java anyways, as despite its little glitches I find it to be overall less painful than C or C++, and I really do think that it is improving (and if it ceases, I'll just jump ship to Python). But it's kind of annoying that for years we have been told that this type of thing is not a problem at all, and that furthermore, that the only workaround is to put supreme faith in the JVM to bless us with everything we need. I'd kind of prefer if Sun just came out and said, "We don't give a glistening poo nugget about people trying to do hardcore computation in Java. Deal with it!" rather than pretending that the solution is already in our hands. Because it's not!
  • Re:Maybe it's me (Score:3, Informative)

    by nostriluu (138310) on Wednesday November 28, 2007 @11:23AM (#21504779) Homepage
    They are two different things. uTorrent is, well, a micro client implementation, whereas Azureus is meant to be a be-all, end-all client implementation. You could make a minimal torrent implementation in Java as well.
  • by 0xABADC0DA (867955) on Wednesday November 28, 2007 @01:01PM (#21506363)

    Firstly, I think your conclusion that "Java is much faster than C#" is very difficult to support ... but the overall picture I see is that the performance of C# is in fact quite competitive with Java in terms of runtime performance.
    You can't post benchmarks of C#, macro or micro... enough said. Actual performance of CLR has to be hidden from view.

    Value types: [...] Also, the complexity cost you note is small, as even Java still has value types. If you have to deal with both, then adding in structs isn't that costly, from a language and runtime view.
    You'd think... but in Java the bytecode specifically indicates each value type whereas the CLR does not (since there can be any number of value types). The cost of this to CLR is HUGE because makes it not interpretable and also very difficult to optimize... the CLR has to determine types for all values whereas the JVM has the actual type built right into the code. I can't stress enough how much more complex this makes the CLR implementation.

    JIT-only: ... I think MS thought the added complexity of interpretation+hotspot compliation wasn't worth it for them. It was a tradeoff, but I don't see it as a drastic one. Also, C# can still code-pitch if needed. It is probably harder.
    The primary benefits of hotspot (inlining and other optimizations across multiple methods) are effectively not possible in CLR due to the interactions between value types, generics, and the bytecode format. It's not that Microsoft does not want to do these, it's that they are not able to.

    Real Generics: ... C# 3.0 can do a ton of type-inference and more functional-like program as the type information of a delegate (or lambda expression) is kept and passed. Also, I'd like to see the reference for the CLR only inlining one deep.
    Give some real examples because as far as I've seen 'real' generics are useful in theory only. Reference to CLR inlining:

    http://blogs.msdn.com/ericgu/archive/2004/01/29/64717.aspx [msdn.com]

    This is somewhat old, but from a person very close to the code. Note the extreme lack of inlining:

    * nothing greather than 32 instructions
    * no virtual functions
    * nothing with flow control
    * nothing that catches exceptions or uses finally
    * nothing with structs as paramaters

    The fundamental reason is that these things like generics and value types effectively multiply the complexity at each point. In other words, they 'screwed the pooch'. Java inlining is not restricted by any of the above.

If a camel is a horse designed by a committee, then a consensus forecast is a camel's behind. -- Edgar R. Fiedler

Working...