Java on the desktop and mobile never went anywhere. There is a perfectly good reason for that - show me a UI designed by Sun that doesn't make me puke.
If you were to take a good, portable language which a ton of developers are already familiar with and make it successful on the mobile - you are not going to go with Sun, JCP or any other "community" designed models.
So Google's problem was that they liked the Java language and they had to attract developers so they had to adopt the API but they had to throw away the rest of Java - including the JVM, Swing and ton of other useless-for-mobile APIs none of which were really a viable option on mobile.
So you could argue that Google could have been a good citizen, good Sun friend etc. but if they had to take J2ME and/or JCP for that, it would clearly defeat the purpose of Google entering the mobile market.
And I don't understand what McNealy's quote about "they [Google] don't share" is all about - it's open source, Oracle can adopt Android UI APIs or whatever else they wanted. If this is about money - yeah may be Google should have thrown them some bucks but I guess it had to be done under "licensing" which again would have meant dealing with Sun's "Community Process", "Standardization" and other bloat all of which were directly responsible for J2ME not going anywhere in the first place.
Another issue is that Gosling seems to be FUD mongering with Compatibility stick - "we've got organizations of people that do compatibility testing and actual negotiating amongst the different handset makers so that things like GPS APIs look the same." Android has standardized GPS API since I don't know when and that doesn't seem to have been a problem with any of the dozen Android devices I've used. The only difference is Google puts out those APIs and it works with manufacturers to amend / add as required. Google has the final say over APIs which is a good thing - you don't want hardware vendors designing software APIs that work cross device - that is best left to people who know that sort of thing. And not having a sanctioned committee with varying interests wrangling each other and slowing down progress has also worked out well for Google and Android.
Many of the quotes in the article suggest that the Sun people really thought that there current system was a credible solution for the mobile space. Anyone who has ever used Java on mobile is going to have a hard time swallowing that one.
If their argument boils down to "well, they should have agreed to make their system just as shitty as the rest of our systems so that they could be crappily compatible" then it's not hard to see why Google went a different direction.
But with his closing argument, Google counsel Robert Van Nest insisted that the search giant was well within its rights in building its own version of Java, claiming “fair use” of Oracle’s copyrights.
Google's defense is incredibly weak. relying mostly on fair use.
the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright.
> There is one thing the jury won't know: the issue of whether APIs can be copyrighted at all is actually up in the air. It's a legal gray area that will be decided by Judge William Alsup—but only after the jury gives its verdict in this case. (When that happens, even a jury verdict in Oracle's favor could be a hollow one.)
That is awful. Honestly, the idea of APIs, and not their implementation, being copyrighted makes no sense to me, since it goes against the fundamental principle behind copyright law (versus patent law).
If a juror genuinely believes that the idea of copyrighting APIs and extending that copyright to alternate implementations makes no sense, how can they come up with a decision that's anything but arbitrary? That's like me saying, 'Assume that 1 * 5 = 0, and then decide if if the satisfiability problem can be solved in linear time'.
If you give me a nonsensical set of assumptions, how can I come up with an answer that's not also nonsensical? If you give me some messed up numerical system like that one, well sure, maybe those definitions would propagate though to the definition of polynomial complexity as well. But what does that mean for the real world? Nothing - and law is meant to be applied, not some abstract theoretical exercise.
Except that you can't copyright a language specification - just the implementation of it. And even if you could, copyright law wouldn't prevent you from re-implementing it!
I mean, look at it this way - GNU is almost completely compatible with Unix, but it was rebuilt from the ground up. Even if AT&T hadn't given out the license for free, you'd have a hard time convincing me that GNU breaks some sort of copyright - the entire damn codebase was rewritten from the ground up. The design of the operating system may be the same, but copyrighting that is as ridiculous as patenting a geometric shape.
The failure of J2ME has nothing to do with your particular preference for non-Java UIs. J2ME was a creature of the early 2000s. JSR-88 ( the J2ME spec ) was a done deal by early 2003. Implementations & maintenance releases rolled out over 2003-2007.
In contrast, Android 1.0 was released in Sep 2008. All of the success stories of Android, the apps & suchlike, are the post-2010 timeframe. Notwithstanding the experience of hindsight, you had a decade between J2ME & Android, which is like a light year in tech timeframe. Nobody could imagine billions of consumers buying mobile apps in app stores back in 2000. Today that's a reality. To attribute change in customer behavior solely to Android being better than J2ME is quite bizarre. Today, Android is an order of magnitude better than J2ME. But when it debuted, J2ME was infinitely better than anything out there because there was practically nothing else. The remarkable Android UI experience is due to => Scott Chase and Romain Guy => The same Swing gurus who wrote the crappy Java Swing UIs that made you puke :)
There's a time to everything, a time to tear down and a time to build - Ecclesiastes.
There is no such a person as "Scott Chase". Maybe you mean "Chet Haase". Chet joined the Android team in May 2010, way, way after Android became the success it is today.
Having said that, you are quite right to credit Romain for a lot of the UI we see in Android, and there's also a reason why he didn't stay at Sun: he was one of the few graphic engineers who actually cared about releasing good graphical user interfaces.
You are right about the timing and it not just being a UI design issue and I certainly didn't mean otherwise. But could you build J2ME apps that were elegant and WORA without pain? Android mostly makes that a piece of cake. Do you think J2ME kept up with times in the post iPhone era? Do you think if it wasn't for Android, under Sun/Oracle J2ME would have been competent in 2012? Fact remains that J2ME was mostly a failure and even with the hardware and UI advances it hasn't improved. There are reasons for that.
Failure of J2ME had to do with the flawed process, the technology, the design, the backwardness, the inability to keep up with times, the failure of the WORA promise, the fragmentation and Sun's management lacking any and all vision. Licensing from Sun would have likely meant Google would have found itself in a déjà vu situation. That was the point I was trying to make :)
It was, but it was next to impossible to get a half decent application released on any J2ME phone not to mention the impossible fragmentation (compare to the J2ME beast the Android fragmentation is a sweet tamed puppy).
Java is also installed on a bazillion desktops, numbers don't change the fact that the ui framework is very bad.
Historically applets lost to flash for that same reason
Wasn't is stuck on Java (the language 1.1)? Any Java developers who came in at 1.2, 1.3 or 1.4 would have had to re/un-learn how to do certain things they took for granted.
>Mobile: wasn't Java ME on a bazillion feature phones?
Yep, because there wasn't anything else. But it was painful, slow in terms of progress and incomplete (JSR297 - they are still working on 3D graphics API standardization). And hey no one liked it and knew it far as I can tell - talk real fragmentation.
It may have been on them in some sense, but it certainly didn't have much of an impact there. People didn't write apps for those phones in any numbers.
The world wouldn't look very different today if those phones had run a completely different stack. Or even if it wasn't possible to write apps for them at all.
There are ample UI differences between iOS and Android. The similarities end at both being touch interfaces.
Besides, writing J2ME swing style apps was what made a developer puke although the end result of it, the UI was also painful to look at if not as much.
IMHO, an important reason J2ME failed is that handset hardware at the time was so anemic: small screens, slow processors, very little memory, and short battery life.
Java is Gosling's baby. How is he supposed to feel about this? Google threw his work out the window and shipped stuff called "Dalvik" and "Harmony" that did the same thing, never crediting him or using the term "Java". And their stuff was wildly successful.
That's gotta hurt. The harder question is whether or not the "blame" for that lies with Google or Sun, or whether or not it's really useful (in contexts other than Gosling's private emotional space) to assign blame at all.
Edit: lots of responses are diving into the stuff I allude to in my second paragraph. I don't see how that's relevant to Gosling's reaction. My point was that the guy got stung, and that he's lashing out in an entirely understandable way. It's not about the law suit, it's about him.
If Google used "Java" to describe Android, Sun would sue them, like they sued Microsoft. "Java" is a trademark and the only way to use it is to pay Sun (well, Oracle now) a lot of money for the compatibility suite.
I don't see how either Harmony or Dalvik should affect Gosling's feelings one way or another. He had no hand in either so deserve no credit. To the extent that Harmony re-implements Java, no-one is trying to deny Gosling credit for creating Java in that context.
The decisions that Google made were either technical (Dalvik is designed with mobile usage in mind while a standard jvm isn't) or contractual (Sun wants control over Java, Google wants control over Android, neither wanted to fold and things are just fine that way: Android is successful in its domain and Java is successful in its domain).
Note that IBM dumped Harmony in favor of OpenJDK last year after realizing Harmony will never get a TCK license from Sun/Oracle. The Apache Foundation resigned from the JCP Executive Committee in protest shortly after that and last year an open vote was taken within the Project Management Committee, which resulted in a 20-2 majority to discontinue development."
Here's what the Apache Foundation had to say:
when the Apache Foundation resigned from the JCP Executive Committee in protest, it actually stated on the organization's official blog that the "Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses."
I'm fairly certain that Apache was referring to the TCK license when they were talking about Java specifications. They don't use the word API - probably because the idea of copyrighting an API wasn't considered possible (and hopefully still isn't).
Apache wanted to be able to call Harmony "Java", everyone already knew that it was API compatible.
Yep, it's pretty interesting in light of Goslings previous comments on software patents and Sun's inability to make money or make good on its open source promises.
I feel for the guy, but if he didn't want to be slimed, they should have made the TCK available under an actual open source compatible license. If Google slimed Sun, what did Sun do to Harmony?
If the primary goal was compatibility, they should have worked with Apache on that. The license fees wouldn't have been a problem. If, on the other hand, the primary goal was controlling the single open source version of Java, you're going to have to expect non-"Java" open source forks.
I'm not sure what Google "sliming" Sun has to do with the copyright or the patent case, though. Is he suggesting that he agrees that APIs are copyrightable? (you wouldn't even need a TCK in that world)
You forgot to mention the years that Sun strung Harmony along (since JCP decisions at the start of OpenJDK development in 2006!), a behavior that Oracle came out vocally and publicly against until they acquired Sun.
> yes, licensed under GPL not ASL.
I feel like you don't really read the posts you respond to. That kind of thinking was exactly the impetus for the non-"Java" forking I was referring to. Hypothetical: someone forks OpenJDK and makes incompatible changes to the APIs. They have no interest in passing the TCK or following the restrictions in the OpenJDK Community TCK License Agreement. Are they able to release this as long as they don't call it Java? More concretely, should GNU Classpath be shut down?
Precedent up to this point says that that both are fine and have to be tolerated. Jonathan Schwartz said both bothered them but had to be tolerated, but you've made clear that his opinion couldn't possibly be relevant. We'll just have to see how this case turns out.
>Jonathan Schwartz said both bothered them but had to be tolerated, but you've made clear that his opinion couldn't possibly be relevant. We'll just have to see how this case turns out.
His "endorsement" is not a license or a permission to break copyright/license agreements.
He said many things that were pro-Android. Endorsements, explanation, etc. it doesn't matter. What he said was not a license.
What questions? anyone can fork OpenJDK and release it under a different license due to the classpath exceptions, and if they pass the TCK they can call their software Java. If not they cant't. but PhoneME doesn't have the classpath exception and that's why Google didn't like that.
Here's Andy Rubin's email:
"We are building a platform where the entire purpose is to let people differentiate on top of it," said Android chief Andy Rubin in an August 11, 2007, e-mail that Oracle is touting in its case against Google (PDF). "Sun chose GPL for this exact reason so that companies would need to come back to them and take a direct license and pay royalties."
Quotes out of context might work on juries where anyone with technical experience has been excused, but he's clearly talking about their GPL code (which they went to great lengths to not use) because no-one in the industry thinks API's are copyrightable or should be. If they did they'd have worked around it like they did the GPL code.
Even with the TCK license, I think the major problem was licensing of the JVM.
Google wanted to make Android open source, but the JVM license requires the GPL, which Google and a lot of companies using it now won’t touch with a pole.
So they had to use more liberal license, like the one they use in most of their other projects and the only way to do that was to write their own new VM (this probably also allowed them to more easily tailor it for mobile use).
I don't think a GPL'd JVM would be a deal-breaker. It's at about the same level as Linux, probably less likely to be tweaked by device builders. Not having the classpath exception on the libraries would be a no go though.
"Just because Sun didn't have patent suits in our genetic code doesn't mean we didn't feel wronged. While I have differences with Oracle, in this case they are in the right. Google totally slimed Sun. We were all really disturbed, even Jonathan: he just decided to put on a happy face and tried to turn lemons into lemonade. which annoyed a lot of folks at Sun."
In a March 8, 2007 e-mail to Schwartz about working with Google on licensing or partnering with Sun on Java, Sun's co-founder and chairman, Scott McNealy, characterized the relationship with Google at the time: "The Google thing is really a pain. They are immune to copyright laws, good citizenship, they dont share. They dont even call back."
If Sun didn't want to risk ever feeling this way, they shouldn't have made Java open in the way they did. They purposely made Java so that this kind of thing could happen, and then felt wronged when it actually did.
I think he was talking about forks. As you see, when Sun opened it's language, people said at Sun said some interesting stuff:
"But I think there’ll be lots of forks, and I approve. I suspect that basement hackers and university CompSci departments and other unexpected parties will take the Java source, hack groovy improvements into it, compile it, and want to give it to the world. They’ll discover that getting their creation blessed as “Java” requires running the TCK/trademark gauntlet, which isn’t groovy at all. So they’ll think of a clever name for it and publish anyhow."
From what I understand, whatever license Java is released under allows for the possibility of another party creating a clean room implementation of the language and releasing it on their own, outside of any control, influence, or fees due to Sun.
From the developer documentation at Google's android.com:
> The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
> All applications are written using the Java programming language.
> Android applications are written in the Java programming language
Based on a sampling of random pages there, they talk about your Java classes for you application, your Java source files, and so on. It's mentioned dozens if not hundreds of times.
You can reference it anywhere but you can't ship your product calling it Java. In this case Google references Java's classes, SDK etc but they call the version they ship as Android.
That's kinda the crux of the lawsuit... can you copyright a language? Google's argument is that the specifications of the language and core APIs should be considered separate from the implementation. One is "Java" the language, the other is "Java" the platform. Google uses the Java language on the Dalvik/Android platform.
Perhaps the key point here is that there are not 'white knights' or people without stain in this particular fight.
As someone who was there I can tell you the fact is that Sun was going to flush Java down the toilet at the end of Fiscal Year 1995 (June 30th), they had no idea how to monetize it. And when SGI and Microsoft paniced when it got out, well it became a bludgeoning club which they used to bludgeon people they didn't like. And all of the efforts to make it a language for lots of purposes like C or C++ (when is the last time someone got sued by AT&T for making a C compiler?) got tossed into the bucket in the name of bludgeoning.
Bill Joy asserted for a while that the JVM would execute byte code (with the assistance of HotSpot and some other bit of secret sauce that never actually happened) faster than compiled native code. Later when gcj was released (Java to native machine code compiler) that code ran faster than hot spotted code, and it loaded quicker too.)
Google on the other hand knew it was leveraging something it had the code to (and like a third of the original team) and yet it often takes a very literal interpretation on license requirements when that interpretation suits them. An example of that was the lack of any requirement to put any of their changes to Linux back into the repo because they didn't "ship" Linux, they just used it in house. Now a number of engineers were very annoyed at maintaining things that they didn't want to maintain and that forced things to be pushed upstream but that was commit by pain, not commit by intent.
So I really resonate with the comment James made that there isn't anyone with clean hands in this fight. But there are a lot of egos out there.
Google on the other hand knew it was leveraging something it had the code to (and like a third of the original team) and yet it often takes a very literal interpretation on license requirements when that interpretation suits them.
They had the code but they didn't use it, so the license doesn't apply to them. It's not an interpretation of the license at all.
An example of that was the lack of any requirement to put any of their changes to Linux back into the repo because they didn't "ship" Linux, they just used it in house.
That's not their interpretation, that's the FSF's interpretation. The GPL does not, and has never required anyone to "contribute back". Its whole purpose was always to "pay forward" by giving your users the same rights you got. If you're your only user, you don't have to share the code to anyone.
Straight from the horse's mouth in the GPLv2 FAQ:
Does the GPL require that source code of modified versions be posted to the public?
The GPL does not require you to release your modified version. You are free
to make modifications and use them privately, without ever releasing them.
This applies to organizations (including companies), too; an organization can
make a modified version and use it internally without ever releasing it
outside the organization.
>The GPL does not, and has never required anyone to "contribute back". Its whole purpose was always to "pay forward" by giving your users the same rights you got. If you're your only user, you don't have to share the code to anyone.
Oh come on, that's clearly against the spirit of the license. The central point that the FSF makes is that all software should be open (as in, the source code should be freely available). Paying forward the rights that you got (to view and modify the source code) means allowing others to view and modify the source code.
I disagree. Their point is that the user should always be able to share, modify and run the software they have, not that they should have access to every line of code written. Again, from the GNU project:
In general we do not believe it is wrong to develop a program and not release
it. There are occasions when a program is so useful that withholding it from
release is treating humanity badly. However, most programs are not that important,
so not releasing them is not particularly harmful. Thus, there is no conflict
between the development of private or custom software and the principles of the
free software movement.
Nearly all employment for programmers is in development of custom software;
therefore most programming jobs are, or could be, done in a way compatible
with the free software movement.
I doubt their modifications to the kernel (remember we're not talking about userspace stuff here) are "so useful that not releasing them is treating humanity badly".
using what was considered Sun's open, but in some ways restricted, code in a way that would offer little benefit to struggling company that had invested tens of millions of dollars developing Java and its community over more than a decade.
Only speaking for myself, but I wouldn't touch java if it wasn't the language for android development. I'm hard pressed to believe the attention and new developer interest android is bringing to java will hurt the language.
Especially on the mobile side, where it was already dying at the time. However java was extremely popular on server side and desktops for enterprise projects.
Only speaking for myself, but I wouldn't touch java if it wasn't the language for android development.
As an Android developer and, I have to confess, advocate, I have always found Android's Java origins to have been a mistake. It is an unlikable language that did nothing to further the platform, but brought a lot of resource expense with it. I honestly wish Oracle wins this suit and Google gets a sunsetting period to actually bake out a credible NDK API (e.g. no JInvoke BS).
"And what's going on in the Android world is there's kind of no adult in charge.
And all these handset manufacturers are doing whatever they damn well please.
Which means that it's just going to be randomness. It could be let a
thousand flowers bloom, but it also could be a dog's breakfast."
Isn't that like many startups all competing in the same market; may the best variant win (and that's good?)? Of course, there's bias from the iPhone's success.
Having a number of different operating systems that claim to be "Android" but are actually incompatible with each other is a huge problem. Users expect the different handsets to have the same functionality, and developers don't want to (and cannot) write infinite variations of their applications to work on the different phones. Fragmentation doesn't lead to one handset maker's version of android winning over another, it leads to android losing overall, as the costs of android development increases and the quality of the user experience decreases. Feels like the browser wars a bit.
That would be an argument if it weren't for the fact that J2ME was a complete failure in compatibility and Android is, in fact, the best example of write-once-run-everywhere that Java has ever seen.
Yeah, it makes life more difficult for developers. Just like the variety of linux distributions. And yet I don't hear anyone here whining about how we need to all standardize on Oracle Linux.
You don't hear that whining much anymore because of a few reasons.
1) many people who valued standardization of experience moved to other platforms
2) on desktop systems, you can fairly straightforwardly (though not always easily) compile from sources to get an executable binary compatible with you hardware. With mobile/tablets, that's rarely the case (i'd say never, but I don't know about edge case devices out there which may support/encourage it).
I think it's more accurate to say that the linux community engineered around it. Think about the package distribution systems that have evolved: apt, yum, slackpkg, etc. Installing software on a linux distro is WAY easier than than installing software on my Mac. Compare running aptitude install MySQL to going to the MySQL website, downloading a dmg, and running an installer.
This kind of package management would never have evolved under the One True Dogma of Sun or Oracle. Windows still doesn't have it. Apple has finally put an App Store on OSX, but of course with their usual dictatorial flair.
Java is a dying community. This is 100% Sun's fault. The only flourishing parts of the Java ecosystem (Android and App Engine) are flourishing because they dared to speak heresy.
If the price of iPhones and android based phones were equivalent, then yes, android phones lose overall to iPhones.
However, anecdotally and from personal observation (small data size), those who cannot afford iPhones tend to go with androids due to price and availability than go with older generation iPhones.
Do Users really expect Different handsets to have the Same functionality? Or is slightly different ok, since they are slightly different handsets?
Sun has not made anything of user interface value over the last five years because of legal bullshit. Android fixes this problem. The reason Android exists is the massive NIH ego of Sun engineers, the total ignorance of Sun management and the fact that AWT/Swing is a desktop API that ignores mobile phones and tablets. Sun ignored video, audio, animation, maps, vector graphics, DPI/PPI differences, multitouch, GPS, sensors and memory consumtion. The AWT/Swing alternative called JavaFX ignores all the problems that Android solves. I respect Mr Goslings work, but AWT/Swing/JavaFX has nothing on Android and is unable to compete with WebOS or Bada from many years ago. Sun Java WebStart was such a bad product it infected more computers with malware than Adobe Flash over several years.
Java itself is a good product. J2EE works everywhere if you rip out AWT/Swing/JavaFX references. If you do use the UI code your app will probably blow up every couple of years because Sun hired a new developer or Apple is working fulltime on iOS Cocoa. Android is weird, but there is no other Java-like alternative except Windows Phone 7.
Gosling said that Sun was "wronged" by Google and that Oracle is right to sue Google for the way it used Java code in Android.
Just because Sun didn't have patent suits in our genetic code doesn't mean we didn't feel wronged. While I have differences with Oracle, in this case they are in the right. Google totally slimed Sun. We were all really disturbed, even Jonathan: he just decided to put on a happy face and tried to turn lemons into lemonade.
In a March 8, 2007 e-mail to Schwartz about working with Google on licensing or partnering with Sun on Java, Sun's co-founder and chairman, Scott McNealy, characterized the relationship with Google at the time: "The Google thing is really a pain. They are immune to copyright laws, good citizenship, they dont share. They dont even call back."
"It's really hard to tell what their intentions are with Android. They put this thing out there, and you've got lots of people picking it up. The big attraction seems to be the zero on the price tag. But everybody I've talked to who is building an Android phone or whatever, they're all going in and they're just hacking on it. And so all these Android phones are going to be incompatible.
"One of the reasons that we charge license fees is because we've got organizations of people that do compatibility testing and actual negotiating amongst the different handset makers so that things like GPS APIs look the same. And what's going on in the Android world is there's kind of no adult in charge. And all these handset manufacturers are doing whatever they damn well please. Which means that it's just going to be randomness. It could be let a thousand flowers bloom, but it also could be a dog's breakfast. And I guess having been around the track a few times, it feels like it's going to be more of a dog's breakfast."
Putting aside the IP issue, this sounds like a textbook example of worse-is-better[1]. Sun spent years trying to corral mobile vendors through a single standards process to ensure the "correct" result while Google shipped and iterated on something just good enough. Android may be a "dog's breakfast", but it's a couple of orders of magnitude more successful than Sun's Java-on-mobile efforts ever were.
Apple's mobile success might seem like a counter example with the iPhone as a "better-is-better" perfectly polished jewel, but when you look beneath the surface, the iOS implementation is filled with compromises and hacky tricks[2]. The magic comes from always compromising in favor of what really matters (simplicity, responsiveness), rather than refusing to compromise at all.
[2] I'm particularly fond of the way it maintains a recently rendered version of your application's interface to show you for the fraction of a second it takes to activate the app and bring it back to the foreground. It's only marginally more useful than a black screen, but works wonders for the perception of responsiveness.
Reminds me why Java has the reputation for being over-engineered. Google actually shipped a version of Java that was sane to code with, and Sun is just jealous they didn't come up with it first. Android is the first time I could actually say that I enjoyed coding in Java. Couldn't say the same with Sun's complicated over-engineered stuff.
I've watched Gosling's various comments about Android over the years, and it really does sound like a case of sour grapes: Google saw success where Gosling's creation saw overwhelming failure (it is simply incredible for Gosling to actually denigrate Android -- which by and large is incredibly common across thousands of devices -- with the disaster that was J2ME).
I don't know why you have to drag iOS into this discussion, but it's a known fact that there are way more compromises and "hacky tricks" in Android than iOS.
Interesting. I can't comment on the relative volume of hacks in iOS vs. Android. Presumably both have quite a few.
My point was that "worse-is-better" was validated by the success of Android vs. Sun's own mobile efforts as characterized by Sun's executives here. And that despite appearances, the other major successful mobile platform is an application of worse-is-better as well.
I'm surprised the smart guys at Sun—who were themselves beneficiaries of worse-is-better in the Unix workstation market—built their mobile strategy around designing the "one true API". I suppose the (somewhat accidental?) success of Java convinced them it was a viable approach.
I think it's important to think about what Google's goals for Android were, and ask whether those were in conflict with getting a Java license. In the trial I read that Sun wanted a lot of "control" over Java on Android with a license. Can anyone explain what that means exactly? Google's goal with Android, in part, is to provide an open and completely free mobile OS. Would that goal have been affected by the kind of control Sun wanted? Would we still have things like Cyanogenmod? Would progress on the OS in general be slowed? (I honestly don't know so I'm hoping someone can fill me in.)
I find two things really irritating about James Gosling as quoted in this article (there are many more, but none relevant to the article):
1. His use of the phrase "genetic code." He's trying to sound more intelligent than the MBA stereotype by using that phrase instead of "DNA," but he misses the point entirely by still using that idiotic metaphor. The end result is he comes out sounding dumber than the stereotypical MBA.
2. No mention of how Sun "slimed" IBM's VisualAge Smalltalk or Bell Labs' Inferno, because of course Gosling is convinced he invented bytecode VMs and is god's gift to programmers.
...He's trying to sound more intelligent than the MBA stereotype...
...Gosling is convinced he invented bytecode VMs...
If you have to pretend to be a mind-reader in order to rationalize your irritation, maybe you should just take a few deep breaths and ask if there's some other way you could interpret his statements.
Gosling has had reservations about Harmony in the past. But in general with Sun's approach, they never maintained a consistent disdain with Kaffe, Harmony, Classpath, etc. This is why Google brought up Oracle's failure at building their own Java-based smart phone before the suit was filed.
Pardon my "naiveté" but when Android first released, I always assumed Google legitimately licensed Java from Sun. How could Google not see this problem coming? Why didn't they pick Python for Android? Or JavaScript?
I have to wonder if Microsoft has been taking advantage of this situation by further appealing to developers to take up/switch to Window Phone 7. C# is a lot closer to Java than Objective-C is, after all.
Developers will follow the consumers. Once the consumer base builds as high for Windows Phone as it is for Android, you'll have no problem attracting developers.
Exactly, if you can't attract casual developers, then you can't attract consumers. Look at the hit that is Angry Birds, there's still no Blackberry version and that's gone from casual startup to monolith of a gaming company.
And Sun totally slimed UC Berkeley - ripping off their OS for a propriety workstation.
Although if you are allowed to hold a copyright on APIs then ATT is in for some serious remuneration on all this Unix and Linux stuff out their, not to mention C and C++.
If you were to take a good, portable language which a ton of developers are already familiar with and make it successful on the mobile - you are not going to go with Sun, JCP or any other "community" designed models.
So Google's problem was that they liked the Java language and they had to attract developers so they had to adopt the API but they had to throw away the rest of Java - including the JVM, Swing and ton of other useless-for-mobile APIs none of which were really a viable option on mobile.
So you could argue that Google could have been a good citizen, good Sun friend etc. but if they had to take J2ME and/or JCP for that, it would clearly defeat the purpose of Google entering the mobile market.
And I don't understand what McNealy's quote about "they [Google] don't share" is all about - it's open source, Oracle can adopt Android UI APIs or whatever else they wanted. If this is about money - yeah may be Google should have thrown them some bucks but I guess it had to be done under "licensing" which again would have meant dealing with Sun's "Community Process", "Standardization" and other bloat all of which were directly responsible for J2ME not going anywhere in the first place.
Another issue is that Gosling seems to be FUD mongering with Compatibility stick - "we've got organizations of people that do compatibility testing and actual negotiating amongst the different handset makers so that things like GPS APIs look the same." Android has standardized GPS API since I don't know when and that doesn't seem to have been a problem with any of the dozen Android devices I've used. The only difference is Google puts out those APIs and it works with manufacturers to amend / add as required. Google has the final say over APIs which is a good thing - you don't want hardware vendors designing software APIs that work cross device - that is best left to people who know that sort of thing. And not having a sanctioned committee with varying interests wrangling each other and slowing down progress has also worked out well for Google and Android.