Glad to see that I'm not the only one who still likes the JVM after living through the good, the bad, and the ugly with it.
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.
Java was not free'ed by the GPL. Its a mirage. You've been deceived.
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".
That's a good point and you're justified in saying that it could have been better if the TCK was GPL'd too.
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
> the TCK, which is basically all of the test cases,
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?
> Freeing Java with the GPL was an amazing move by Sun and kudos to everyone who made that happen.
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.
I don't think you understand. That APIs are copyrightable means that the GPL applies even to the API. The GPL does not allow any further restrictions, and Oracle isn't imposing any. You may do with OpenJDK as you please as long as you comply with the GPL. You may re-implement the APIs, or use HotSpot's JIT to compile Brainfuck bytecode -- anything at all. That doesn't mean you can use the trademark Java for the result, but that's beside the point (and applies for all open-source projects).
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.
Isn't the issue that Google didn't fork it, but instead re-implemented it and the re-implementation had Oracle code in it? If Google had forked it and kept their version under the GPL they would have been fine.
IANAL, but it seems to me that Java 1.6 is GPLed and the implementation contains the interfaces. As long as they stick to JDK 1.6, which is good enough, they're fine.
I'm not sure if this is meant to be serious or not. I suppose if someone has no experience outside of the Java ecosystem (like many of the developers I've had to work with over the years), Maven and OSGi might appear to be 'good' things.
Your comment is sneering and dismissive without any substance. Why is Maven bad instead of good, and what experiences do you have that lead you to that opinion?
>Today, the JVM runs on an estimated 89% of computers, 3 billion mobile phones, and 125 million TV devices.
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.
> 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.
If Linux was only used inside phones or set-top boxes as embedded software, yes, it would be as insignificant as QNX.
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?.
It's been an ongoing research to get a new standard going:
>"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."
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"
>"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."
"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.
> 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.
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.
Security contests are the worst way to eval security. It might have something to do with the java prize only being $30K (cuz it's so fucking easy) instead of $75K.
If Fischer Price made "My first exploit" kits it would ship with java.
You don't always have that choice. There was a European country (I forget which one. Norway?) that was using applets for access to government services.
You can run Java selectively then, disable when not knowingly using it. Would provide a higher magnitude of security than just having it running while a rogue 0 day exploit hits advertisement servers or something similar.
Germany was it – until 2011 the only way to file taxes digitally was through a Java Applet called ELSTER. Now there is a beta version of a JS based solution.
> Those 3 billion mobile phones either are Android, in which case they don't exactly run 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 JVM has had billions of dollars of engineering effort poured into it. At the same time, it is still out-performed by low-budget small-team efforts (e.g. LuaJIT, Inferno).
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.
You say the JVM is hard to run fast because it has a stack-based architecture.
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.
His argument is hearsay. There's no conclusive evidence that a stack-based VM will always perform worse than a registered based one. There are tradeoffs between both designs. With all of the optimizations you see from register based VMs, you end up with larger instructions due to the lack of a stack pointer.
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.
wait til they hear that Linux has a stack-based architecture. that all C-based software has a stack based architecture. threads with stacks everywhere: surprisingly fast. it's usually things like higher-level architectural patterns and algorithm choices which make a MUCH bigger impact on latency and throughput, than whether you have stacks or not.
That's not what that means. In the context of bytecode, a stack-based architecture is one where instructions directly manipulate stack entries. For example, the Java bytecode instruction iadd takes the top two entries from the stack, adds them together, and pushes the result onto the stack. This is in contrast to a register architecture, where you might have an instruction of the form `add x, y, z`, which takes the values in two registers, adds them, and stores the result in another register.
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.
Java bytecode is instructions for a stack machine -- but that's an abstraction. Then the bytecode compiles down to (register) machine instructions, and that compiled implementation is highly efficient and highly optimized.
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 thread is talking more about stack versus register-based VMs than call stacks.
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).
It's always fun to see how different people throw around the seemingly-absolute terms "slow" and "fast" when there is always some other platform they're implicitly comparing to. I had a chuckle about this the other day as I was evaluating BEAM for potentially running a re-write of a Rails app; I was thinking how pleasant it was to use a platform so fast when I came across people ridiculing how slow Erlang is (presumably relative to C++ or even the JVM).
Those people don't get the point of Erlang. You'd have to be completely oblivious to complain about performance on the Erlang VM. The Erlang developers will always sacrifice performance and everything else in favor of reliability and response time. Consider that every actor has its own heap and GC. That's slightly absurd, honestly, but it makes sense when you think about Erlang's goals. I just get so frustrated when people say things like that.
Indeed, these claims always lack context of what is being attempted. If you are using Erlang to perform matrix multiplications on large datasets or some kind of CPU intensive work, you're probably barking up the wrong tree.
But if you want to parallelize and distribute less CPU intensive tasks and have fault tolerance, then it's a good choice.
Yes, that's why modern triple A titles are written on the JVM.
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.
Why does someone bring up game performance when the discussion is about JVM versus native code? Languages with a GC compiled to native code have the same problems, even C/ASM calls can be relatively expensive in languages compiled to native code (e.g. see Go).
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.
If you want to talk about "widely deployed VMs" then Dalvik is faster. If you want to talk about VMs in general then there are many that are faster, e.g. LuaJIT.
Actually no, Dalvik is slower than the JVM and with worse GC.
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.
All java software installed on my computer are still slow as shitting.
All my java projects need minutes to compile fully and to startup.
All my java programs uses hundreds Mb memory.
On the contrary, Golang programs run much faster, compile much faster, use much less memory.
Apples, Oranges. The Golang compiler is made for a language designed for speed of compilation. If you'd write a golang compiler in java (why you'd ever do that is not a relevant question here) then it would most likely be quite fast too.
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.
"The JVM has billions of dollars of engineering effort poured into it. At the same time, it is stil out-performed by low-budget small-team efforts (e.g., LuaJIT, Inferno)."
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.
> 2006-2010 [...] a new crop of JVM-based languages emerged. [...] JRuby was soon followed by Groovy, Scala, Clojure and many others. Each language introduced features that were unique and unavailable in 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.
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.
> Java's lambdas don't support mutation of captured variables
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).
> Java's lambdas don't support mutation of captured variables
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.
It's quite a cool trick for avoiding mutable global state, or clobbering the global namespace. It's used a lot in javascript projects.
function make_counter() {
var i = 0;
return (function() {
return i++;
});
}
var blah = make_counter();
every time you call `blah()` now, it will return the next number in the series, but there's no way for anywhere else in the application to modify `i`. This can be useful as an iterator, so giving you effectively the same as `yield`-ish generators in python.
I think the counter-argument is that all mutable state is bad, and the equivalent thing could be accomplished if invoking `blah` returned the next number in the series as well as a new closure that does the same thing.
Sure, everything as immutable does make certain guarantees about the code a lot easier. Also certain algorithms become very nice.
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.
One thing to note, GNU/Linux definitely did not crush Microsoft. Android/Linux maybe, but Android/Linux and GNU/Linux are pretty far apart. There is almost nothing GNU in Android. Honestly the whole "GNU/Linux" naming things makes a whole lot more sense in light of Android than it did when we Linux was basically only popular in conjunction with GNU based desktops & servers.
Java's best time may coming up because of the Internet of Things.
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.
Java was truly ahead of its time in that vision. Its promise was initially its portability, and it always had a network-friendly orientation.
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.
Actually, Java was originally developed as a programming language for smart appliances. Its roots are in IoT and embedded systems with limited resources.
Deployed on the server or to the device? If you are referring to device, I'm extremely doubtful.
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.
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.
>It has grown under Oracle -- both in openness and adoption.
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.
Its not possible to use only Go for Android application development. The goal of both the Go team and the Android team is to make Go a candidate for JNI development as an alternate to C/C++. The rest of the Android app, especially the UI can only be written in Java.
Java's challenge over the next few years is going be how to make compatibility breaking changes to the language and standard library without ending up in the same quagmire that Python did.
If they can do that then I think both language and VM have a decent future ahead of them.
Actually it doesn't. Have you tried making a mobile app with it? The experience is unacceptably slow and janky. React Native isn't officially released. That leaves us... with Java or Objective-C.
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).
"Run[s] C" doesn't actually make sense. C outputs assembly, so most of them run assembly. There are a lot of mobile platforms with no [obvious] C compiler, or certainly not trivial access to one.
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.
It makes as much sense as saying they run Java. Java bytecode is JITted into very same machine code. JVM outputs "assembly" [1] as well. The interpreters are also written in C or C++, even the partially hardware assisted ones, such as Jazelle.
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...
Well, C is usually the lowest common denominator language. Something that everything can run. Something you can truly run everywhere, although not necessarily as-is without some porting effort.
I'm just happy I could deinstall Java on my mothers PC because 98% (?) of LibreOffice functionality runs without Java, so no need to keep this hell of update software on a Windows machine.
The first thing Java and especially the main JVM maintainer for PCs (Oracle) should do is:
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.
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.