A Language Is More Than a Language
docs.google.com
docs.google.com
-- Guy Steele - Sun Microsystems Labs (about Java)
source: http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg040...
Meanwhile, I also had discovered that it was possible to use a GC enabled systems programming language for writing OS (Oberon and Modula-3). And was exposed to Prolog, Caml Light, Smalltalk and Eiffel.
So Java seemed a nice compromise for industry adoption. Our university adopted it right away for its distributed computing and compiler development classes.
However I never liked the religiosity about a JIT, preferring the .NET way of having a choice between JIT and AOT.
So I still like C++ a lot, but unless I am shaving off ms or bytes from a specific algorithm or writing portable code for mobile devices, I tend to use other languages.
I wonder how much of this comes down to the fact that Java methods are virtual by default and in C# they are not. The former makes devirtualization more important and is harder to do ahead of time.
But yes, a real Java 2 or Java++ or next generation Java would indeed be a good thing.
I though C# was considered pretty much Java with less warts.
I remember reading, for example, some horror stories from the early days of Fogcreek Fogbugz support on Unix via Mono.
Even today, is any big company using Mono? Are there are any big commercial (or Open Source) applications using it?
But you can take more time before releasing major components/features, and try to get them right. Eckel thinks they could have done better if they hadn't been in such a hurry, and focusing on marketting over quality, and maybe had some more skilled people involved. Especially in a platform so committed to backwards compat, if you release something designed poorly, you're stuck with it.
I guess the 'marketting' rejoinder would be if they had taken more time before releasing an attempted solution, it might have prevented Java's success in the 'market'.
I don't know. But I think it's general consensus at this point that eg J2EE API's and design was/is pretty awful -- and I don't think it actually takes retrospection to see that, it was awful right away and was seen so by many right away too.
I had a summer job working on EJBs at a company that had built everything on CORBA. It was basically a research project; they knew they had to switch to EJB, because it was going to be the standard (ha), and they wanted to know how. This was in the EJB 1.x era, so somewhere between 1998 and 2001 - i don't remember exactly when!
I remember thinking that it was all rather complicated, especially around persistence. And i remember being appalled that beans didn't actually implement their interfaces. We came up with some rather complicated pattern to work around that - i think there was a master interface where all the methods threw RemoteException, then the bean interface trivially extended that, and there was a local interface that extended it but overrode all the methods to not throw RemoteException, then the bean implemented that. And i spent most of my time there wrestling with the fact that the performance characteristics of local and remote calls are very different, and how that impacted design; we ended up with DTOs mirroring every entity bean to save network round-trips.
But the thing is, there was nothing else around at the time that did anything similar. Remote object invocation, with declarative transactions, and container-managed object lifecycles, including pulling objects out of a database on demand. That seemed like saucer tech! So it seemed, glaring design flaws aside, fair enough that it was complicated. Hey, i might have to write an XML document, but at least it wasn't ten thousand lines of C++.
So they criticise J2EE, but don't get it was actually a pleasure when compared to these technologies, specially when adding the C++ portability issues across OSes and compiler vendors.
It had lots of nice ideas, but it was a pain to use in reality.
Typical enterprise stuff.
There might have been nothing at the time _in mainstream languages/platforms_ (important distinction) that did something similar, but that doesn't mean they coudln't have done better if they had spent more time on it. I mean, even if there's nothing better to use as a model (debatable), is it acceptable to release something that requires complicated workarounds? (I guess that's debatable too; but we know what side Eckel comes down on!).
(Does anyone still want remote object invocation these days? I ask for real, I don't know. In my circles, it seems generally to have been found to be a mistaken thing to try. Based on experiences like yours in fact. So the other question is whether 'something similar' is even what was needed -- again, I think, a design question that takes time. Figuring out the right features of the right solution to actual problems is design.).
Going off mainstream, I read somewhere that Objective-C WebObjects framework was the inspiration to J2EE, given the Objective-C work going at Sun back then.
Then there was also Taligent, but it was short lived as well.
> Does anyone still want remote object invocation these days?
Apparently yes, now they call it REST and microservices.
As for remote invocation, i think it became clear quite a while ago that there's no point trying to pretend that remote objects are local. So, indeed, the original motivation behind EJB and CORBA has fallen away. The current version of EJB does still have remote invocation, and it appears people use it; i think it's used in much the same way as protobuf+HTTP/Thrift/Avro are, as an efficient coarse-grained intramural RPC mechanism.
I dunno, it is indeed just one example (and it's yours not mine, I don't have enough experience with this stuff to use my own, I've succesfully avoided it in my career) and it alone isn't enough to make the case, but it seems to me to be an example of Eckel's point. For something you're going to put in a stdlib and is going to be used by possibly millions of developers, you have a responsibility to design it right.
Eckel writes "collective losses of billions due to bad design" -- this is not an exageration. How many aggregate developer-hours spent fighting with this stuff, that could have been prevented by many many fewer developer-hours up front doing it right in the first place?
How many aggregate developer-hours would have been lost waiting for it to be perfect rather than just better than whatever else was available at the time? Especially since perfection is a target that keeps moving as we learn more about what works and doesn't.
But I'm sensing some historical farce coming, the isomorphic web starts to feel a lot like remote objects in javascript/protobuf clothings.
I don't know enough about the history of Java to say. But I know from my experience that good design takes time. And I agree with Eckel that a lot of historical Java API's aren't very good design.
Source: I am a Java dev and I simply old code a lot by introducing EJBs.
"Expert One-on-One J2EE Development without EJB Paperback – July 2, 2004"
http://www.amazon.com/Expert-One-One-Development-without/dp/...
Thanks
You mean the Google legal shenanigans that tried to find loopholes around two Java licenses (one of them completely open-source, and the other would have cost them $25M) that would hopefully hold up in a court case (which they were sure would follow, because they went straight after Sun's business), failed, and in the process forked the ecosystem?
Oracle did exactly what Google dared them to do (after a reprieve while Sun was dying). Only, to get what they wanted -- payment for the use of Java not under its open-source license -- they used whatever legal argument they could come up with, in the hope that one would stick. One did (well, at least partially), and now Oracle is at fault? This entire court case -- except the decision -- was orchestrated by Google. They could have avoided the whole thing by either abiding by the open-source license (which, BTW, is exactly the same as Linux's) or by paying Sun $25M. Oracle, OTOH, had no choice because Google went after them with their own weapon.
Oracle didn't just go after someone who'd forked Java. They went after someone who'd forked Java with the intent to harm on of their main income sources from Java (at least at the time), while forking the ecosystem and breaking compatibility -- the ecosystem's prime directive -- and all that while Java was available under an open-source license, which Google rejected. They don't care about the principles of copyright. They just happened to use that in their arsenal of legal tools to go after a company that they believed had harmed them.
Then, Google's PR tried to terrify the world with the possible repercussions of the one argument that did stick by blowing it out of proportion and neglecting to mention that it hardly applies to any software these days.
Neither of these companies is a saint in this story. They are just two corporations playing their parts. But Google was the one who could have stopped all this, and blaming the whole thing on Oracle is just ridiculous.
Of course, that's not true, and you know it's not true, since you replied earlier this year to someone who explained that the alleged offer was $20M + 10% of Android's revenue (capped at $25M) for a three year license - and this was in 2006, years before Android had even launched. FSM knows what Oracle would have demanded after Android was a proven success and Google had caved earlier.
Of course, one may still think Google should have paid whatever Sun/Oracle asked for, but let's not spread misinformation.
-- James Gosling, http://nighthacks.com/roller/jag/entry/my_attitude_on_oracle...
If you check his blog he has another posts about the whole issue.
So, what do you think the SSO of 37 Java API's are worth?
Also, since all Oracle has left is the SSO claim of 37 Java API's, what do you think that's worth? And do you really support the copyright of API SSO?
WRONG! OpenJDK is 100% open source with absolutely no restrictions whatsoever[1]. Restrictions apply to other Java licensing methods, some of them may also be free as in beer but not as in speech.
> And do you really support the copyright of API SSO?
I think there are valid arguments either way (e.g., a book's TOC is copyrighted), but the use of an API for implementing a compatible version should be allowed regardless of the copyrightability issue.
But whatever your opinion is, blaming Oracle for this is hypocritical. Their goal wasn't to copyright their APIs. Their goal was to get Google to pay for Android, and they used whatever tool they could think of in their legal arsenal. Any other company would have done the same. And keep in mind -- they didn't do it on principle. Google directly attacked one of their major revenue streams -- licensing (under a non-GPL license) of Java for mobile devices. What Google did was highly unusual. I'm unaware of any such event in the past two decades or maybe even ever. It was Google who provoked Sun to sue them, and now they're trying to gain sympathy by crying over the weapon that happened to hit. But they knew Sun (or Oracle) would come after them, they started this, and now they want people to blame Oracle for any collateral damage.
The collateral damage, BTW, is quite small (although Google is also trying to inflate that to gain sympathy). The copyrightability ruling applies only to "classical" software APIs; not protocols; not REST APIs etc.. There is no way, no how, to interpret the ruling to apply to anything other than this kind of API (copyright cannot apply to anything that isn't fixed). Implementation of an API by software that does not comply with the API's license is rare. In addition, implementation of an API for the purpose of providing a compatible, competing product may still be fair use. But that, too, is not what Google did. Android does not comply with not a single one of Java's editions, so it was certainly not Google's intention to create a competing implementation that would allow Java programs to run unchanged.
Android is the reason Java is the #1 programming language. I hope Google transitions to another language and leaves Java in the dust. Google is responsible for making Java relevant in the consumer space and Google is also going to be responsible for making it irrelevant thanks to Oracle.
Or Google could have complied with the open-source license, as they did with Linux. But there was no way Google was ever going to let that happen.
> Android is the reason Java is the #1 programming language
Android hardly accounts for a few percentage points.
How exactly did Google not comply? Are you suggesting that if Google released the Android bits under the GPL license and not the Apache they would be been compliant and Oracle would have not sued? I highly doubt that.
>Android hardly accounts for a few percentage points.
Java would be in a constant annual decline had it not been for Google and Android. Just as Objective-C has sunk dramatically in the TIOBE index we'll see the same result when Google switches to Go, Dart or perhaps even Python.
Of course! OpenJDK is licensed to the entire world under the GPL, and anyone is explicitly permitted to do whatever the hell they please with it.
OpenJDK is probably the world's second-largest open-source project (after the Linux kernel), and possibly the world's most active. OTOH, with the rare exceptions of Android (that has significant parts forked from Apache Harmony) and Go, Google has made scant contributions to open-source in general. Netflix, Yahoo, LinkedIn, Twitter and Facebook are all much bigger open-source contributors than Google. True, Oracle is not a big fan of the ton of open-sourceness it inherited from Sun, and has even made the terrible decision to stop contributing to OpenSolaris, but painting Google as a champion of the developer community and a defender of OSS is ridiculous. I have no love for Oracle, and even less love for Google, but in this story Oracle weren't the bad guys.
> Java would be in a constant annual decline had it not been for Google and Android.
That is completely unfounded. Even within Google (one of the world's biggest Java shops), Android is not one of the biggest Java codebases. Objective-C is a client-side language. Java is first and foremost used on the server. Client-side Java (including Android, which isn't really Java) is a very small part of the Java ecosystem.
Hardly. Java has been #1 nearly a whole decade before Android even appeared.
Java has been #1 from at least 2002 (and even before, long before Android) until now according to TIOBE -- the fact that it had a dip to #2 in 2014 doesn't change anything substancial to what I said, which was: "Java has been #1 nearly a whole decade before Android even appeared."
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
No, I wrote (quote) "nearly a whole decade before Android was released".
Besides, you couldn't have missed the point more.
First the whole thing in discussion is whether Java became #1 due to Android or not (and it hasn't: it was #1 way before Android, and kept it until now for over a decade).
Second, TIOBE is indicative, not absolute. A language that's #1 with 25% in early 2014 doesn't suddenly drop 5-10 points to go below another for a few months -- that's just a momentary trend in searches or repos and other things that TIOBE looks at, not some indication that millions abandonded Java and adopted C for six months and then came back.
Then you will like Java.
Full disclosure: I grew up in SF and didn't really believe in seasons until that year I spent in CO, so take this comment with a grain of salt or better yet a big bag of that road salt they use to melt the ice on the roads, and a four-wheel drive vehicle with working heater, and winter underwear and a warm preferably-goose-down jacket and boots and "smart wool" socks, and hat and mittens. Seriously though, unless you like to ski or you're just really into ice and being cold and you can't get to Antarctica going to Crested Butte in winter is nuts. Nice town. Freezing cold.