Slashdot Mirror
IBM and Oracle To Collaborate On OpenJDK
An anonymous reader writes "Today, IBM and Oracle announced their intent to work together to accelerate innovation on the Java Platform, leveraging OpenJDK. IBM and Oracle will also collaborate to support the Java SE 7 and Java SE 8 schedules presented recently at JavaOne and to continue to enhance the JCP."
I'm sure this IBM-Oracle teamup will produce an amazing result with the reliability of LotusNotes and the developer friendliness of an Oracle database tool.
It'll also have... well, crap. You're going to get sued if you use it no matter which parent is dominant there.
I don't see the economic incentive for Oracle to keep this project,
Maybe because Oracle, being enterprise-y, has an absurd number of applications which run on Java? Improving Java performance means nearly all Oracle applications run faster. Making Java more flexible as a language and as a VM means they have more powerful tools and better techniques going forward, which they can use for developing things which plug directly into all that legacy Java code they've got.
And while Oracle certainly has the rights to close as much of it as they like, hopefully even they realize it's in their best interests to collaborate with the community (including IBM), rather than trying to go it alone.
I'm guessing the bulk of the Dev work is transitioning to IBM.
And why do you think IBM has a better incentive than Oracle?
Don't thank God, thank a doctor!
This is some of what Java has going for it:
1. Massive standard class library covering everything from smartphones to distributed application servers
2. Huge amounts of third-party support. If you can think of it, someone somewhere has written a library for it, and chances are it's open source
3. The best IDEs in existence. NetBeans, Eclipse, IntelliJ, etc. all come with built in support for unit testing, dependency management, source control (mercurial, SVN, git, you name it), profiling, local and remote debugging, etc.
4. Agent support for instrumentation and runtime redeployment. Using tools like JRebel I can edit code in my IDE and see the results instantly in the application server, and *still* take advantage of strong typing, etc.
5. Object-Relation-Management (ORM). Tools like TopLink and Hibernate mean that you can reverse engineer a class model from a DB, or generate a DB from a class model, and use the ORM API to effortlessly add optimistic locking, transaction management, and object based queries to your app
6. Application servers support distributed transaction management (XA) and messaging (JMS) on top of a generalize connection management framework (JCA) in which any vendor can provide a standard connector (resource adapter) to their systems and participate in global two-phase transactions
7. Open driver support for virtually every data store; lots of choices for embedded in-memory SQL/RDBMS databases
8. Container-based pooling, caching, and transaction management
9. Dependency management and build systems like Ant, Maven, Hudson, and Sonar that enable you to very easily configure scheduled builds with static code analysis, automated unit tests, and concise reports of errors with references to changesets included in the build
10. Perhaps the largest collection of forums, blogs, and online documentation for any platform
11. Strong typing, API contracts, and runtime introspection identify issues at compile/deploy time, rather than runtime
12. Strong industry support from multiple vendors (Google, Oracle, IBM, RedHat, etc.)
So, if you're writing a little GTK widget for managing your MP3 collection, maybe Java isn't for you. But if you are a medium-to-large business chances are you either develop or administer an enterprise-scale Java application.
Another thing to consider is that the vast majority of Java tools and libraries are open source, and many of the specifications are formed once an open source toolset reaches a certain level of maturity/popularity. For example, Hibernate did most of the legwork for JPA; JSF was initiated largely due to the success of Struts; and WebBeans is a formal spec defining the basics what Seam provides. So all Oracle really has to do is keep the JCP going and publish the standards while RedHat (JBoss), IBM, the Glassfish development team, and everyone else provides the implementations. Oracle stays competitive with IBM and RedHat by offering a development stack (based on Oracle DB, Oracle AS, Oracle JDeveloper, etc. all of which use Java) *and* continues to collect licensing fees from the other players. Plus they have a little more say in the JCP process, which gives them a slight advantage when ratifying new APIs.
Not to mention that Java is installed in over 2.6 billion handheld devices, each of which pays a royalty fee to Oracle.
What surprises me is that Oracle is partnering with IBM on this venture. I wonder what IBM has on Oracle?
Oracle makes money selling software that uses Java.
People working on improving Java without Oracle having to pay them is, therefore, in Oracle's interest.
They claimed to be using the Java language
Actually the main plank of Google's defence is that Android does *not* run Java. The test of whether they succeed or fail is largely whether they can convince the court that Dalvik is *not* a Java VM. And sure enough if you scan the Android SDK you'll find just about nowhere that it says you are programming in Java. It's pretty weird and interesting.
The way I see, IBM is progressing now towards a stewardship role in Java, without bothering with all the SUN's hardware business (which would have been a dead-weight for it)... and this without spending a extra nickel, on top the strong investment in Java IBM already has.
Almost a perfect solution... the only drawback being the Imaginary Property in Java still being owned by Oracle (with known consequences... the minuet and other high society dances Oracle chose to drag Google into).
Questions raise, answers kill. Raise questions to stay alive.
The complaint with Google was that Google was infringing on Oracle's patents and copyrights via Android. Google's official and legal response was along the lines of, "WTF are you talking about?"
My own theory is that Sun (and now Oracle) liked the profits they were receiving via licensing royalties from mobile phones that shipped with an embedded Java environment. Google did an end-run around these royalties by developing their own third-party JVM, Dalvik. When it looked like Android would gain a decent foothold in the smart phone market, Oracle probably thought they needed to do something. Maybe they have this opinion that they "own" all parts of Java.
(My understanding is that Dalvik and Java(tm) are completely different, except that the human-readable source code for both happens to be the Java programming language. A programming language itself, so far as I know, cannot be copyrighted. Patented, maybe, but you would have a tremendously difficult time trying to find any feature of a "modern" language that doesn't have decades of prior art.)
As for OpenJDK, Oracle appears to be the copyright holder of the source code and are entitled to any Java copyrights or patents applicable to it. Whether they give it away for free or charge for it doesn't matter.
Can somebody more familiar with Java and the overall Java scene clue us in as to whether this is a good thing?
These joint announcements would appear to break the log jam that has prevailed over Java for the last few years. Sun simply didn't scale to open projects and gradually found itself at odds with the JCP on many fronts. Oracle and IBM have now slated specific items from the JCP backlog for future OpenJDK implementations, implicitly anointing both the JCP and the (open source) OpenJDK as the official future of Java. That is the closest thing to a 'plan' that has appeared in the Java world in about four years.
The Oracle vs. Google thing is very troubling. Google made Java work in a huge way on Android. Networked, mobile, embedded stuff was use case for which Java was originally intended. Java badly needs to inculcate that success. Otherwise it will assume the role its detractors have often accused of it; the COBOL of our day.
Lurking at the bottom of the gravity well, getting old
Otherwise it will assume the role its detractors have often accused of it; the COBOL of our day.
So it will be wildly successful with billions of lines of code still in use powering a ton of the infrastructure that modern-day business relies on?