IBM and Oracle To Collaborate On OpenJDK 160
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."
Oracle, OpenJDK?? Yeah Right. (Score:0, Insightful)
The last time someone fell for that Open Java BS Google got sued for daring to create a good smartphone with the language.
I would hope that by now people would realize that Java is nothing more than Patent Troll Fodder to Oracle.
"Fool me once, shame on you. Fool me tw-- you can't get fooled again."
George W Bush
It's a trap (Score:3, Insightful)
Not sure how, but it must be. OpenJDK is something Oracle doesn't make money on, as far as I can tell. Whenever Oracle touches something it doesn't make money on, it always makes an attempt to crush it between it's teeth.
Re:And Nothing(?) Was Gained (Score:5, Insightful)
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?
Re:And Nothing(?) Was Gained (Score:5, Insightful)
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?
Re:Here's a question ... (Score:5, Insightful)
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?
Re:Oracle, OpenJDK?? Yeah Right. (Score:3, Insightful)
That's not gonna hold up if their implementation still falls under the Java patents.
Re:So will they stop suing Google? (Score:2, Insightful)
Please turn in your programmer card. You've fallen for the deception that a language specification is the same thing as an execution environment, aka virtual machine, or -- even worse! -- an entire software platform. How did you become confused? Because common practice is to use Java as a cover-all term to mean Java the language, Java the JVM, and Java the platform. A programming language defines semantics, NOT the governing machine. A standard can include library details, but that is NOT the same as the core language itself.
Android uses Java the language, the Android libraries (a DERIVATIVE of the Java libraries), the Dalvik virtual machine, which together form the Android platform. Why are the libraries derivative? Because they are based on the Java class libraries, not in completeness, and the behavior of the identical libraries are not guaranteed to be the same.
Copying standard library specifications is not something new in the programming world. Look at D [digitalmars.com], which blatantly copies the C++ standard library. Why did D authors make that choice? Because the SC++L cannot feasibly be topped by recreating it; only by extending and improving on it can it be bettered. The Java class libraries were taken by Google because they are familiar to many thousands of programmers across the world, and because they have a long history of reliability and general design quality.
A simple example may help to dispel the confusion. Let's build a compiler. I want to base it on C#. The goal is to produce bytecode that runs on my proprietary VM. Technically, we could make it produce Python/Java bytecode, or (perhaps) native binaries even. After I'm done, the syntax it compiles is exact and conforming to C#, and even behaves the same way. I might take a few .NET libraries and reimplement them to work with my compiler. Not all of .NET though; it's simply too large. The compiler successfully compiles pure C# code, and a varying amount of .NET-using C# code. See the resemblance to Dalvik? My compiler and VM are not .NET-based, and have zip to do with the CLR. It's a 100%-valid C# compiler, but is unrelated to .NET.
Why is the above example easier to understand? Because Microsoft didn't name all its technologies the same: C# was never dubbed "the .NET programming language."
Re:And Nothing(?) Was Gained (Score:4, Insightful)
Because if Java fails, .NET takes over, and .NET integrates a lot smoother with MS SQL than with Oracle(not that you can't access Oracle, just that the built in frameworks are all based on SQL). MS SQL is essentially the number one threat to Oracle's business in the short term, since for the vast majority of cases it's a perfectly viable solution, generally costs less(presuming you already have any MS products in your organization), and to be honest, Microsoft are a lot nicer to deal with than Oracle.
IBM and Oracle both desperately need Java to survive, that's half the reason that Oracle bought Sun in the first place.
Re:Oracle, OpenJDK?? Yeah Right. (Score:2, Insightful)
Google is creating the same situation as Microsoft did with their custom HTML standards, once Googles implementation starts being used in other google products, and people start using that instead, it will create all kinds of problems for everyone (non-inter-operating libraries, for example).
Re:Oracle, OpenJDK?? Yeah Right. (Score:3, Insightful)
LLVM has bytecode too. Completely different bytecode than Java. I suppose that's just java in disguise too though huh?
Re:Here's a question ... (Score:4, Insightful)
Re:Not the same at all. (Score:3, Insightful)
"while the Google thing is a patent dispute, which would be as if they sued Microsoft for .NET."
They sued .NET for excactly the same reasons: VM patents.
Re:So will they stop suing Google? (Score:1, Insightful)
The key bit is "...part of the class library...". You can't take some Java code written for Sun or IBM's VM and be confident it will run on Android because parts of the core class library aren't there. That destroys one of the main selling points of Java which is its portability ("Write once, run anywhere"). And that is a big deal. I develop on Windows and Mac OS and deploy to Linux and Solaris. And it just works.
Re:Here's a question ... (Score:3, Insightful)
Yup, and most of it will be written by people who have a lot of knowledge of the problem domain and a tiny bit of knowledge of programming, making the code very hard to maintain. It will then be used for about 20 years longer than the original designers expected.
I've likened Java to COBOL before. It's not a criticism, just a point that they both fill the same niche. Java was created as a language for average programmers (that was a stated design goal) and it's succeeded in this - people with little knowledge can write (often horrible) code that works in Java. And code that works is far more valuable to most businesses than elegant code that doesn't work.
Re:Here's a question ... (Score:3, Insightful)
Saying it's not Java is like saying gcj is not Java because it compiles Java code to native code rather than to JVM bytecode.