The Next Twenty Years of Java: Where We've Been and Where We're Going
blog.heroku.com
blog.heroku.com
Freeing Java with the GPL was an amazing move by Sun and kudos to everyone who made that happen. Without that action, there likely would not be another 20 years at this point.
I think the article is good and I concur that the JVM's future as a compilation target looks promising. Personally I'm very excited about the prospect of the JVM being a major platform for Perl 6... Perl has an amazing community and I look forward to an influx of true hackers into Javaland.
The specific implementation of the OpenJDK is available under the GPL, but the TCK, which is basically all of the test cases, is essentially proprietary.
Can you imagine Google writing Go, but keeping the Test cases for themselves? Well, they would let you use the test cases, but only if you used Go in way Google wanted you to. If you wanted to compile Go on the Raspberry Pi, or on anything 'like' a Phone, well that was off limits, and you could no longer use the test cases.
It's bizarre. It's evil.
The JVM is a great platform, but it is not "free".
But in reality the TCK is not part of the language, the virtual machine, or anything else that most hackers use. And we actually have a free JVM implementation that passes the TCK and always will as long as that is important, and I would argue that having 2 is much less important than having 1. And if its really that important... we could make our own TCK and force Oracle to become bug for bug compatible with us
I think much more relevant to being 'partially free' would be the example of Android... if they had released the whole platform as GPL the wouldn't be facing a billion dollar lawsuit that threatens the very possibility of building compatible APIs altogether... instead they chose to be as proprietary and control freakish as they could get away with while still pretending to be a community project... you can at least compile and run OpenJDK on almost any platform... while Android is notorious for being technically open source but in practice nearly impossible to run without proprietary components
What if a new set of compatibility tests were derived from OpenJDK's behavior and all major Java-invested vendors who wouldn't mind poking Larry in the eye (I suppose not too many people would find that objectionable), decided that new test set is the de-facto compatibility reference?
But due to recent legal rulings (and assuming they don't get overturned in the supreme court) Oracle has effectively locked Java back down. Even if it is GPL, Oracle has managed to copyright the APIs themselves, making the GPL-ness of the Java codebase more or less meaningless.
Sun did make Java free, no doubt about that, but under Oracle it is hard to argue that Java remains free. It is an Oracle product that Oracle owns, and if you try to fork it you will be sued (Oracle has made that point abundantly clear).
To be honest the GPL is now inadequate against this new type of copyright enforcement.
If you don't want to comply with the GPL and you still want to build an implementation of Java -- which is what Google did -- only then do you have to comply with Oracle's alternative licensing, which forces you to make your implementation fully compliant (Android isn't) and places further restrictions (such as the use on mobile devices).
In any case, whatever applies to Java applies to any other GPL project. As to Oracle suing you if you fork Java (and not abide by the GPL), let's just see what actually happened there: 1/ Google reimplemented Java not under GPL 2/ it did so while breaking compatibility, and 3/ to directly compete against what was then on of Java's main sources of income. So, yes, I think it's safe to say that if you make an incompatible implementation of Java to directly threaten Oracle's business, they will sue you. I have a feeling that other companies would do the same.
Maven and OSGi are wonderful, wonderful things.
I'm not even sure the above is technically correct. But even if it is:
1) it runs on most of those "89% of computers" as Java Applets, a technology noone cares about, not as a readily deployed Java runtime for the desktop.
2) Those 3 billion mobile phones either are Android, in which case they don't exactly run Java, or are insignificant featurephones with mobile Java that again nobody cares about.
3) Nobody cares about those "125 million TV devices" as platforms either.
No. Java is more pervasive than you think. It's widely used in SIM cards: http://en.wikipedia.org/wiki/Java_Card
You can't get away from it.
(Not to mention they'll probably get the boot soon, as they're an obsolete technology)
There would be some embedded software programmers employed, to write the set-top box or the phone OS, and that's it.
The same way that before phones had "app platforms" nobody cared what OS an Ericsson, or a Nokia or a Motorola phone run, and the number of people who worked on them was insignificant (basically employees of said companies).
What makes Linux important for millions of people is that it's used in servers, corporate and home desktops, phones, consoles, etc, that have active application platforms, it gives jobs to sys-admins, web apps, pages and services are written in it, etc.
It's not just that an "auto mechanic" doesn't care what OS runs on his set-top box, it's that unless that OS also provides a platform that lots of people work on nobody else does either (except of the "coders of propriterary embedded-ware" that wrote it and those competing for jobs with them in a quite small market).
A commenter lower down says it more succintly:
">who cares about sim cards? If SIM cards were to run on Fortran (for some strange reason), would you argue that Fortran is the wave of the future?.
>"The GSM Association, an organization of wireless telephone operators including AT&T Inc., plans to replace the removable SIM card connecting handsets to networks with a system integrated in the devices."
http://www.bloomberg.com/news/articles/2010-11-18/gsma-explo...
Apple then made a first move adding a "programmable SIM card" -- which is a first step towards software-only SIM:
>"Some of Apple’s latest iPads have a new type of SIM card that lets users switch easily between operators without replacing the card. This could seriously weaken the operators’ grip on their market, especially if Apple were to follow up by putting the new SIMs in iPhones or replacing them with software"
http://www.economist.com/news/business/21633870-moves-reinve...
>"As others have pointed out, as of right now the Apple SIM isn’t a huge threat to the existing smartphone sales model – contract subsidies are too attractive to customers. But ultimately, Apple is almost certainly hoping to replace the physical Apple SIM with a software solution built directly into devices; in fact, it was working on such a plan back in 2010, before that was axed by opposition from a coalition of European carriers in particular."
http://techcrunch.com/2014/10/16/apple-sim-details-and-poten...
"Java Card bytecode run by the Java Card Virtual Machine is a functional subset of Java 2 bytecode run by a standard Java Virtual Machine but with a different encoding to optimize for size"
It's a proprietary binary blob like the GSM-modem in your smartphone or the HTML5-DRM-module in your web browser. It probably falls under the category security by obscurity.
CDMA/locking the device to an account is basically a US only thing.
I replied to the statement that "in Africa they don't use Android phones", not that in Africa they don't use SIM cards.
It may or may not be as relevant as before, but one of the smartest things that WhatsApp did was to care about mobile Java.
I care about them as a security hazard. See "Java Primary Cause of 91 Percent of Attacks: Cisco" (2013) and similar.
http://www.eweek.com/security/java-primary-cause-of-91-perce...
If Fischer Price made "My first exploit" kits it would ship with java.
That's true, but it's also academic. Android's runtimes, Dalvik and ART, have very similar semantics to runtimes that use Java bytecode.
In the Android toolchain, Java source code gets compiled to Java bytecodes. This enables Java tooling to work with the Android toolchain. Then the Java bytecode is converted to Dalvik bytecode.
So, on the one hand you can say "There is no Java in Android devices." But very few Android APKs are created without Java in the code base.
The article disassociates itself from Java the language. Java was a better C++ in 1994. It has long since been eclipsed by both improved old languages that have evolved (e.g. C++11/C++14) and new languages (e.g. Go and Rust) that are unencumbered by the JVM. This is despite recent incremental efforts to renew Java the language.
Instead, the article tries to claim some success for Java by switching focus to the JVM. The JVM is still slow and - by its design (a clunky stack-based architecture) - simple to implement but very hard to run fast.
Java will still be around for a long time to come. It's the COBOL of our generation: it's better than what it replaced, but far away from what we are capable of.
That argument doesn't make any sense to me - by the time you are in your dynamic compiler, and you have an IR in something like sea of nodes, what difference does it make in what format the program was represented on disk? The stack part of it has long gone by then.
You can claim that the JVM runs faster than Dalvik though, because it has a better JIT that has had years more to improve.
But I don't know why JVM is being compared against Dalvik when ART is where Android is going in the long run, and has AOT compilation that beats Dalvik's JIT.
To say that Linux or C is stack-based is nonsensical, as it applies to an instruction set architecture. Virtually all hardware ISAs you're likely to encounter are register-based these days.
The virtual machine itself is a complete abstraction. Modern JVMs do not run a simulation of a stack machine at runtime (after compilation, that is).
The great stack vs. register-based debate is, in my mind, somewhat like the CISC vs. RISC debate—a fun water cooler conversation, but not too relevant in practice. All performance-focused language VMs lower into a (usually SSA-based) IR soon anyway, so the difference only ends up mattering for VMs that are deliberately kept simple for code size, simplicity, or legacy reasons (like Lua, or CPython).
What are you talking about? It's the fastest widely deployed VM out there...
But if you want to parallelize and distribute less CPU intensive tasks and have fault tolerance, then it's a good choice.
The JVM can generate faster numeric code than C++ in limited instances and when writing in C/C++ style. And then when you want to be faster than java you drop down to ASM and use a few SIMD instructions.
In the general case when you write real applications it's much slower. Not to mention that no one wants to drop 12 frames waiting for GC.
There are many other classes of applications outside games where a few milliseconds of garbage collection are acceptable. It is no surprise that many server applications are written in JVM languages - the 2x C/C++ performance is acceptable when people get a lot of instrumentation, more safety, etc.
I would say the primary reasons server apps are written in Java is the enterprise support and giant ecosystem as well as number of developers who can write java. The performance on the server is decent, and great compared to ruby/python.
People bring up video games because they are the most demanding apps most people run. Similarly you'll see apps like Photoshop, Office, etc written in C++.
Languages with a GC blah blah blah don't matter because no one writing C++ for performance uses a GC with it. I'm comparing C++ to Java for real world apps not language benchmarks, etc. C++ would not be my first choice for a web app because the task is trivially parallelizable and you get little improvement in string copying between C++ / Java / etc which is the primary thing web apps do, copy strings.
And LuaJIT faster than the JVM? Where you got that? You wont fine many benchmarks or people agreeing with you. LuaJIT is faster (much) than most scripting languages, but not faster than Java.
Are you comparing startup time?
Java is no longer slow. JVM languages in general are very, very fast. HotSpot is, frankly, incredible.
There are legitimate gripes to be had about Java as a language, but Java as an ecosystem and a runtime are incredible.
On the contrary, Golang programs run much faster, compile much faster, use much less memory.
If you're complaining about java programs that are slow or memory hogs you can only compare languages when you build the exact same application using different languages.
This seems a truism with respect to many "high value" software products/projects across the computing world. The ones that attract large investment.
The only time I ever use Java is when I use something made by someone else who uses Java. And when their software slows to a crawl or crashes, what can I do? It was not my decision to use Java. It is so pervasive, there's Java on a SIM card, what can a user do? Impossible to avoid.
But as for computers where I can open them up and install my choice of kernel and utilities, I have no need for Java. There is not a single file of Java anywhere in my source tree. I can find code written in terse languages that does everything I need to do with the computer. Code that out-performs Java, easily.
Maybe something written by a small team or even one person. :)
I think that is what makes the ITC field so entertaining. No matter how much cash and how many engineers a company can accumulate, a small team of dedicated people with little to no money, sometimes just one incredible mind sitting at a keyboard, can still create something that wins on performance. Is that not "success" of some sort?
As for Java, I guess it depends on how one defines success.
I like brevity, conciseness, performance and reliablity. Not sure I would label Java as a success under those criteria, but that is just my personal opinion as a user.
In terms of mindshare, Java is a tremendous success.
You mentioned Go. Rob Pikes' OSCON 2010 talk introducing Go had some criticisms of Java with examples. I think he said Java was a symbol of bureaucracy or something to that effect. Let us celebrate the success of bureaucracy. Congratulations Java.
Languages that are JVM versions of already existing languages were out long before JRuby (JVM' Ruby) and Clojure (JVM's Lisp). I remember Jython (JVM's Python) was first released around 1997, then called JPython. At that time there was also the Jacl language (JVM's TCL).
Beanshell's also an older language, which Groovy cloned and added closures (since made obsolete by Java 8's lambdas) and a meta-object protocol to. As for Scala, it's like a more statically-compiled and functional version of Groovy, about which Groovy's creator said he'd never have created Groovy if he'd known about Scala.
Groovy cloned and added closures (since made
obsolete by Java 8's lambdas)
Edit: "Real" is, I suppose, arguable. By that I meant: Java's lambdas don't support mutation of captured variables.
Then Haskell doesn't have closures either ;).
I think the definition of a closure is: a lambda abstraction / anonymous function that uses a free variable in its definition. So, Java's lambdas are real closures.
A variable has to be declared 'final' to be visible from a Java closure (anonymous inner class in pre-1.8 Java).
This means you can't mutate a primitive or an object reference, but it's possible to change the contents (instance variables) of an instantiated object captured by the closure. (And, indeed, this is exactly what you do in this situation).
I've never used Java 8 lambdas but that sounds the same as Java's inner classes which I'm now guessing lambdas are syntactic sugar for. I remember the common trick with inner classes to enable mutation was to declare and initialize a size 1 array of the required type instead of the type itself, and refer to, say, myvar[0] instead of myvar inside the class. I'm guessing this would then work with Java 8 lambdas also.
> Java's lambdas aren't real closures, though. Are Groovy's?
I last used Groovy at version 1.8 so don't remember for sure but think they did allow mutation. Groovy's closures also have the delegate lookup flag to enable dynamic scoping of names within closure code passed around and executed later, which I don't imagine lambdas have. Such a trick is done with macros in lisps like Clojure.
is that really a good idea?
function make_counter() {
var i = 0;
return (function() {
return i++;
});
}
var blah = make_counter();
Purity is pretty awesome. I really like conceptual Haskell (actual real Haskell tends to become too abstract for my brain to remember important details when I come back to a project...).
The (sad) fact is that mutating a bit of state is actually often much faster, or a lot cleaner to read / understand than implementing a fully pure functional version. And by limiting access to state, you make sure you don't accidentally introduce dependencies.
Using closures like this, can end up being very similar to object-oriented code (in the best-case, strictly limited sense) whereby each area of concern in the code can only modify what you expect it to be able to modify, and you can be sure nowhere else in the code can access it.
Otherwise I love that Java and GNU/Linux CRUSHED Microsoft in mobile.
http://www.gnu.org/philosophy/android-and-users-freedom.en.h...
At Sun JavaSoft in the '90s, we had IoT prototypes working well, such as distributed networking, home automation, automobile controllers, and wearable computing.
It's great to see these IoT concepts are coming to fruition.
But the plethora of interconnected devices that we have and envision today simply didn't exist at that time. If Java hadn't hung in there, we'd be talking about another, more recently created language designed for this purpose.
I remember that Oracle had a Java booth at the San Mateo Maker Faire 2014. I was at the Faire the entire 2 days and would pass the booth every so often in the convention center. I hardly saw anyone take any interest in the idea of Java on embedded devices, and the booth remained empty despite some good presentation with large signs and plenty of floor space.
Anecdotal? Maybe. But I think many device guys would cringe at the idea of something as bloated as Java running on a device. I've done my share of Java on server and Android at Google, and I certainly do. And by bloated, I mean things that come with Java-- large dependency trees, libraries, verbose code etc.
I think both NodeJS and Python are gaining more mindshare on the device-side: https://github.com/rwaldron/johnny-five
If you mean server-side, I would agree more. Java is certainly fast enough to run the data collection frontend. Kafka and Storm are great libraries that you can fit into a Lambda architecture for processing real-time data. And of course there are frameworks like Hadoop, Mahout, etc for the batch processing end.
Still, there's MQTT which isn't Java-centric, and IMO lacks an adequate message broker in Java. And Go is a another good option on the data collection side as well, and will probably get better.
No it has not, basically Sun did all the hard work on this areas.
If Google looses (lets hope not) the lawsuit vs Oracle, I hope they give Oracle what they deserve and switch to C#. Either way I am not using Java (I don't dislike it!) for anything outside of Android.
UI just is graphics painting using OpenGL ES.
Overall if Oracle doesn't screw it up, Java (at least the platform) does have a bright future.
If they can do that then I think both language and VM have a decent future ahead of them.
Java's challenge over the next few years is
going be how to make compatibility breaking
changes to the language and standard library
Case in point: 1. Not a single mention of its main competitor .NET. 2. Not a single mention that as Java becomes more and more closed source and proprietary, under Oracle's stewardship, .NET becomes more and more open source and community driven (in the true sense).
Today, 100% of them run C. Without C, there'd be nothing for Java to run on.
Running Java makes sense, since JavaByte is a "thing." Running C is just another way of saying they run native binary blobs which is meaningless and obvious.
All executable code is native "binary blobs" in the end. But they're written in language X. What I'm saying, is that 100% of those devices contain code written in C. C is also a "thing", it just happens to be usually compiled ahead of time.
[1]: Technically the term should be native/machine code or such. Assembly usually refers to text format assembler listing.
Edit: Wow, so many downvotes? Even though that 100% was just as meaningful as 3 billion. Ok...
1. stop distributing junk like Ask toolbar.
2. make Java automatic updates as easy as updating Chrome.
JVM is big adware nowadays and annoying to update for normal non tech people out there.