Comment by blinkingled | Hacker News Reader

Comment by blinkingled | Hacker News Reader

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.

http://en.wikipedia.org/wiki/Fair_use

Google's best defense is that API can't be copyrighted actually, and that will be decided by the judge if the jury find Google's work is not fair use.

jury told by Judge to assume APIs are copyrightable.

Since that order emphasizes the importance of the APIs, it probably weighs in Oracle's favor.

We'll find out for sure in a few days.

http://arstechnica.com/tech-policy/news/2012/04/oracle-presi...

From the article:

> 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.)

which is exactly what felipeko was referring to.

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.

Which I agreed with. That's why I said "We'll find out for sure in a few days."

I just posted this to highlight the fact that things are in Oracle's favor.

jury told by Judge to assume APIs are copyrightable.

Since that order emphasizes the importance of the APIs, it probably weighs in Oracle's favor.

If that is the case, designing a C-family language and then trying to evangelize it with the developer crowd was the legally available direction.

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.

I'm counting 34 circles in your comment. License them or lawyer up, freeloader.

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.

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 :)

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.

The only J2ME API that I've used is GPS, and it was far more fragmented and unreliable than any Android implementation that I've seen.

(also, Android has a compatibility test system/process)

> Java on the desktop and mobile never went anywhere

Desktop: true.

Mobile: wasn't Java ME on a bazillion feature phones?

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.

The lack of good apps is hardly surprising. The screens were tiny, and they lacked an app store. Its hard to have ad supported apps on a tiny screen.

>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.

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.

Battery life was actually good (if only due to all those other things you've listed). I usually had a week between recharges on a basic 2003 handset.

You know what the irony of this is? Show me an Android UI pre-iOS that didn't make me puke.

Google nicked the programming language off Sun and an interface off Apple.

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.

Reply on news.ycombinator.com