Slashdot Mirror
Will Sun Open Source Java?
capt turnpike writes "According to eWEEK.com, there's an internal debate going on at Sun whether to open-source Java. (Insert typical response: "It's about time!") Company spokespersons have no official comment, as might be expected, but perhaps we could hear confirmation or denial as early as May 16, at the JavaOne conference. One commentator said, "Sun should endorse PHP and go one step forward and make sure the 'P' languages run great on the JVM [Java virtual machine] by open-sourcing Java." Would this move Java up the desirability scale in your eyes? Could this be a way to help improve what's lacking in Java?"
"Will Sun Open Source Java?"
No, haven't they already said that? Like hundreds of times? And does it really matter?
Sure it matters. A lot of people have issues with it because of the license. It would clearly expand the number of potential adopters to go open source. More adopters will mean better tools.
"Sun should endorse PHP and go one step forward and make sure the 'P' languages run great on the JVM [Java virtual machine] by open-sourcing Java."
"No", who would run PHP on Java anyway? Why? Why would open-sourcing it help?
Well, I agree with the first part. But presumably integration will get better/faster in open source.
"Would this move Java up the desirability scale in your eyes?"
No, Java is already desirable in my eyes.
But a lot of people would find it more desireable. You can trust that java won't go away in open source, whereas you can't really say the same as long as SUN is at the helm.
"Could this be a way to help improve what's lacking in Java?"
No, what is lacking?
Mostly modernizing. The pace of java development is glacial, compared to say what is going on in C# or Ruby. People with specific integration issues that can't get sun to address compatibility problems are stuck.
People who complain that Java is slow, should be open-sourced, and so on have never seemed to had a clue.
There's no doubt java is still slow in a number of contexts. There are also obvious opportunities for performance enhancement that could be addressed in an open source process. I recently benchmarked ten of my applications in c++ and java, java is about 2x slower for most of the cases I tried, and never faster. To me, that's perfectly acceptable, but java could make more inroads into other areas of computing if it was more competitive in performance. More inroads means more developers, and that means better tools, which is what I yearn for.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
So what exactly is the problem?
:-) Plus, it's even more concise than C (which is saying quite a bit), is safe and garbage-collected, has very strict typing (I've heard one ML fan say "If your code compiles, it's correct" in only half-jest)...ah.
I don't have the Sun JDK on my Fedora system by default because of the Sun license.
Meanwhile, Microsoft has been adopting ocaml as the next big language. For once, Microsoft is technically ahead of its competitors -- ocaml (which Microsoft did not produce) is very fast and safe, and from a technical standpoint is much more impressive than C# and Java.
Plus, ocaml can be used as a pure functional language -- such languages eliminate almost all the reason to use (error-prone, difficult to guarantee correctness with) threads. Pure functional code is inherently parallelizable any time the compiler can say "hey, no data dependency here".
Ocaml is picking up quite a bit of steam -- there are a slew of open-source libraries for it out there, it's the only safe language that I'm aware of that provides performance comparable to C and C++, yadda yadda yadda. The INRIA ocaml compiler is open source (though, annoyingly, QPL instead of GPL). The runtimes and the stuff that you stuff into your code is LGPL. I didn't realize that Microsoft was backing it and integrating ocaml support into Visual Studio until quite recently, though. There have been gtk+ bindings for ocaml for a while, but MS may actually be ahead of the OSS world in providing complete ocaml bindings.
If you've never used ocaml before, wait until the first time you break in the debugger at a problem...and then step *backwards* to watch the problem occurring. It's simply delightful.
What's particularly satisfying is that C was well-designed -- for a specific set of systems and circumstances that don't apply to most application software development today. Ocaml is the first language in a long time that I've seen where I can say not just that the language has good ideas, but that it is really well-designed. It's also a lot better-suited to application development than C is.
Gah...sorry. Ocaml gives me the warm fuzzies.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
PHP is probably one of the best (worst) examples of what a language would look like if it was designed and developed incrementally in an open source community. It's hack upon hack upon hack. It's backward compatibility breaking changes is just about every point(!) release. Register_globals enyone? Magic quotes? Ambivalence towards types/objects - "type hinting". Arguably (and freely admitted by the designers) PHP is *not* a well designed language. It's a pragmatic ooops kind of language whose main advantage is a large (albeit somewhat amateurish) user base, and free availability. Java on the other hand - if anything - tends to be over-engineered. Swing is actually more flexible than even .NET Windows Forms (which was designed later). It's easier to combine widgets, e.g. put textboxes inside tree nodes, etc. Swing may be a little slow, but nothing Java has ever had that "hackish" feel to it. It's always well thought out. Same thing could be said about JSF, JDO and certainly EJB.
Sun has always taken great care of minimizing BC breaking changes. Sun has always taken pride in being a little on the conservative side, i.e. only introduce well understood technologies. This has been received well by the enterprise developer community. PHP is nowhere near that yet. There's still tons of BC breaking changes in store for PHP developers when PHP finally will get namespaces, unicode support etc.
To put it simple, the primary virtues of Java is nowhere to be found in PHP. And frankly, if PHP is the way a language looks like when it's designed by an open source community, open sourcing Java would possibly destroy it. A model like eclipse where it's formally open sourced but in reality still maintained by a single, competent organization might work, though.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I'm not sure if you're complaining about development of the language and standard library API, or development of Sun's implementation. The language evolves about as fast as is prudent, because they're committed to having the language not have badly-designed features that need to either be incompatibly dropped or painfully maintained. So Java gets features essentially as soon as C++ has made all the mistakes related to those features.
On the other hand, Sun's Java compiler has always had broken dependancy tracking (at least since I started using it heavily in 1999). (If a build has an error, the set of output class files may be such that the next run of the compiler skips a source file which needs to be compiled; this is mainly that it can generate the public class without generating other classes in the same file.) I think it's likely that, if Sun does open source the JDK, they'll get fixes for a number of annoying flaws of that sort pretty quickly, and things that are clearly wrong but aren't considered worth working on will be improved substantially.
Of course, there's essentially no chance that they'll relax their grip on the language standard, and they probably shouldn't, unless they turn it over to a standards body due to no longer being able to employ good language designers.
you are correct. but whatever we saved using java to get the project started, we have already spent trying to figure out why, oh, why java croaks on OutOfMemoryException when we have more than 8G of ram most of which is not being used.
on a more philosophical level, there is already an excellent VM that *can* use all the 8G and then some. it's called linux. using java to build apps because it's easy to program in is like using tonka trucks because those trucks are so much easier to handle than the real thing. after all, why pay commercial driver rates to drive a multi ton truck when you can get you own kids (for free) to 'drive' the tonka trucks.
i learned java back around '95, '96 and was really excited about it then. but after having used it on some really large projects, i have been really really disappointed and came to the conclusion that the only real contribution of the JVM was a serious neutering to most modern advances in the OS.
forget portable programming languages - use a portable OS - linux. and forget the V, use the M (tm).
anyhow, Guy Steel was right. i am looking at lisp right now (mostly for emacs tho).
I still fail to see the benefits of "open sourcing" Java. How will it be improved? It's not as if the engineers at Sun are stupid and don't know how to engineer enterprise software.
Honestly, that's part of the problem.
Enterprise developers are used to a very particular envelope. That involves putting up with a lot of large-company bullshit and unfriendly tools. People in other environments have different needs that are poorly served by Java. And actually enterprise people have those needs too; they're just used to suffering.
Take all of the C#-inspired improvements in Java 1.5, for example. Many of them are about programmer convenience and improved expressiveness, neither of which mattered much until C# was a threat. Or consider EJB 3.0. EJB sucked for years until Hibernate, an open-source project, came along and beat the snot out of it. EJB 3.0 is basically a straight import of Hibernate.
Or take Ruby on Rails: you can't write that in Java. Why? My theory is that in large companies, they'll let you go away for three months and build infrastructure. Plus, neither Sun nor an enterprise architecture group trusts programmers with the kind of heavy wizardry that Rails uses to make things happen. So again, Sun gets its ass kicked by an open-source project.
If they really open it up, perhaps Sun can harness some of that power. But I'd bet they won't do it properly; Java reeks of "cathedral" thinking, and that papa-knows-best mentality is hard to shake.
All of this is terribly ironic to me. I've worked with Java for about 6 years now. It's considered the Enterprise Open Source solution (because admin types typically confuse open source with "free and runs on lots of platforms) usually. So it's either Java or Microsoft in every shop I've ever worked for. No PHP. No Ruby. And often Java is paired up with Linux, MySQL, etc. So I find it funny (although I understand the point, but it's still funny) that people consider Java to be so difficult because it's closed source. In every shop where Microsoft is the choice, the decision is usually made because the stack is predictable. It's predictable because Microsoft controls every aspect of it from the database to the app server to the language you use to code on it. So open sourcing Java would probably have the unintended consequence of giving Java a perception problem in the eyes of manager types. It would become risky on the same level as Linux and MySQL and so instead of being the safe, "adult" part of that crazy open source stack, it would just become one more piece of it. Albeit a powerful one, but it would probably push more people into the arms of Microsoft. Sorry, but that's been my experience, given what I've witnessed in the industry lately.
I have the impression that the last couple of months I see more people on Slashdot mentioning Common Lisp as a replacement for Java.
That is the reason that with SUSE you can decide yourself wether or not you use it or not. e.g. for the upcoming 10.1 version the CD1-5 are pure OSS. There is an additional CD6 that will hold the non-OSS stuff, like Opera and Java.
That way SUSE lies the choice with the user, not with the distribution. If the user still decides to use it (and many will) they still have all the advantages as they have with the different other packages that are included with SUSE, including security updates.
Don't fight for your country, if your country does not fight for you.
Gets its ass kicked? I don't see many people moving from Java to Ruby. From Perl, Python, and PHP, people are switching to Ruby in hordes. But from Java? A trickle, if anything.
You are missing my point. I am saying the enterprise approach to things only applies to a selection of software projects. Sun has ignored the ease-of-use and low-barrier-to-entry criteria for years and years. This means that small projects correctly don't use Java because it's not economical. They uses PHP, Rails, and the like.
But large projects often start as small projects, so Sun is, presumably accidentally, driving a lot of users away from Java. There is no good reason for this; the world wanted Rails, and Sun missed the boat. When I look at the Alexa Global 100, none of the up-and-comers I recognize seem to be using Java. I know that Craigslist, MySpace, and Flickr are built on those non-enterprise technologies you disdain; in a few years I'd bet will see some Ruby on Rails entries, but none for, say, Java Server Faces or Struts.
Enterprise developers are, by nature, unlikely to use Rails yet because they are relatively conservative. Java is, in many ways, the new COBOL. But Rails, which used Ruby's greater power to dramatically increase ease of use, now has created a substantial user base for Ruby.
And unlike Perl and PHP, Ruby has the potential to be an enterprise-scale language. It's a much better OO language than Java in many ways. With a few improvements, some supporting tools, and another five years, you will see Ruby invading enterprise shops if Sun doesn't counter effectively.