Java 6 Available on OSX Thanks to Port of OpenJDK

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."

Comments

Maybe it's me

[Anonymous Coward]

"Many Mac users have been upset that Apple has not made Java 6 available on the platform."

I'd have thought not having Java infecting your machine would be a huge advantage myself. Not having .Net is another.

Re:Maybe it's me

[Anonymous Coward]

The only Mac users I know that even noticed are Java developers.

Re:Maybe it's me

[AmaDaden]

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 Anyone would be happy if their programs were faster, better looking and more responsive.

Re:Maybe it's me

[Anonymous Coward]

I really meant to imply that besides Java developers nobody uses client side Java applications. I probably should have been clearer and just said that Java sucks.

Re:Maybe it's me

[Anonymous Coward]

FYI, Azureus a well known Java based BitTorrent Client is extremely popular.

Re:Maybe it's me

[AmaDaden]

Client side Java applications have historically sucked because the Java GUI objects sucked and/or were too hard to use. It caused the apps to be bloated, unresponsive, slow, and hard to write. You could work around these problems but it was a tough fight and you needed to REALLY know what Java was doing. If Java 6 does fix even some of this then we are likely to see many more usable Java client apps. Hell, even the Java bashers might enjoy using some of them soon.

Re:Maybe it's me

[encoderer]

I'm a programmer, and while my work is usually an order of magnitude more complex than "Write this CRUD screen for this Access Database," it's nowhere near "develop a new programming language."

That being said..

Java used their own in-built controls so the language could be portable, cross-platform, etc.

Well.. why couldn't they keep that in place, but also write special-case code for the most popular platforms? Like, and excuse how crude this is:

switch (current_os)
{
    case XP: // load comdlg.dll
          break;
    case OSX: // Load cocoa? or whatever the hell mac uses...
          break;
    default: // Load in-built controls
}

Re:Maybe it's me

[mattgreen]

It'd look different on each platform, and apparently that's a bad thing in Sun's eyes, as they would prefer that Java be a platform that runs on top of the native OS.

Yes, it is ass-backwards. This is Sun we're talking about, so it is difficult to be surprised.

Re:Maybe it's me

[AmaDaden]

It seems simple but it gets very messy very quickly. They started out doing that. http://en.wikipedia.org/wiki/Java_version_history. AWT 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. Swing still kinda sucks but it's way better then AWT was.

Re:Maybe it's me

[jilles]

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.

Re:Maybe it's me

[MacColossus]

Groupwise client from Novell is Java based for Linux and Mac OS X. While I use Mail, several of the people I support use the Mac Groupwise Client.

Re:Maybe it's me

[FatherOfONe]

Yeah, and lets add a few more to the list.
No PHP crap. Slow, and it is only for script kiddies.
No Ruby crap. Way too new and it is a fad.
No games... they just cause systems to crash. Who needs cool games.
No C or C++, only that crappy C variant that Apple makes.
Heck, now that I think about it, no programming languages at all. Make it just like they wanted to with the iPhone.

Obviously I am kidding... I own a Mac and run most (not all) of the stuff mentioned above. I game on a console. I do wish that Apple would release their GUI Java stuff under GPL, so people like this guy could get Java 6 with SWING out there ASAP. I would love to do my Java development on my Mac without using Parallels and XP.

Some have suggested that Sun should be the one making a VM for Apple, and I would agree BUT Apple should have come to Sun two years ago and said that they were out of the JVM business and worked with Sun to insure a modern VM was on their platform. It is in both parties interest to see a good JVM on the Macintosh.... Hopefully one that doesn't require a freaking OS upgrade to get the latest version of Java.

Please Apple, finish Java 6 for the Macintosh and then hand the code over to Sun to make Java 7. Sun take that code and open source it as well.

Re:Maybe it's me

[AmaDaden]

Sun take that code and open source it as well.

Your behind by a few months.
http://open.itworld.com/4915/070508opsjava/page_1.html
Here is a summery for people to lazy to click on the link from http://en.wikipedia.org/wiki/Java_(programming_language)

On 13 November 2006, Sun released much of Java as free software under the terms of the GNU General Public License (GPL). On 8 May 2007 Sun finished the process, making all of Java's core code open source, aside from a small portion of code to which Sun did not hold the copyright.

Re:Maybe it's me

[Anonymous Coward]

If you want a fast, good looking and responsive application, the last thing you would do is write it in Java.

Re:Maybe it's me

[nostriluu]

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/). 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.

Re:Maybe it's me

[FatherOfONe]

I am sorry but I wasn't clear.

I want Apple to GIVE Sun the code that makes SWING run on the Mac OSX and look good. Sun could then opensource that code as well as the Open JDK project.

The guy that did the JDK 6 for OSX (awesome guy), has used the BSD version and it requires X to run Swing applications. These applications will look bad compared to the near native look and feel of SWING applications run on Apples 1.5 JVM. Apple put a lot of time in to making Java applications look and feel great on their platform, but they just haven't kept up.

Re:Maybe it's me

[PitaBred]

Only if you don't have much memory to work with. Java's quite well positioned to work on the desktop, and can even look decent with a good developer behind it.

Re:Maybe it's me

[tyrione]

Landon Fuller used to work at Apple inside the BSD team. I sure as hell hope he knows a wee bit of how the Java/Cocoa marriage works.

Re:Maybe it's me

[wwwillem]

Do I get this right? You suck the object and then it gets "hard to use", it gets "bloated, unresponsive, slow and hard".
So, it was "a tough fight", but that all happened after a cup of Java?? Oh it was not normal coffee, it was Java S..X. :-) Wow......

Re:Maybe it's me

[icepick72]

Well if we're too lazy to click on the first link, why would we click on the second?

Re:Maybe it's me

[J.Y.Kelly]

Well.. why couldn't they keep that in place, but also write special-case code for the most popular platforms?

Kind of like...

try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {}

OK so it's more of a theme which makes the native Java widgets look platform specific, but frankly for most applications it's good enough. I have a set of Java client application which run on Linux, OSX and Windows and my users would have a heck of a job telling the difference between them and a 'real' native application.

Re:Maybe it's me

[master_p]

Java is nice, but compare Azureus with uTorrent (for example), and you see why c/c++ is still a popular choice.

Re:Maybe it's me

[nostriluu]

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.

Re:Maybe it's me

[Lally Singh]

There's an art to Java Client-side apps. Over time, the easy path is allowing larger & larger apps to run pretty close to native speed. Partially due to cpu speed increases, JVM enhancements, and better understanding of how to write responsive java client-side apps.

Honest to God, my sun ultra runs eclipse so fast it feels native.

As for Java 6, it's got it's own share of performance enhancements, one of the big ones is DTrace Support. At least we can tell why something's taking so long, and adapt the app to remove or mitigate the problem.

Re:Maybe it's me

[Lally Singh]

Depends... I still haven't found a C++ library that makes a good looking app on multiple platforms. QT still looks terrible on the Mac and doesn't really fit in with GNOME-based Unix desktops.

Of all the cross-platform efforts out there, the Java camp's working the hardest.

Re:Maybe it's me

[inline_four]

The reason why AWT was a problem is two-fold:

1. AWT uses what's called native peers to draw each individual component. That means that every interaction between Java code and an AWT widget required JVM to go outside of the managed code stack and vice versa.

2. AWT exposed its API in a very primitive way with inadequate data-presentation separation and a poor event model.

Swing came on the scene from outside of Sun. It became incorporated into J2SE, but it retains the javax top-level package name because it was originally a 3rd party solution. Swing attempted to address the 2 issues above. It made use of as few native peers as possible (usually just one per frame to draw the enclosing window) with the help from "lightweight components". It also hailed itself as an MVC framework. Interestingly, this separation of presentation from data and business logic allowed a greater degree of freedom with regard to what the GUI looked like, but the default behavior was to create a native GUI look-alike, and it remains so to this day. However, it's possible, should the developer need it, to take full control of what GUI looks like and not care about making it fit with the native look of the system.

When Swing first came out, it was excruciatingly slow, in part because it wasn't well optimized and in part because JVM itself was slow. And of course the hardware was slower back then too. This is when Java caught a lot of flack for having piss poor GUI response and feel. Nowadays things are significantly better, but popular opinion is still partly affected by this "Java is slow" mentality. The hoopla about Java 6 not being available on Leopard is important, even if not too many non-developer end users are aware of it.

The reason it's important is because until this Open JDK port, Mac Java was the only implementation of the JVM that was not authored by Sun. So it was up to Apple to provide a version of Java that would work well with OS X. This goes beyond just making it work, which is what this BSD-derived port does. Apple's implementation optimized Swing's Apple look and feel to work well with Cocoa, while the Open JDK port uses X11. Don't get me wrong, it's wonderful that this has happened, which is the whole point of having Open JDK around, but we're still waiting on a full-on Mac Java in terms of GUI. The worry that many have is that Jobs has downgraded Java on the priority list and that this may become a significant roadblock in letting Java succeed on the desktop as a cross-platform solution. Since Apple chooses to be very closed in the way Mac OS X is developed, it is really their responsibility to provide a good Java experience to their users. But I can see how it's a conflict of interest to them, so they may choose not to, which I think is a shame.

Re:Maybe it's me

[daem0n1x]

I don't think Swing is hard to use, compared with other GUI toolkits, I think it's pretty cool.

If it looks good, well that's another thing. I think it has been improving a lot and now, a well-built Java application can run alongside with native ones, and users won't even notice.

Why do slashdotters hate Java so much? Even if they had something intelligent to say, but most of it is just prejudicial bullshit and senseless bashing.

Re:Maybe it's me

[daem0n1x]

You haven't touched Java for quite a few years, haven't you?

Re:Maybe it's me

[AmaDaden]

They hate it because it started off as closed source, slow, buzz word nonsense. However over the last 12 years it has become open sourced, decently fast, and a valid language to do work in. They got a bad taste in their mouth about it and refuse to let the issue go. People don't care that it's better then it was and that most of these issues have been fixed. They will only care if it can do something they already do better then what they have now. So until Java can beat C/C++ or Perl most people refuse to even learn how about how well it can do somethings. Even if it can handle most of the cross platform and memory leak issues of C/C++ and that Perl 6 is trying to use the same VM idea that Java has had for years now they just don't care. I don't get it either, I just try to correct the miss understandings and hope that they catch on to the fact that Java has become a useful language.

Re:Maybe it's me

[master_p]

No, compare the client parts of both.

uTorrent author says in the documentation that he chose c++ because he wanted a small app without dependencies.

Re:Maybe it's me

[daem0n1x]

I'm stuck between two teams that were supposed to collaborate.

The team A is C/C++ centric. They use open-source libraries and tools whenever they need.

The team B is composed of the typical Microsoft drones: They only consider C# or VB as valid languages, they write web apps for IIS only and they have a profound hatred for all things open-source.

I'm a strong Java advocate, but they won't listen to me. Team A because "Java is slow" or "Java is closed" or other bullshit like that. Team B, of course, because "it's not Microsoft".

Team B wants to standardize all our products in the MS platform. Our customers demand cross-platform stuff, so we will probably lose business because of that. Funny thing is that the C geeks are actually helping them.

Re:Maybe it's me

[nostriluu]

I agree, thus the comment about politics (majorly, first MS, now Apple).

Not Open JDK based

[bafio]

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:Not Open JDK based

[Anonymous Coward]

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

What's the big deal about jruby?

[happyemoticon]

Am I the only one who thinks it's weird to run an interpreted language inside of a virtual machine? Would there be any application to it, aside from rewriting overly-verbose Java code in a more concise language?

Re:What's the big deal about jruby?

[snl2587]

No, you're definitely not the only one. What's so hard about learning Java instead? (Seriously: what are JRuby's advantages?)

Re:What's the big deal about jruby?

[OptimusPaul]

One application is to add scripting support to a java app that has an installed base. And Ruby is popular these days so it only makes sense.

Re:What's the big deal about jruby?

[Surt]

Why would anyone ever use anything but assembly? The rest is all syntactic sugar. Even if you need portability, you need only go as far as c.

More seriously, jruby is faster than cruby, and has nicer syntax than java. You would use it if you wanted to write code in a nice language on platforms where you would otherwise be stuck with java. Virtually anything that processes either plaintext or xml is going to be radically easier to implement in jruby than java, and nearly as fast at runtime.

Re:What's the big deal about jruby?

[MBCook]

Ruby gives you easy scripting without having to use something like Janino to compile and import classes on the fly. Using Java also provides access to all the Java libraries from Ruby (which can be nice) and fixes some of Ruby's issues (I understand that the ruby interpreter is single threaded, for example). There are some good reasons why one might want to do it.

Re:What's the big deal about jruby?

[FranTaylor]

Oh, that's an easy one. Take advantage of the garbage collection and the JIT compiler. Why write your own when you can use what already exists?

De gustibus non est disputandem.

Re:What's the big deal about jruby?

[wandazulu]

I am using it to write a scriptable Java application. JRuby has saved me literally thousands of hours trying to implement my own pseudo language just to support a simple DSL in the app. And because it's Ruby, I can now do all kinds of things that my own language couldn't do, like loops. When we give the app to users, we tell them it's scriptable, here's the DSL objects, and here's a website on Ruby; you're limited only by your imagination.

Plus it works in Java 5, so I can use it instead of waiting for Apple to release Java6 with its built in JavaScript scripting language (which I don't like nearly as much as Ruby).

Re:What's the big deal about jruby?

[TheNarrator]

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.

Re:What's the big deal about jruby?

[Gr8Apes]

There's another reason to run JRuby - the ability to dynamically change a code snippet by users inside a larger application for custom rule engines, as an example.

Java allows it as well, but it's much harder to sandbox dynamically uploaded java code than a scriplet.

Re:What's the big deal about jruby?

[Bert64]

Well, your C program could get faster by being compiled with a more optimising compiler...
And it's not that ruby written in C cant be faster, it's just the current implementation that's not. Remember, the JVM and it's JIT compiler are themselves written in C. It would still be more efficient to do it without the extra overhead of java, assuming your program doesn't add any extra overheads/inefficiencies of it's own.

Re:What's the big deal about jruby?

[Anonymous Coward]

Nothing really prevents you from using a "recompiler" at runtime with a C based executable. For example LLVM.

Re:What's the big deal about jruby?

[ClassMyAss]

Yes, the JIT compiler is written in C, but you are wrong that a better optimizing C compiler could beat a really good JIT. The whole point of JIT is that it can use current information about how a program is running and do things like arrange objects in memory to increase the cache hit rate. The best C compiler in the world just doesn't have the amount of information available that it would need to do things like this.

That's not to say this all currently works in practice, though. Sun has been telling everyone for the past five years that the JVMs are so robust and intelligent that you don't need lightweight objects to do fast computation (for things like vector math), that you can just use plain old Java objects and the JVM will figure out how to optimize these, and anybody that's ever actually programmed some physics or graphics in Java knows that those claims are still crap. (Though I'm told this version of Java is much better about this stuff, to be fair)

However, failures in implementation aside, there are very good arguments that suggest that as we go forward, JIT compilers will eventually overtake statically compiled code when it comes to speed. IMO the current Java 6 JVM is a pretty good first step towards this ideal JIT compiler; maybe I'd qualify it as a very early alpha version of The Real Thing. Certainly much more of an improvement than the past few versions. It's unfortunate, however, that Sun continues to pretend that they've already got it all figured out and running smoothly, when there is obviously so much more work to do. It's also quite irksome that they ignore most performance-related RFEs, simply promising that the magical JIT will fix everything in the next version...

Re:What's the big deal about jruby?

[setagllib]

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:What's the big deal about jruby?

[Anonymous Coward]

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.

That's all well and good, but the C program started out faster to begin with. The Java programs may be getting faster, but the question is: are they getting faster than a program in C, or are they just approaching the speed that the C program had to begin with?

Re:What's the big deal about jruby?

[kwerle]

jruby lets us write new web apps that use thousands of lines of java controller code without having to rewrite those thousands of lines of perfectly functional code. Eventually we may migrate to pure ruby - but in the meantime, jruby is a great solution.

Re:What's the big deal about jruby?

[Cobron]

Speed of development, I guess. Ruby on rails seems to be quite good at this they say. Using netbeans 6 (release candidate) it was a breeze following the jruby on rails tutorial on netbeans' site and deploy it on my tomcat 5 hosting. After that I lost interest.

There is also the promise of a jruby compiler which compiles the ruby files into bytecode.

Re:What's the big deal about jruby?

[cmburns69]

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.

Re:What's the big deal about jruby?

[Headius]

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.

Re:What's the big deal about jruby?

[jilles]

That's true in theory but in practice most C programmers have no clue about underlying hardware architecture so 100% control amounts to random and arbitrary optimizations (and sometimes dangerous/counter productive) in most cases. The VM that the hardware presents to the compiler is not that different from the bytecode VM Java presents only more complicated, full of legacy features that no longer make sense and implemented in hardware. Underneath the processor translates to its real processor architecture which is probably quite alien to what most programmers are used to.

Also C programmers can only optimize for so many platforms and the optimizations can be different and even conflicting for each one. With a optimizing JIT, you can automatically optimize at run-time and apply any appropriate platform specific optimizations it knows about as well as optimizations that take into account measured performance of the running application. Doing the same in C requires dozens of different binaries and source code level optimizations just to target recent variations of X86 processors. Linux distributions have only recently started defaulting to 586 or 686 code instead of 386 code.

That's why a new compiler architecture is under construction (LLVM) that can do similar run-time optimizations to what Java is doing today. It makes sense to do optimization at run-time, also for C software.

Re:What's the big deal about jruby?

[Paradise Pete]

No, you're definitely not the only one. What's so hard about learning Java instead?

I've been writing Java code since its early days, but I'd *much* rather write in Ruby. And JRuby brings access to all the Java libraries.

Re:What's the big deal about jruby?

[smcdow]

... more general and well maintained VM ... Sounds like Parrot.

Re:What's the big deal about jruby?

[petermgreen]

one of the big problems with java from a performance perspective is it's object model. You can't have a variable that is an object only a variable that is a reference to an object. This causes several problems especially when dealing with lots of operations on small plain old data objects.

1: designers must make a hard choice between mutable and immutable objects. Mutable objects are error prone but immutable ones mean a lot of load on the memory manager.
2: objects that consist of aggregations of objects increase the load on the memory manager further because instead of one object several must be allocated and deallocated
3: an array of a large number of objects means that every object in the array must be allocated seperately which means an immense increase in memory manager loads.

yes you can try to optimise some of theese cases but it is very difficult to tell at creation time whether an objects lifetime will be tied to the object that contains it.

Re:What's the big deal about jruby?

[0xABADC0DA]

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.

Re:What's the big deal about jruby?

[NoOneInParticular]

You're absolutely right: there's no such thing as a scripting language. There is however a necessity for scripting, and languages that fit that need are commonly called scripting languages. In my scientific endeavours, I often have the need for post-processing of data. I generally use bash, python and octave for those needs. These are my scripting languages. Some collegues of mine use C, Lisp, or other tools for their scripting needs. These are their scripting languages.

To sum it up, a scripting language is a language suitable to solve scripting needs. Need is personal, but some solutions to these needs are laughable. Using C to process a bunch of data on a one-off basis I find silly. But, if that's all you know, more power to you.

Re:What's the big deal about jruby?

[PitaBred]

Neat :) I never knew that kinda stuff was out there.

It's still a bigger pain than just writing Java code, though.

Re:What's the big deal about jruby?

[Max Littlemore]

It's unfortunate, however, that Sun continues to pretend that they've already got it all figured out and running smoothly, when there is obviously so much more work to do.

This is true... but...

Imagine Sun said "It's not perfect yetm but it's getting better" with every release. Meanwhile, given their standard marketing practices, MS said ".Net works perfectly, outperforms everything, in fact it runs faster than is theoretically possible on all supported hardware* and gives the officer responsible for purchasing software a 53% increase in sex appeal!". What's the PHB going to buy?

Sure they might ask for input from propeller heads, but at the end of the day MS is trusted and consistant (much more important than good - see McDonalds). Sun basically has to lie to keep the technology alive. It's standard business in any field.

*Minimum system requirements: 8*4 core 64 bit Intel processor with 64GB RAM. 256*4 core with 1.3TB recommended.

Re:What's the big deal about jruby?

[setagllib]

That's what I said, here:

"The cost is having to do all of the intelligent JVM-like optimization manually, which means you'll spend years micro-optimizing C code"

Re:What's the big deal about jruby?

[ndykman]

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 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.

Re:What's the big deal about jruby?

[aled]

Nonsense. Parrot is version 0.5 (alfa? beta?) while the Hotspot virtual machine has years of stable, production quality and performance optimizations that Parrot doesn't.
If that's not enough read the parrot FAQ:

So you won't run on JVM/.NET?

Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends.

Re:What's the big deal about jruby?

[ClassMyAss]

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:What's the big deal about jruby?

[jhol13]

I did a quick and dirty test. I allocated three vectors of floats and compared if to one vector of objects containing three floats (one million of them). Of course my experiment is far from scientific and especially tells nothing about your circumstances.

The result? The object version used considerably less memory.

I am confident we should not invent new mechanisms to a language just because something "feels" more expensive. Are value types really that much lighter in your case? Have you measured?

Just like stack variables - no need to add as it seems[1] Java 7 could be able to put some objects to stack (by using escape analysis, etc.).

[1] I am not sure if this is going to happen (and how advantageous it would be), but I have seen some talks about this.

Re:What's the big deal about jruby?

[inline_four]

Maybe it's too late for your project, but I've always loved using BeanShell.

Re:What's the big deal about jruby?

[0xABADC0DA]

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 are talking about 'value' types and collections of them. Values are copies, so just write a VectorArray that stores them using arrays of Java primitive types. The overhead of creating small temporary objects when accessing these vectors will be real but negligible (since these objects do not last long). Yes, it's slightly annoying.

I did not say that there is no benefit to 'value' types, only that their benefit is outweighed by their cost. What good is it to have a value type when the methods you call on it are not inlined, or are only superficially inlined? Java can and does inline 5+ calls deep in some cases -- that can be a lot of extra time to cover these costs.

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. It's not that I disagree with that, but on the other hand the optimizations the JVM can do now is largely because they didn't add hacks to directly address these issues. That was my point. It's basically another example of Knuth's motto.

Re:What's the big deal about jruby?

[0xABADC0DA]

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

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.

Re:What's the big deal about jruby?

[MenTaLguY]

Actually, until recently C-Ruby didn't even have a VM; Ruby 1.8 and before used an interpreter that simply walked the AST. Ruby 1.8 is the current stable version, so it might be more accurate to say that Ruby folks are largely motivated by the poor performance of not having a VM at all.

On the other hand, the experimental Ruby 1.9 did finally introduce a Ruby-specific VM (YARV) implemented in C, and 1.9 on YARV is actually what Charlie was comparing JRuby's performance to in his post.

I can't wait

[Anonymous Coward]

...for the next OS X update, when this breaks the updating.

People will cry foul on the boards, other people will note that as this isn't an official release, it should have been expected that it'd break the updating.

It'll be fun for the whole family!

Re:I can't wait

[miscz]

So you only install official Apple software on your OSX?

Re:I can't wait

[Symbolis]

Me? Heavens no! ....I don't have a Mac, never mind OSX. ;) Also: Wooo! Password found!

Re:java 6 is FAST

[MartinG]

Then don't use WSAD. It's crap.

I changed to eclipse and everything is blazingly fast.

Why Apple?

[Orange Crush]

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?

Re:Why Apple?

[scheme]

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?

[teh kurisu]

Because Apple provide Java on Mac OS, not Sun. Remember how Microsoft provided the Windows version of Java, before Sun got pissed off with what they were doing with it and demanded it back? Same thing here, only Sun haven't got pissed off yet (hopefully soon!).

Can't be bothered looking for anything to back up what I've just said, but go to http://java.sun.com/ and look for any Mac OS X download. There aren't any.

Re:Why Apple?

[el_chupanegre]

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:Why Apple?

[nofx911]

Apple took over the port from Sun many years back. Sun lent them a few employees, but it was Apple's responsibility to keep the port up to date. Java seems to no longer be a priority for Apple, and many of the Apple devs that were quite helpful on Apple's Java Dev Forum seem to have left the company or were moved to other projects. My guess is that PPC users may never see a port of Java 6 and that the most functional Java 6 port for Intel Mac users will come from the BSD port. Depending on IBM developers PPC users may see a working port of the openjdk.

Re:Why Apple?

[Anonymous Coward]

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.

Re:Why Apple?

[0racle]

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

Re:Why Apple?

[kwolf22]

Apple provides their own non-GPL'd Java implementation. Presumably, the core components of this implementation have been licensed from Sun under a non-GPL license that allows Apple to create a platform specific derivative work. I know that Apple distributes J2SE 5.0 with an Apple License that states, "...you may not copy, decompile, reverse engineer, disassemble, modify, or create derivative works of the Apple Software or any part thereof." This protects the proprietary parts of Apple's implementation of Java that link to the rest of their proprietary code. BTW, this situation also means that the GPL Classpath Exception doesn't apply to Apple's Java Implementation.

My feeling is that the Apple/Java vacuum has to do with the fact that Java is now GPL'd. I seem to remember that one of the reasons that Apple chose BSD over Linux for OS X was due to the way GPL'd software is licensed. Think about it... Apple has done A LOT of work to integrate Java into just about every aspect of OS X. Probably, under the GPL, they'd have to cough up a lot of their proprietary integration source code. I think that this is also why there is no official QuickTime Player for Linux. If Apple were to come out and announce that they won't support Java on OS X because of the GPL, it would probably cause much worse press than the present situation (which also sucks, btw).

Since OS X, Apple has been a big supporter of Open Source software - but NOT Free (GPL'd) software. My feeling is that before we see OpenJDK on OS X (or on the iPhone), Apple will have to figure out how their proprietary technologies such as Aqua, QuickTime, etc. will be able to legally integrate with GPL'd Java. Either that, or Apple will cease in-house Java development entirely and give it back to the community - relegating Java it to third party add-on status.

Personally, my fear is that since Apple's Java 6 implementation seemed ready to go - especially for Leopard, Apple pulled their Java 6 implementation because they are unwilling to comply with the terms of the GPL. Keep in mind that Java 5 (Apple's current implementation) is not to be GPL'd. If this is the case, there could be serious implications about the future of Java integration with all of Apple's technologies

Re:Why Apple?

[nofx911]

No, that is not the way that it works. Sun choose to have a general release of the JDK (openjdk) under the GPL - since they still own the code they can choose to license it to others under different terms than the GPL - much the same way that MySQL has done their releases. IBM, HP (for True64 / OpenVMS port), Apple - still have their paid licenses in tact. Don't let GPL hysteria scare you. If you own the code (or force contributors to turn their rights to the code over to you) there is no limit on the number of different ways you can license your code to others. Even the Mozilla foundation releases their code under many different licenese to make it compatible with different projects (Mozilla Public License, version 1.1 or later, GNU General Public License, version 2.0 or later, and GNU Lesser General Public License, version 2.1 or later).

Re:Why Apple?

[Bert64]

Bear in mind there were betas of JDK6 for OSX.. So Apple have clearly been working on it at some point.
Apple have recently released a new version of their OS (leopard), and some new devices (Iphone, ipod) that needed their own port of the OS... And they're still ironing out bugs in those flagship products. Seeing as they only have limited developer resources, it's not surprising to see java on the back burner for a bit.

Re:Why Apple?

[KugelKurt]

Apple does it by itself, because old ports of Java for Mac OS (classic) by Sun were so bad that Apple thought doing Java itself is better than letting Sun ruin it. IIRC Apple even chose a Java implementation from Microsoft for a while, because it was better than Sun's Java version.

Re:Why Apple?

[sammy baby]

(disclaimer - i'm not an apple or java developer)

That wasn't an entirely bad move on Apple's part - at the time, they were planning on making Java a first class citizen on OS X, with native Cocoa libraries for Java programmers. Unfortunately, that's pretty much all out the window now - Apple's tutorials state that "The Java API for Cocoa is deprecated in Mac OS X version 10.4 and later."

So in other words, Apple definitely did something dumb here, but it's not too hard to see what their motivations were.

Re:Why Apple?

[LizardKing]

So in other words, Apple definitely did something dumb here, but it's not too hard to see what their motivations were.

The deprecation of the Java-Cocoa libraries is linked to Apple's support for Objective-C. At one point Apple was saying that Objective-C would be gradually replaced by C++ at one extreme and Java at the other. However, they seem to have realised that Objective-C and the tarted up OpenStep libraries are nice enough to work with that no one really wants to use C++, and that Java developers are going to stick to the plain ole JDK for their apps (either through familiarity or not to sacrifice portability).

Re:Why Apple?

[am 2k]

Having Java ship with the OS installation does have some benefits, though. Especially for Java developers working on applications for end users.

Re:Why Apple?

[VGPowerlord]

Because Apple provide Java on Mac OS, not Sun. Remember how Microsoft provided the Windows version of Java, before Sun got pissed off with what they were doing with it and demanded it back? Same thing here, only Sun haven't got pissed off yet (hopefully soon!).

As far as I'm aware, Apple hasn't added a bunch of new commands to Java, then encouraged developers to use those commands as to make programs not work on Sun Java.

Re:Why Apple?

[cthulhu11]

Apple's existing Java 5 is a bit screwy - I'd been hoping that a Java 6 from Apple would fix eg. the Java Web Start hassles when trying to run Sun's Remote Console, which with a stock setting on OSX somehow tries to run Java 4 despite preferences to the contrary.

Re:Why Apple?

[wwwillem]

Since OS X, Apple has been a big supporter of Open Source software
Do you mean that in the sense of "using open source" or of "contributing". I like Apple, but objectively I can't remember much of the latter. I could be proven wrong of course.

Re:Why Apple?

[J.Y.Kelly]

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

Well one reason I'm a bit miffed is that Apple turned up at ISMB this year and were touting the advantages of running Java on OSX. They were very vocal about the continuing and improved support for Java in 10.6 and I guess that doesn't sit well with 10.6 coming with essentially the same version of Java as 10.5.

Re:Why Apple?

[srmq]

That's nonsense. Sun owns the copyright of the JDK code and can continue to license it to Apple under whatever license they seem fit.

Re:Why Apple?

[stinerman]

Since OS X, Apple has been a big supporter of Open Source software - but NOT Free (GPL'd) software.

You mean they're a supporter of F/OSS but not copyleft software. The BSD license is just as (if not more so) Free and Open as the GPL (for certain values of Free and Open).

Re:java 6 is FAST

[Anonymous Coward]

What the hell is WASD and why do you use it?

Clueless

[FranTaylor]

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:Clueless

[somersault]

*Whooooooosh*

(hint: iPhone)

Re:Clueless

[somersault]

Probably because you didn't get it

Re:Clueless

[LKM]

I don't think GP was joking. I think he was just dumb.

Re:performance of other java apps?

[FranTaylor]

Probably not. This is only good news if you need JDK 6.

mod parent UP Re:Why Apple?

[damn_registrars]

I suspect I'm not the only person who didn't know the answer to this person's question. I have no idea why someone felt the need to mod it "troll".

And even further into the thread, it is pointed out that the answer lies in Apple's earlier promise to provide Java for OS X people (rather than Sun doing it). I suspect I'm not the only person who wasn't previously familiar with that, either.

Who needs Java 6?

[FranTaylor]

Where are the Java 6 apps out there that make this necessary? Java 6 introduces incompatible changes to JDBC, so new database drivers are necessary.

Okay, developers need it, but why not develop on Linux, which has had Java 6 for some time now?

"Write once, test everywhere"

Re:Who needs Java 6?

[AmaDaden]

http://en.wikipedia.org/wiki/Java_version_history 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.

Re:Who needs Java 6?

[aled]

Java 6 introduces incompatible changes to JDBC, so new database drivers are necessary.

Care to elaborate? I'm using jdbc drivers from before Java 6 was released with no problems.

Re:Who needs Java 6?

[FranTaylor]

I don't have it all in front of me, but some of the MetaData functions return new values that they didn't before. Basic users of JDBC don't care so much, but things like object serialization and code generators are affected.

still no native swing?

[twoboxen]

No swing, no thanks... yet.

Re:still no native swing?

[Mercano]

Native swing... you mean AWT? The problem with native controls is that they behave differently and have different capabilities from one platform to the next, meaning that if you are trying to create a cross-platform wrapper library around them, you have to aim for the least common denominator. Hence, they just gave up, left AWT where it was and started work on Swing.

Because Java is more integrated with system

[SuperKendall]

As others have noted, Java on the Mac is handled more by Apple than by Sun.

But there are good reasons for this - Java on the Mac is more tightly integrated than with other systems. For example if you load multiple Java apps, you are not getting multiple instances of Java libraries loaded...

There is also a Java-Cocoa integration layer, which though deprecated has to be supported and tested.

It's true that Java ports have lagged behind other platforms, but there are some compensations in return. That said it's good to see some option for Java6 support for people that need that.

Re:Because Java is more integrated with system

[mabhatter654]

I like the Java/OSX integration.. apps look and behave very close to Mac apps... even the simple little ones. But the Java 6 implementation is annoying. There WAS a Java 6 beta but the week before Leopard launched it disappeared. As I'm taking Java in school this semester, I was eagerly awaiting the released version when I got leopard.. disappointing.

Re:java 6 is FAST

[somersault]

It's the preferred keyboard layout of first person shooters, ever since Quake (or in my case, Half-Life). I use it because I can have other keys around my fingers to easily access buttons for reloading, using items (such as doors and health stations), jumping and ducking (easily done at the same time when the duck and jump keys are located conveniently under my thumb and pinkie), running, switching weapons, and even checking my score (usually only in multiplayter). You should try it instead of those stupid arrow keys..

Re:It IS available!

[revscat]

No it's not. That's J2SE 5, release 6.

Who are these "many" Mac users?

[Logic Bomb]

Who are these "many" Mac users who are supposedly upset about Java 6? There were a couple of very loud-mouthed blog posts at the 10.5 release date, but other than that.... Java developers surely don't make up a group of "many" Mac users.

Re:Who are these "many" Mac users?

[MemoryDragon]

Actually there are many java developers, but many of them have left the mac for developing java apps.

Re:Who are these "many" Mac users?

[filterban]

Count me as one. It'd be more of an issue to me if we were developing on Java 6 yet, but our apps have primarily been written in Java 5, so my Mac has worked great. Apple needs to keep up to date on Java so the newest Java software (a large portion of which is written in Java so that it's cross platform) will run on Macs.

Re:performance of other java apps?

[AmaDaden]

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). 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

[apsmith]

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:Nope

[jeremyp]

I have a DMG with a Java 6 beta that I downloaded from Apple a couple of months ago and haven't installed yet. Unfortunately, it no longer seems to be available on the ADC web site, so they must have pulled it.

Java whiners

[revscat]

(Note: I am a Java developer by day.)

There was a huge, huge stink in the Java community when Leopard was released without Java6. Teeth were gnashed, complaints were shouted from the rooftops, great offense was taken. Threads of truly astonishing lengths were generated.

Watching all of this transpire made me incredibly embarrassed of the Java community. (Note: Predictable smart-ass comments can be inserted after the previous sentence.) The hue and cry was simply amazing and, let's face it, immature. "I want Java6 *now* and since it's not there I'm abandoning the Mac as my platform!" In other words: "I'm taking my toys and going home." Very, very few of the complaints were from people who actually depend upon Java6, i.e. are building apps with it. Instead, there was a large sense of entitlement that was unjustified and exhibitied a childish impatience that was amazing to watch, with a strong dose of the usual fanboy/hater streetfight.

*shrug* There were two choices that were much less reactionary: (a) wait for the Apple release Java6 or (b) work on the OpenJDK project. Kudos to Landon for doing this. It's a big start, and will hopefully generate enough interest to move it forward significantly.

Of course, people like to bitch, and neither of those choices fulfills that need.

Re:Java whiners

[Knara]

You forgot 3) "switch to an operating system where your development tools aren't beholden to the whims of a single OS+Hardware vendor"

Re:Java whiners

[mgkimsal2]

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:Java whiners

[thomas.galvin]

Watching all of this transpire made me incredibly embarrassed of the Java community. (Note: Predictable smart-ass comments can be inserted after the previous sentence.) The hue and cry was simply amazing and, let's face it, immature. "I want Java6 *now* and since it's not there I'm abandoning the Mac as my platform!" When I made the switch to Mac, one of the big selling points was Apple's clear statements that "Java was a first-class citizen," and "the Mac is the best Java development environment available." And for a long while, that was true.

Java 6 was released in 2006. Java 5 is from 2004. People aren't crying "we want Java 6 now," they're saying "we'd like your 'first-class' citizen to be updated to something written in the last three years." I don't think that this is unreasonable.

Re:Java whiners

[99BottlesOfBeerInMyF]

You forgot 3) "switch to an operating system where your development tools aren't beholden to the whims of a single OS+Hardware vendor"

Umm, I think this article in part demonstrates that on OS X your tools are not beholden to the whims of Apple, if anyone seriously thought they were. Apple is providing less support for Java in their included dev tools, but it is not like there are not other popular development tools like Eclipse and obviously not even the runtime is being held up significantly by Apple's glacial pace.

Personally, I think Apple is making a mistake by ignoring Java, but then again, why should they do all the work when others will do it for them. I'd much rather Apple and Sun and the community worked together for the benefit of all, since Java is not going away anytime soon, but it would be foolish to rely upon any one supplier for all your dev tools. A big part of the draw of Java is the choices available; unlike .Net or the Visual environments. If this is the response when Apple does not immediately switch to Java 6 I wonder how hardcore C developers will react when/if Apple moves away from GCC.

Re:Java whiners

[xutopia]

I don't use Java, nor do I particularly like it, but Apple made a comitment to Java and failed to follow through.

Re:Java whiners

[Jay L]

*shrug* There were two choices that were much less reactionary: (a) wait for the Apple release Java6 or (b) work on the OpenJDK project

You say that as if there's necessarily some Java6 Apple release to wait for. AFAIK, Apple's had no comment on when-or-if they plan to release a Java 6. It was in Leopard, and then it wasn't. For all we know, it could be completely dropped due to the licensing issues above.

Re:Java whiners

[shawnce]

Apple almost NEVER comments on unreleased products or road maps. In fact Apple's engineers are explicitly told not to comment on future products. So expecting them to comment on Java plans (out side of normal NDAed channels, aka WWDC, etc.) is holding them to measure that they cannot possibly match.

Also Apple always outlined that the final feature set of Leopard would be locked down until it shipped.

Re:Java whiners

[shawnce]

I wonder how hardcore C developers will react when/if Apple moves away from GCC.

Likely many will dance in the streets. /me points at clang

Re:Java whiners

[petermgreen]

What licensing issues? some ignorant people here are mentioning the GPL but unless the GPL is included in suns contract with apple (which I very much doubt then it it totally irrelevent.

Sun insists that everyone who contributes back to the main java tree signs a contributor agreement so that sun can offer that code under any license they like.

Re:Java whiners

[jim3e8]

Java used to be a first-class citizen. The writing has been on the wall since before Apple made the announcement, over two years ago, that the Java API for Cocoa is deprecated in Mac OS X version 10.4 and later. Although that's discouraging for Java developers, things do change.

Re:Java whiners

[Unoti]

Apple's engineers are explicitly told not to comment on future products. So expecting them to comment on Java plans...

I think the complaint is with management, not the engineers.

Re:Java whiners

[revscat]

Java 6 was released in 2006. Java 5 is from 2004. People aren't crying "we want Java 6 now," they're saying "we'd like your 'first-class' citizen to be updated to something written in the last three years." I don't think that this is unreasonable.

Java5 is available now. Has been for a while. Java6 is not, but that's not three years.

Re:Java whiners

[revscat]

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... It's the not knowing which is causing *most* of the frustration, not the fact that it's not here right now.

I tend to agree with you, and meant to mention this in my original post. What was frustrating to me was the persistent subtext of "Apple has abandoned Java!" throughout the discussions I saw. Java releases have always trailed OS releases by 8 months or so. Patience -- not an infinite amount, but *some* -- seems not just wiser but historically justified.

Having said that I also wish Apple were more communicative.

When your livelihood is at stake, you might get a bit bitchy.

Yeah, but if someone is basing their livelihood on a beta version of a product... Well, don't expect sympathy if that beta is yanked.

Re:java 6 is FAST

[somersault]

Maybe you should do some research into common human (and slashdotter, which tends to fall loosely into the 'human' set) behaviours.

*Whoooosh*

Re:java 6 is FAST

[DCstewieG]

Y'know, I almost added a disclaimer just in case you were failing miserably at being sarcastic. Sorry.

Re:java 6 is FAST

[somersault]

Yes, perhaps I was a little too deadpan. I had hoped that the laboured nature of my description was enough of a giveaway..

Re:java 6 is FAST

[DCstewieG]

Ha, that's actually what made me think you were clueless :)

Re:java 6 is FAST

[somersault]

;) It wasn't really meant to be sarcasm btw, I just have a weird sense of humour is all - I'd actually already found that wikipedia page when finding out what WSAD really was :P

Re:java 6 is FAST

[DCstewieG]

Well the mods are on your side so I guess you're okay. And now this thread has been long enough so I say good day sir!

Intel Only for now

[dadragon]

I'd like to see a powerpc port, and I'd be willing to work on it if I understood the platform a little better. I'll wait for Apple to release Java 6, I guess.

I am confiscating your Golden Hammer.

[Lethyos]

Is it weird to have both hammers and screwdrivers? While on the topic, I remind you that virtualization is used throughout modern operating systems, and in ways that are completely transparent to you. A Java runtime environment is just one of many such forms.

Re:I am confiscating your Golden Hammer.

[happyemoticon]

I think this is an example of a good analogy taken too far. For it to apply completely, you would somehow have to implement a screwdriver within a hammer, or perhaps assemble a virtual hammer out of screwdrivers, which is downright farcical.

And thanks, everyone who helped answer that question. It was pretty interesting.

Re:performance of other java apps?

[Adm.Wiggin]

Re-packaged I could understand, but what's all this about recompiling? Java bytecode is still Java bytecode, no matter who compiles it.

Just wanna say thanks

[theolein]

It's people like this who help us idiots who believed that Apple would finally provide timely releases of the JDK after it was no longer the language de jour.

And convince your customers to do likewise

[Foerstner]

(The subject says it all, but the lameness filter doesn't pay any attention.)

java 6 is available for osx from apple already...

[sentientbrendan]

last time I checked you could download it from apple's developer site

Re:performance of other java apps?

[AmaDaden]

Yes but there is more then one way to compile a program. Back in the day people thought high-level languages could never work because a compiler that turned Fortran in to ASM would never be able to match the efficiency of the ASM code generated by a programmer who was trying to write a program to do the same exact thing. Over the years compilers got smarter and now it's hard for a programmer to match a compiler. In the same way a newer Java compiler could be smarter and write faster bytecode code. I just have no idea what is more important, the Java compiler or the JVM.

Re:So it's entitlement, then?

[mean pun]

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.

warning 'Java is slow' troll alert in 3..2..1..

[Anonymous Coward]

Most people don't realize that once algorithmic complexity has been taken care of (no, a computer AI won't find -- yet -- a better way to solve 0-1 knapscak than a good DP algo), systems that do modify an executable in real-time will always be faster than whatever a computer programmer could come with in his wildest assembly dreams (and, yup, this comes from an old former assembly language programmer).

This has been shown in, what, the eighties, by HP with their project Dynamo, reordering on the fly assembly instructions to gain speed. You think you can order and pad every single assembly opcode so that you have optimal perfs? Across today's deeply pipelined/parallelized architectures? You can't. It's a fact. A good JIT 'interpreter/compiler/you-name-it' can. It's a fact too.

Major financial project here... We just ported a huge project, running across hundreds of machines, from C++ to Java (Monte Carlo simulations). Major reason? Easier developping environment (easir debugging, easier profiling, easier code coverage, easier testing, easier you-name-it), easier maintenance. Perfs? Slight edge to Java thanks to the JIT.

Java, when done correctly, is blazingly fast and keeps getting faster and faster with each release. You have to be a very blind man not to see that.

But have fun from the top of your ivory tower screaming "Java is so slow"... Poor blind man.

Re:warning 'Java is slow' troll alert in 3..2..1..

[MenTaLguY]

One more thing: if your code has to deal with a wide variety of workloads, it may be impossible to statically optimize it for all of them. However, a JIT can optimize the code for the particular workload it is given.

Re:performance of other java apps?

[Adm.Wiggin]

I was always under the impression that the bytecode was a fairly direct representation of the original source code, but your ideas make much more sense. Sorry for my ignorance.

However, I would still place more weight on the JVM, because it's the meat of where the program runs. I believe these run-time optimizations are critical for Java to meet or surpass C++ in speed. As has been stated earlier in this thread, there are lots of cache-type optimizations that can be made at run-time by the JVM that even an optimizing compiler cannot make.

Re:java 6 is available for osx from apple already.

[LionMage]

This has already been addressed elsewhere multiple times, but...

First, there is a "Java release 6" available for OS X which is not Java 6, it's a sixth release of Java 5 for Tiger. If you carefully read the blurb on Apple's developer site, it does say that it is in fact a newer release of JDK 1.5, not JDK 1.6 (aka Java 6).

Second, Apple made a beta of Java 6 available long before Leopard came out. The early access release of Java 6 coincided roughly with JavaOne 2006; I actually attended the BOF session with Apple's Java engineers, where they demoed it. This beta was yanked from Apple's developer site over a month before Leopard was released. (Sorry, I don't know how long exactly before Leopard's release the download was pulled -- I just know that, when I went to look for it around the same time that I was looking to purchase an Intel Mac, the download was missing.)

Re:performance of other java apps?

[AmaDaden]

I believe these run-time optimizations are critical for Java to meet or surpass C++ in speed.

Considering the out come of the Fortran vs. ASM battle I talked about I think that day will come. It makes me wonder if FireFox were written in Java would it still have the memory leak issues it has been having (and yes there are ways to make memory leaks in Java. It's just harder). In any case I just look forward to the day where anytime a program is written in Java people don't immediately consider it slow and worthless.

Re:java 6 is available for osx from apple already.

[LizardKing]

There was some sort of "developer release candidate", but I can't find it on the Apple dev site anymore, and have seen blog comments that suggest it's been pulled.

One of the "whiners"

[AmaranthineNight]

I was one of the people who was waiting to see Java 6 for the Mac. I'm a college student learning Java, and the instructional demos from sun require JRE 1.6 to run. I need Java 6 on mac so that I can take a peek at, and run, the example code. It's good to hear that somebody has stepped up and provided the JVM that Apple decided not to bother releasing.

Re:So it's entitlement, then?

[shawnce]

FYI... Apple seeded J2SE 5 with developer previews of Mac OS X 10.4 and when Mac OS X 10.4 shipped it did not include J2SE 5. The reason it got pulled was to give Apple's Java team more time to fix bugs bugs.

In the case of J2SE 5 the extra 3 weeks time between final seed of 10.4 and shipping of 10.4 (DVD stamp and packaging time) allowed them to correct most of the issues with J2SE 5 so that they made J2SE 5 available as a download on the same day the OS was released. Of course I would argue that they should have worked on J2SE 5 a little longer given the various bugs the first release had.

I have every reason to expect a similar issue is taking place with J2SE 6 and Mac OS X 10.5... note it is obvious that Apple's Java team has been primarily focusing on J2SE 5 improvements / fixes for Leopard (including a 64-bit version of it) and updating Tiger to later versions of Java 5 and 1.4. IMHO it makes sense for them to focus on the current mainstay of Java on the Mac (J2SE 5) then focus on bringing out the latest J2SE (aka Java 6) afterwards.

Re:first class what?

[micromuncher]

You have fallen to the Apple PReng machine! In 1995 Apple said the Mac would be the best Java development platform at WWDC. Repeated in 1996. Yes, pre-Jobs/OSX, but subsequently Apple would put ONE developer on Java/JDK ports, a position oddly they found hard to staff (heck, they asked me), and as I understand it, this under-resourcing of Java development has continued to this very day.

(I used the be a MacOS developer by day, and then became a Java developer by day. I continued through Rhapsody development and finally threw in the towel with 10.1.)

Re:java 6 is FAST

[leenks]

The grandparent asked what WASD was not WSAD. Sure, it was a typo (or a deliberate context-joke) but still ;-)

It's okay guys! I just got the memo

[pizzach]

I just got the memo, guys. Apparently there was some confusion between the Java department and the higher ups. When Java Version 5 Release 6 was released, the developers were shifted to help work on the next iPod release. Yesterday the mistake was realized, and Java Version 6 work has begun. Expect it included with the next OS release.

Please don't hit me...well not hard anyway. I first started doing object oriented programming on Mac OS X with Java so this story does hit a cord. I can't help but wonder if Java 6 will be available to older releases of Mac OS X than 10.5.

Re:java 6 is FAST

[Bearhouse]

Urm...only for QWERTY keyboards. Ok, for pendants, you can remap them...

Re:performance of other java apps?

[petermgreen]

I was always under the impression that the bytecode was a fairly direct representation of the original source code
It is similar enough that there are a number of programs that can turn java bytecode back into reasonablly readable (you lose local variable names and comments but the structure stays pretty much the same) java source code.

IIRC the ammount of optimisation possible at compile time is very limited due to needing to pass the bytecode verifier.

Just tried with Jython

[hotfireball]

I've just tried the same with Jython 2.2.1 and I can confirm, that CPython 2.5.1 is slower around 10% than Java 1.6 + Jython 2.2.1 on my Leopard machine. Damn weird...

Re:java 6 is FAST

[somersault]

Pedants.

There has to be some irony in there somewhere.

Java is important for Mac users

[LKM]

I really meant to imply that besides Java developers nobody uses client side Java applications. I probably should have been clearer and just said that Java sucks.

There are actually quite a few Java apps that are important to many Mac users. Obviously, if you're running Mac OS X Server, you might want to run stuff like Apache Tomcat. User-level Java Mac apps include stuff like XML mind, which is widely used to write docbook documents. It's also kind of interesting that some Java apps running on Macs try to hide the fact that they're Java apps, because many Mac users have an irrational hatred of Java (probabbly due to the incredibly bad performance and looks of early Swing apps).

MacUpdate lists Java-based teaching apps, CAD Software, Microscope Image viewers, Magic card databases, iTunes helpers and a ton of games.

I'd say a huge number of Mac users have at least one or two Java apps on their Mac, probably without even realizing the apps are written in Java.

Both

[LKM]

Since OS X, Apple has been a big supporter of Open Source software Do you mean that in the sense of "using open source" or of "contributing".

Both.

Apple uses a lot of Open Source projects (which is a good thing even without giving back), but they also write code for a lot of OS projects, and even host a few of their own.

Unrelated

[12357bd]

There was a firehose entry about a serious gcc bug (wrong sign in inlined abs() mixed with negative constants) those last days, but it never reached the main/developers page.
It is that 'normal'???
It should be clearly advised to any developer using gcc right now.!

Mac users?

[kapowaz]

Many Mac users have been upset...

Shouldn't that be Many Java developers... ? I don't know of a single Mac user who has complained except those who also happen to be Java developers.

Re:java 6 is available for osx from apple already.

[udittmer]

Indeed, it was pulled a couple of months ago. And even if someone gets their hand on it, it doesn't work under Leopard (10.5). Of course, it hadn't been updated before being pulled for a long time.

Re:This proves open source "whiners" wrong

[MenTaLguY]

The guy ("these people") was already JRL licensees, so he did the initial work under the JRL. But he couldn't have released it publicly that way. The difference now is that he's able to port the work to OpenJDK and actually release it for total public consumption. I think that's an important detail.

Apple: Integrate X11 completely!

[backspaces]

The simple solution is for Apple to integrate X11 completely into their existing windows system so that the X11.app simply goes away, and all linux/unix apps simply run without the need of X11.app.

Then Apple's Java could always start as an X11 version, possibly from Sun, then be better integrated later into Cocoa if needed.

Re:So it's entitlement, then?

[Workaphobia]

I thought the entire philosophy of purchasing Apple products was that you expect them to work and do everything you need them to, because you're royally screwed and have no recourse if they don't. You know, the part of that old operating system to airline analogy where the stewardess politely tells you that you don't need to know this and that, so just enjoy the ride?

Still, it did strike me as weird that Apple was responsible for a Java VM, and not Sun.

Re:java 6 is FAST

[Bearhouse]

Guilty as charged, M'lud!