Java Trap, 2010 Edition
journal.paul.querna.org
journal.paul.querna.org
I just saw this on twitter...
http://twitter.com/casperbang/status/27134952930
"Java has an official open source reference implementation, but is not free. C# has only unofficial open source implementations, but is free!"
http://www2.research.att.com/~bs/bs_faq.html#Java
"Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation."
Also, good luck with any kind of support that is not in the interest/hobby of D developer. I once wrote a fairly large program that was for a commercial purpose (wrote as an order) - and I got stuck on a fairly large bug in standard library which I couldn't resolve myself because I have lacked the expertise to do so, I even think it was not open sourced then also (basically free() never returned memory to the OS). That bug is still open after several years. I offered money, anything basically to get this resolved since my application crashed due to it - if there weren't for helpful Tango guys I would have to rewrite the damn thing from scratch in another language.
D1/Tango had so much potential, but it got nowhere, unfortunately. I am still bitter I spent so much time and effort in D at all, just to return to C (and some C++).
D2 of course... "Consensus is that D is dead for all practical purposes (especially D2)." BS..
There is a chicken and egg situation with D... if somebody big doesn't put some backing behind it then it will go nowhere...
Tomasz wrote it better than I can right now http://h3.gd/devlog/?p=22 and I respect his view because, if nothing else, he is the man that wrote the largest code base there is written in D (for his Nucleus engine and tools). Main problem, among MANY, is that people who are working on D these days are not coding in D at all, not serious projects at least - otherwise they would see fairly quickly what is wrong with it. This topic has been covered among D community by large now, you can dig up fallout of tango team from D2 and numerous sagas alike on digital mars newsgroup.
Additionally, it doesn't help that D is torn. There used to be the Phobos/Tango split, now there is yet another split: D1/D2. The second is definitely a more serious competitor to C++, but there is no up-to-date fully open source compiler available. Digital Mars's D2 compiler has a proprietary backend, gdc (a GCC frontend) is outdated, and ldc (LLVM frontend) does not have usable D2 support.
Oh, and if you want a 64-bit D2 compiler, even proprietary, you are out in the woods (yes, work has started).
Even the average Scheme compiler is in a more usable state ;).
Many of Apache's projects are Java-based, and I don't seem them making any effort to port all of them over into a different language.
Though Oracle stunk up JavaOne this year, and the lawsuit against Google is making Oracle look like a supreme ass, companies like IBM, RedHat, SpringSource, and many, many others have a significant investment in Java.
Java has been and will continue to be close to the top of Paul's heap in terms of jobs for the foreseeable future:
http://www.indeed.com/jobtrends?q=java%2C+Python%2C+Javascri...
http://www.indeed.com/jobs?q=java
However, I would be the first to say that if you are looking to the future, explore dynamic and functional programming languages. If I had to pick one right now, I'd lean toward Ruby, not because it is the most well adopted (and for goodness sakes, it has had enough time to be), but because the language itself is great, and it has a growing and thriving community.
But Java is not dead yet, and it is far from a trap.
Imagine, if you will, that there were no Apache. What would the Java landscape look like today? If Java at Apache flounders, the platform as a whole will also diminish. Java has thrived for so long in a Microsoft dominated world thanks largely to third-party open source efforts. If a (the?) major contributor of open source code in Java goes away, which direction do you think Java will go? "Thriving community" is not how I see this turning out.
Yes, I think there will continue to be some new projects, and other projects will fall off. Apache isn't the end-all be-all of Java projects, however.
Several of the larger newer projects were under SpringSource's wing, and there continue to be new projects there. And there's Codehaus. And some Java projects under GitHub, Java.net, SourceForge, etc. Then there's Groovy, Grails, and related projects. JRuby (formerly at Sun, now at EngineYard) is Ruby, but it allows some reuse of other Java projects. Android (like the author states) is a subset of Java, so all of those Android app projects. Kindle's KDK is Java. Your cable box may even run on Java.
If you've been only looking at Apache for Java growth, you've been looking in the wrong place.
"Or how many existing projects will have any significant effort put behind them?"
The Java projects at Apache have had continued effort put behind them, but some of the people that would have put effort towards Apache projects have spread out into some of the places I mentioned.
"If Java at Apache flounders, the platform as a whole will also diminish."
That's BS. If Apache fell on its ass, Java would still survive. See all of the other projects I mentioned, plus all of the current Java jobs I mentioned.
Where "Java" itself isn't the new hot thing, Java is dominant, and things using/requiring Java are hot, for example- look at this Google trends of Java vs. Android to see what I mean:
I know all about the new-hotness that are Groovy, JRuby, Closure, Scala, KDK, Android etc... This isn't a Java-the-language discussion. This is a Java the platform/JVM discussion. Oracle's actions so far have been pretty chilling for the entire platform. You can't run any of the above without the JVM, and that is what Oracle is controlling.
Java will survive for a long time, and I don't think that anyone doubts that. But for the first time in a long time there is some doubt about whether or not it is a platform to build future products on.
In my mind, Apache is the canary in the coal mine. It might take a while, but they will lose their position of dominance over this.
Then again, it's been a ~15 years, isn't the industry ready to promote something else as the new major language? We've already seen Ruby and Python strengthen their positions.
This is also one of those stories where the GPL (version 2) is acting in the interests of Oracle, not in the interest of the users; if only Sun released OpenJDK under Apache ... but why would they do that?
They are certainly doing harm to Java, but Oracle hasn't sued IBM yet over this and there is quite a bit Oracle would go after if it were truly intent on killing the JVM:
http://en.wikipedia.org/wiki/List_of_Java_virtual_machines
I don't think that anyone is questioning anyone looking into using other languages. I even suggested Ruby myself.
It might be a dark age for Oracle sponsoring Java Community Process development, but some of the JSRs have been crap. If development of new JSRs slows to a crawl, so be it. A wealth of Java, Ruby, Python, etc. projects have evolved without being attached to a bureaucratic standards committee.
All open-source Java implementations available (minus OpenJDK) are not certified, and can be sued for patents infringements (or trademark violations if they're advertised as being Java implementations).
Oracle just showed they are not shy on using their property.
http://blog.headius.com/2010/08/my-thoughts-on-oracle-v-goog...
My point is that no rational company would attack its own base. Oracle had some wild claims. These will be toned down and they will come to an agreement. Things will move on.
I'm not saying that people shouldn't pay attention to Oracle's antics (even though I just consider Oracle a whining child at this point), but I think this whole thing is overblown.
Conversely, by not passing TCK you don't get their patent license. Many of the patents in question are difficult (if even possible) to work around if you were to create your alternate implementation.
This means that using any non TCK implementation of Java makes you liable for patent lawsuits (as seen with the Google case).
The right conclusion to make seems to be that software patents are bad.
> Ah, so anyone using GCJ in a product could
> be sued the same way Google was sued. I
> didn't know that.
this is exactly the point. And this might also be (one of) the reason(s) why Google PR is calling the suit against them a suit against Open Source in itself.Can they do that, being the OpenJDK GPL-licensed? IIRC, it shields the OpenJDK, as well as GPL-licensed derivatives, from patent lawsuits.
It doesn't protect Apache/MIT/BSD-licensed implementations, but who cares, if there is a GPL-licensed implementation available?
Clean-room reimplementation are not though.
Harmony was created to have a non-GPL implementation (and was used by Google for that reason)
Releasing code under the GPL does not give the open source community carte blanche access to all your future patents, perhaps unless those patents are necessarily infringed by the original GPL release.
And the OpenJDK folks can always implement around those patents.
GCJ is old... and OpenJDK does have access to the TCK IIRC...
Of course it does, access to the TCK was always at Sun's discretion to give.
OpenJDK doesn't matter, Java is not free to be implemented by open-source projects (even though JSR 270 explicitly says so) because the TCK licensing prohibits it.
It is also irrelevant if GCJ is old, patents don't have a "use it or you'll lose it" clause as trademarks do.
http://www.excelsior-usa.com/jet.html
It is licensed...
Google is the one that wants to keep it's advertisement machine going. It matters to them that over the next few years an open and mobile competitor is around. It doesn't matter to me.
He also criticized the JVM.
"not resulting in as healthy an ecosystem"
No ecosystem? Clojure, Lucene/Solr, Cassandra, Groovy, Hadoop to name a few are all part of this excellent ecosystem.
Edit: There's some serious group think in HN. It seems any kind of alternate opinion gets immediately down modded. You may disagree with my opinion, but it is a valid and relevant opinion: Is all this lawsuit crap between the MegaCorps relevant to the average developer using Java for services?
And I agree that java has a large ecosystem built on top of it, making it even more important that the underlying stuff doesn't get controlled by one person.
Here's some context: http://www.apache.org/jcp/sunopenletter.html
Also, all these language implementations are symptoms of a larger problem, can you guess which?
I'm just saying all these articles about the death or lameness of the JVM are not covering the big picture.
Believe it or not, I'm using Solr, Groovy and Clojure and in my eyes the (approved || sanctioned || blessed) JVM has never a better platform.
Oracle's patent lawsuit against the Dalvik VM has cast a cloud on deep innovations in JVMs, such as GC implementations tuned for Clojure.
Is there going to be a long term problem? Who knows, who can say? All we know is that Oracle's lawyers were eager to sue Google whereas "patent suits [were] never in Sun's genetic code" (http://nighthacks.com/roller/jag/entry/the_shit_finally_hits...); what follows will depend on how that goes and who knows what else.
At the very least I'm pretty sure this is having a chilling effect. If you have various areas in which you can do things, why do deep JVM innovation. E.g. for Clojure, perhaps Clojure-in-Clojure targeting another platform, most especially x86_64? (This is not idle speculation, BTW.)
I'm just saying the sky isn't falling for the average developer that is using the JVM. We'll all be using XYZ technology, which hasn't been invented yet, in 3-5 years anyway.
Google is the one with the short term vested interest in distributing a VM that runs Java.
The Android _SDK_ is Java based. The Android apps are written in Java, the language, compiled into Java bytecode (Java class files) and the class files are converted into single dex file, which is custom instruction set. Then the app is moved onto the device and run.
The Android runtime is neither Java, nor JVM. It is custom (proprietary) VM that happens to use library that is API compatible with Java's standard library (Apache Harmony compiled and converted to dex; again, no java bytecode in sight).
It's really hard to miss, right under the title, in big bold type:
I've read many arguments about how Dalvik is 'different' and some or all of these are 'safe' and so on, but the reality is that 'safe' is whatever Oracle decides it is.
Wait - what users of non-Oracle/Sun JVM implementations have been sued by Oracle?
Oracle sued Google as the maker of a non-licensed (and supposedly copyright infringing) Java Virtual Machine. To my knowledge, no one has been sued for merely using a non-Oracle JVM, have they?
Now, you can either ignore the bug, and hope that it gets fixed. You can work around it. You can use a different C compiler that may not have the bug. Or, you can fix the bug yourself.
Now, lets say instead of C, you're writing Java. Given the situation that Oracle seems to be attempting to make, the first situation won't get you sued, but it will leave you will a bug. The second choice is the best option. But, the bug still needs to be fixed at some point. The third choice might not be possible, because Oracle will have sued everyone else who has a JVM implementation and forced them to stop making an alternative, leaving you with the buggy Oracle/Sun JVM. And the last choice will get you sued.
And, to be frank, three of these four choices suck, and the remaining one isn't a joy to work with either.
It was Sun approved, and I see no reason Oracle would change that unless they want to fsck with OpenJDK in general. But, again, who knows? Oracle is the new Java steward and their polices, so far some good, some bad, are demonstrably different than Sun's were.
From http://openjdk.java.net/legal/gplv2+ce.html
"6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
and
"7. (...) For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program"
How this plays out with OpenJDK and its derivatives I don't know; I'd assume they couldn't do anything for Java 6 (and I don't want to borrow trouble), but couldn't they e.g. in theory refuse access to the Java 7 TCK, resulting in a freezing of the GPLed version?
Anyway, my point here is that their GPL license of their technology is a much more restricted use of the license than we're used to.
No, that is not correct. The OpenJDK license is the GNU GPL plus a liberalizing exception for the Classpath. Possessors of the GPLed JDK are permitted to make and distribute modified versions without passing the TCK.
No. Since it's licensed under GPL, it's completely Oracle-proof. The license is valid regardless TCK compliance.
> How this plays out with OpenJDK and its derivatives I don't know
Any derivative is also covered by the same license.
> refuse access to the Java 7 TCK, resulting in a freezing of the GPLed version?
OpenJDK can gain any features present in JDK 7. As long as it's derived, Oracle can do nothing about it. What may get you in trouble is calling it Java without passing the TCK. I am happy with changing JDK and JVM to "Just-Like-Their Development Kit" and "Just-Like-Their VM".
It will be funny if, in the end, it's Stallman who makes Oracle into a civilized corporate citizen.
Python is a great choice too, provided you don't mind about performance (which is true in the majority of applications).
[1] - Note: not a realistic possibility. Someone would pay a billion dollar ransom instead. But the fact that the threat is out there, regardless how how credible it is, shows the problem.[2]
[2] - Note: the problem in this case is NOT due to non-free implementations: no one questions whether Dalvik is sufficiently free. The problem in this case is software patents. The only proper fix for that is to change the law. Please call your congresscritter.
Sun demanded a mobile usage restriction. Oracle is suing a company that for technical and no doubt monetary reasons went around this restriction. Oracle now can't make up with Apache without undercutting their lawsuit, even if they were so inclined, which strikes me as unlikely.
The argument being that 3rd parties have no means to validate their implementation. Hence, there is no practical way to implement Java SE independently.
Considering the dominant position of Oracle/Sun, we can't exclude the possibility that the European Commission will start a new anti-trust investigation against Oracle/Sun.
So Java platform lock-in can be a problem, I understand. But this seems to be totally orthogonal to the topic of from wich programming languages to which platforms you can compile. These different issues are somehow mixed in the article I think.
If you've reached this escape point, yes, you're wasting time by porting your application away from Java. But you knew Java is a closed platform owned by one company, and you took that risk.
There may be a legal structure to address that, but for anyone who depends on the good will of Sun, now Oracle, which probably includes IBM, it certainly wouldn't have been practical.
I'd love to hear his reasoning for disagreeing with RMS's ideal of user freedom.
On the other hand, the GPL imposes heavy restrictions on what a user can do with a software's source code in order to preserve other users' freedoms.
That's the fundamental split in permissive licenses vs copyleft licenses. It has been argued to death and the author probably (correctly) assumed that most readers are already familiar with it.