Google, Sun Headed for Showdown Over Android

narramissic writes "There may be trouble brewing between Google and Sun. Google has written its own virtual machine for Android, 'most likely as a way to get around licensing issues with Sun.' If Google used any of Sun's intellectual property to build Dalvik, Sun could sue Google for patent infringement. But here's where it gets interesting - Sun is a vocal advocate for open source and it would 'hardly appease the open source community to sue Google over an open source software stack.'"

Comments

To put it bluntly.

[LWATCDR]

So reporter thinks that Sun might sue Google for forking Java all the while over looking the fact that Sun has GPLed Java and that other groups have produced versions of Java with out getting sued. Google and Sun both are saying that they are working together.
In other words a none story.

Re:To put it bluntly.

[Anonymous Coward]

No, it's not a non-story.

OK, mini-rant about Sun and Java's naming. Java is three distinct things that Sun has helpfully lumped into one name:

1. The virtual machine.
2. The collection of libraries.
3. The language itself.

Google is using #3, the Java language. They are not using #1, the virtual machine, and using only some subset of #2, the collection of libraries.

Now given the way that Sun sued Microsoft over changing parts of Java in the past, it's almost guaranteed that they'll do it again over Google not using their virtual machine or library.

I can't really blame Google though, since the VM is why Java is notoriously slow, and the libraries is why it's notoriously member hungry. For a PC that's not a big deal, but on a mobile device, it is. There's a reason Java ME has gone nowhere, and Google is trying to succeed where Java has failed.

Re:To put it bluntly.

[davester666]

I think Android is good for the cell phone industry and for developers in that it sounds like it's a full reset of the API's that are available to developers. The current setup that Sun provides has boatloads of backwards compatibility cruft and old API's like AWT that just don't help with providing either great experiences for developers or end-users. If anything, Sun will jump on the Android bandwagon by adding the same API's to their VM [making it even more bloated].

Re:To put it bluntly.

[fm6]

Pretty much. But it's worth noting that many companies in Sun's position would sue Google. Not only did Google clone Sun's Java technology, they hired some of Sun's best Java people to do it. Of course, suing wouldn't accomplish much, but some ego-driven CEOs wouldn't let that stop them.

Re:To put it bluntly.

[Bill, Shooter of Bul]

Yes, it is a non story. Sun sued Microsoft years before they open sourced java. Micorosft has also signed a license saying that they would not fork java, but they did anyways. In this case Sun says its cool, then its cool. I don't know how true your assertions about Java ME are, but they are not true of Java in general. GuI interfaces are usually done horribly in Java, because its easy to screw them up. The unresponsive Gui (see zend framework) often makes people think that Java is slow.

Re:To put it bluntly.

[cromar]

It's not the CEOs. It's the PR and legal depts.

Re:To put it bluntly.

[Dr. Slacker]

I think you forgot that MS had to stop using their Java VM and use Sun's VM instead. If you look in an XP machine's Control Panel you'll see Sun's JAVA icon.

Re:To put it bluntly.

[Actually, I do RTFA]

GuI interfaces are usually done horribly in Java, because its easy to screw them up. The unresponsive Gui (see zend framework) often makes people think that Java is slow.

Unresponsive is slow. From a user's (and my) POV, I don't care if code executes in 10ms or 299ms if the GUI refreshes every 300ms. Why, because I use a program to do things, not to marvel at the effiency of the algorithim (unless I'm examining the code).

Additionally, a lack of progress bars leads to killing processes and restarting them, making them slower in reality.

Re:To put it bluntly.

[ClassMyAss]

Indeed - Sun made a lot of big mistakes early on that have severely hampered Java's acceptance since then:

1) The first VMs were truly awful and slow
2) Terrible browser integration with applets
3) AWT as a whole was just a mess, and Swing didn't do much to help things.
4) Brought the language out as a trimmed down C++, only to realize that some of the stuff in C++ was actually useful and put it back in later (it happened with generics and static imports, and if reason takes hold it will eventually happen with operator overloading)

1) is pretty much fixed now on the desktop, but when you go to the mobile world you're basically bac to first-gen VM territory. It will be interesting to see if Dalvik is much better than your run-of-the-mill J2ME VM these days; I'm sure it's possible, but I think it's yet to be proven (I'd love to see actual tests side by side!). 2) is irrelevant for phones (interestingly enough, apparently Android can't load Java applets from the browser - ha!), but supposedly close to being fixed on PCs - of course, this is now a decade late, years after everyone has written off the applet as a delivery mechanism. 3) is still making Java development hell, so I'm thrilled that Google has decided to throw the whole mess out and start new, I suspect Google will do it much better. Maybe some of their interface code, once opened up, will be useful enough to swim upstream and help out "real" Java?

Re:To put it bluntly.

[Anonymous Coward]

I can't really blame Google though, since the VM is why Java is notoriously slow, and the libraries is why it's notoriously member hungry. For a PC that's not a big deal, but on a mobile device, it is. There's a reason Java ME has gone nowhere, and Google is trying to succeed where Java has failed.

Why are you talking about Java ME as being slow and memory hungry? Nothing could be farther from the truth. I suggest you pick up a Sony Ericsson mobile, anything from the last 2-3 years will do, and test your theory.

Re:To put it bluntly.

[Anonymous Coward]

To quote an e-mail received in my inbox:

Hello Everyone, You may have heard about the new Google Android mobile phone SDK. Sun's legal counsel has informed Sun employees not to download this software due to IP concerns. I'm including his message below. Here's the message from Chris Nadan:

Please be sure no one downloads it on behalf of Sun, as the Google download license has a provision that says the downloader agrees Google owns all the IP (which, since there's some Java in there, they don't). We may want to engage a third party contractor to review the code for us.

Again, please do not download this software. I'll alert you to future communications from Sun's legal counsel as I receive it. Thank you for your understanding and support. Regards, Gary

Re:To put it bluntly.

[Pollardito]

Now given the way that Sun sued Microsoft over changing parts of Java in the past, it's almost guaranteed that they'll do it again over Google not using their virtual machine or library. but did they just take away things from the library and not add new features to the core? it's one thing to release a new platform that doesn't support all of the java libraries, that just means that existing programs aren't completely portable to your new device and is really your own loss. it's another to do what MS did and that is to add language features (method pointers for callbacks), release a developer suite for your bastardized version of the language, and encourage people to develop programs using it that won't work on other VMs. Sun probably doesn't love either choice, but they're not equivalent problems.

Re:To put it bluntly.

[Bearhouse]

"In other words a none story"

Yup, but watch while everybody jumps onto the empty hook anyway...this is /.

Re:To put it bluntly.

[ReeceTarbert]

There's a reason Java ME has gone nowhere

Uh? You are kidding aren't you?

What about this list of Networks Operatos and Carriers

Or the Java ME Device Table?

Or, for that matter, what about these phones from Nokia, Motorola and Sony Ericcson just to name a few?

Google is trying to succeed where Java has failed

I agree that there's a lot NOT to like about Java, but calling it a failure it's just trolling... and I just fell for it! ;-)

RT
--
Your Bookmarks. Anywhere. Anytime.

Re:To put it bluntly.

[ReeceTarbert]

The current setup that Sun provides has boatloads of backwards compatibility cruft and old API's like AWT

This may be true for desktops, but the version used on mobile phones and other handheld devices has no AWT (or Swing for that matter) and it's called Java ME -- check the Platform Overview for the details if you like.

RT
--
Your Bookmarks. Anywhere. Anytime.

Re:To put it bluntly.

[Weedlekin]

MS didn't have to stop using their VM in the original Java court case, which only required two remedies:

1) That the MS VM defaulted to standard Java and used a switch to engage MS extensions instead of being the other way around, as was originally the case.
2) Microsoft would add all standard Java classes including JNI to their distribution instead of shipping a subset that made writing multi-platform code difficult.

It actually took MS about a month to comply with these orders by making an update available that implemented them.

Re:To put it bluntly.

[drinkypoo]

Additionally, a lack of progress bars leads to killing processes and restarting them, making them slower in reality.

Yes, this is the biggest problem I have with most amateur-level software. So I am careful to avoid it on the rare occasion I write anything, and provide plenty of status messages. But too often you will click something and then wait for a long time with no updates. My current favorite offender is Vega Strike, a cross-platform spaceflight game. There are many times when it looks like it's frozen.

Re:To put it bluntly.

[Cid Highwind]

There's a reason Java ME has gone nowhere, and Google is trying to succeed where Java has failed.

I take it that by "nowhere" you mean "into pretty much every phone in use today, with one notable exception (iPhone)"...

Re:To put it bluntly.

[Fizzl]

Platform is there, but applications are not.
I have develop some stuff for Java ME just to get familiar with it. I don't own the latest and greatest phones, so trying to use graphics for even UI was a show stopper.
I have also coded module tests for the standard libraries and JSR's for one manuacturer. I tried running them on different manufacturers platforms just for fun, and found out that the API is not reliable accross platforms, which means that you have to develop towards the lowest common denominator. (sp?)
It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

Re:To put it bluntly.

[Xordan]

Parent is correct that this is a non-story.
I went to a talk by Scott McNealy (Chairman and Co-founder of Sun) at Imperial College London this week and the question of what Sun's stance on Android is was asked to him.
His response was that they totally welcomed and supported this move, and that they were sure that there would be no breakages in core API compatibility between the Sun VM and Android.
This break in the core API was the main reason why Sun sued Microsoft, before Java was GPLed (also the reason why Java wasn't under the GPL license originally, so Sun could protect it long enough so that it was used on enough devices that nobody would want do a Microsoft).

Re:To put it bluntly.

[ReeceTarbert]

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

True. If you stick to the CLDC/MIDP profile your options are fairly limited, but usually developers target one series from one manufacturer. For instance, for a Series 60 model from Nokia, in addtion to the Connected Limited Device Configuration CLDC 1.1 (JSR-139) and the Mobile Information Device Profile MIDP 2.0 (JSR-118) you could use:

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

Re:To put it bluntly.

[harlows_monkeys]

Google's VM is not a Java VM. That is, it does not execute Java bytecodes and does not follow the JVM specs. Rather, Google has basically a recompiler that can read a Java class file and generate code for Google's VM.

Re:To put it bluntly.

[oblonski]

You sir, need to head over to http://wap.getjar.com/ with your mobile phone and see all the quality apps developed and uploaded for testing and evaluation With your desktop browser just go to www.getjar.com and see what's available there

and the best part of all these things are: they run in a java sandbox on your phone and uses gprs so you end up doing most everything you can do with a desktop browser, but on your phone and for the equivalent of a couple of cents

I have heard some complain about it running in a java sandbox and having to go through a couple of extra clicks of the joystick on the phone to get to them, but that is just silly considering the benefits you get

Re:To put it bluntly.

[Anonymous Coward]

I'm aware that they hired Romain Guy (http://www.curious-creature.org), one of Sun's most brilliant UI engineers. Who else jumped ship?

Re:To put it bluntly.

[stoanhart]

Very good point. Java code, written properly, can be as fast as anything. Anyone ever seen Jake? It's the open source Quake II engine translated into Java (from C++); it beats the Quake II engine in benchmarks.

Re:To put it bluntly.

[mcvos]

I can't really blame Google though, since the VM is why Java is notoriously slow, and the libraries is why it's notoriously member hungry. For a PC that's not a big deal, but on a mobile device, it is. There's a reason Java ME has gone nowhere, and Google is trying to succeed where Java has failed.

Java has not been notoriously slow for a couple of years now. Unless you consider C++ notoriously slow, because that's about how fast Java 5 JVMs are. It is true that Java is somewhat memory hungry, but I don't see how that can be avoided in a proper OO language (which C++ isn't).

And Java ME has most definitely gone somewhere. If I'm not mistaken, just about every single Nokia phone runs Java, and that's a sizable chunk of the market. And I doubt they're the only phones with Java.

Re:To put it bluntly.

[fm6]

I think I speak for everybody here when I say: Huh? "Hello, Legal? Public Relations here. Would you mind launching a multi-million dollar lawsuit? What, you want to check with the CEO first? Whatever for?"

Re:To put it bluntly.

[Anonymous Coward]

You forgot a few things.

Sun has helpfully lumped the following into the JAVA name:

1. The virtual machine.
2. The collection of libraries.
3. The language itself.
4. The operating system (JAVA Desktop System) which contains no java.
5. The SUN ONE JAVA Enterprise Servers (which actually have nothing to do with java). These include the SUN ONE JAVA Enterprise Messaging Server, Instant Messaging Server, Proxy Server, Webmail Server, Identity Server, Directory Server, Calendar Server, Portal Server, Access Manager, Application Server.

Re:To put it bluntly.

[jhol13]

Check miniopera.com.

They do not find it insufficient, so maybe the problem is you, not Java ME?

Does Sun make any money from Java on phones?

[NickCatal]

Anyone know how much a cell phone manuf has to pay Sun to include the J2ME VM in their product?

Re:Does Sun make any money from Java on phones?

[keithjr]

I'm going to go with 0, since Java is open-source and free. Somebody correct me if I'm wrong on this point. How Sun makes money on Java is a very complicated question, but up front, none. Similar questions like how they make money on the open-source Solaris OS are equally difficult to answer. But it all fits into the same business model.

Re:Does Sun make any money from Java on phones?

[Anonymous Coward]

You're wrong.

Sun has in the past stated that the majority of their profits come from Java, and more specifically from Java in embedded devices like Blu-Ray and mobile devices.

They charge for it, although I doubt you'll find exact details online. But Sun does make money off of Java. They're only open-sourcing the x86 version, or so they claim. Go ahead and try to find any mention of open anything on java.com.

Re:Does Sun make any money from Java on phones?

[mhall119]

Sun has or is in the process of open-sourcing their implementations of JavaSE, JavaME and JavaEE, as well as their JVM and Java compiler.

Sun does make money licensing their Java code to third parties, but that isn't a requirement for providing Java support. The Java language specification is freely available, anybody can create their own implementation, but for most companies it is cheaper to reuse Sun's implementation than make their own. Sun even provides financial assistance for small businesses or open-source projects to take the Java compatibility test. Heck, they've even open-sources the test harness for the compatibility test.

Re:Does Sun make any money from Java on phones?

[ricegf]

I don't know for sure, but since it's Slashdot, I'll happily speculate. ;-)

Java is GPLed. A manufacturer is free to tweak Java for his machine and ship it... with the source code. Or, he can pay Sun a nominal fee for a non-GPL license and tweak to his heart's content, and keep his tweaks to himself.

This is precisely the dual-license model used for QT, and it works pretty well. Free software gets to use the technology for free. Proprietary software pays for a proprietary license, but they're charging their customers anyway. Everybody's happy. Well, except for BSD advocates... ;-) ;-)

Re:Does Sun make any money from Java on phones?

[Eponymous Coward]

I'm not sure what you have to pay, but it is something.

Here's a better article about the same thing. I was wondering if this story was going to get picked up anywhere.

I don't think JavaME will be given away any time soon. It's going to be really interesting to see what Sun does here.

-ec

Re:Does Sun make any money from Java on phones?

[onefriedrice]

> Well, except for BSD advocates... ;-)

Actually, I'm happy too.

Re:Does Sun make any money from Java on phones?

[kripkenstein]

This is precisely the dual-license model used for QT, and it works pretty well. Free software gets to use the technology for free. Proprietary software pays for a proprietary license, but they're charging their customers anyway. Everybody's happy. Well, I'm not sure Qt is such a good example. In fact many (including me) believe that the reason GTK+ has been popular in recent years (used on all major desktop distros - Ubuntu, Fedora, SUSE; Nokia devices; etc.) is precisely the licensing issue. Imagine if Linux itself (the kernel) used that licensing model - GPL for free, pay up otherwise. Would Linux be as popular today? I doubt it.

The general model of GPL for apps, LGPL for frameworks that apps run on top of, makes sense. You want to extend the kernel? Write in GPL. You want to run some app of yours on top of it? No problem, you are free to do so. This is precisely what the LGPL is for.

Re:Does Sun make any money from Java on phones?

[Anonymous Coward]

Okay, let's see here
I write modules for the Linux kernel: I'm forced to release it as GPL, but I'm still free to charge money (though those who've bought it may distribute it as they want).

The same still holds with Qt. If I _would_ like to charge money for my product _and_ be able to hinder further distribution/not give out source code, I'd need the commercial Qt license. I'm free to do what I want with the GPL Qt except for:
* Relicensing it
* Stop redistribution (though I'm free to never give it to anyone)
* Withhold source code from people that have received my software

GPL explicitly prevents you from imposing further restrictions on your GPLed code and as such, anything allowed with the GPLed Linux kernel is allowed with the GPLed Qt.

Re:Does Sun make any money from Java on phones?

[makomk]

Unfortunately, it looks like the open-source version of JavaME doesn't have the linking exception, and therefore can't be used to run non-GPLed JavaME applications. (This was one of the things mentioned in TFA).

Re:Does Sun make any money from Java on phones?

[ReeceTarbert]

I'm going to go with 0, since Java is open-source and free. Somebody correct me if I'm wrong on this point.

Quoting from Java ME Lincensees:

The companies listed below have licensed Java Platform, Micro Edition (Java ME) configurations and profiles and the associated Technology Compatibility Kits (TCK). Only Java ME technology licensees can claim compatibility with Java ME technology specifications and TCKs.

The list is quite long and of course includes the usual suspects.

RT
--
Your Bookmarks. Anywhere. Anytime.

Re:Does Sun make any money from Java on phones?

[Goaway]

Incorrect.

Java on the desktop is GPLed, with an extra exception that allows non-GPL software to run on it.

JavaME does not have this exception, thus forcing phone manufacturers to pay for a commercial license to escape having to GPL their entire software stacks (which they will not and often can not do).

And that is why Google made their own VM, to work around this huge limitation Sun put in to protect their profits.

Re:Does Sun make any money from Java on phones?

[mhall119]

According to Sun, most phone manufacturers will use a proprietary implementation of JavaME, because it's implementation is highly dependent on the hardware itself, unlike the more generic JavaSE and JavaEE. This is also why PhoneME is GPL, not LGPL.

But as for only being able to run GPL'd applications, that's not true. The GPL only restricts distribution, not use, so you can't distribute a non-GPL'd program that is linked with PhoneME classes. Since every implementation of JavaME will use the same namespaces, you should be able to compile your JavaME program against any implementation of JavaME, and then run it without problem (technical or legal) on PhoneME. You can't distribute PhoneME linked to your program, but you can distribute your program by itself.

nothing to see here

[doktorjayd]

FTA:

While Sun declined to comment directly for this story, it pointed to some public statements from company executives. Jonathan Schwartz, president and CEO of Sun, wrote a blog post congratulating Google on the day of Android's launch. Notably, he refers to Android as a "Java/Linux" platform

where is the trouble? the article is pure beat-up.

the reason for dalvik is entirely technical. check out the youtube presentations, it makes it pretty clear that you develop in pretty much pure java, but the runtime needed a little more than the standard jme could provide.

move on..

Re:nothing to see here

[Goaway]

the reason for dalvik is entirely technical. Incorrect. There is a very big legal issue in that Sun does not allow non-GPLed software to run on the GPLed mobile Java unless you buy a license. That is what this, and many previous and no doubt many future stories are about.

Re:w00t!

[Anonymous Coward]

The chicks, money and fame will be there soon.

Nonsense

[loubs001]

Schwartz is sencerely all for oepn source, and he insists he's not interested in sueing anyone over patents. They might sue over license infringement of course, but in this case there is none. It's all Apache code. The only sore point is that Android doesnt include a complete and compliant Java stack (neither JME or JSE), only a subset, so they wont be able to certify it as a compliant implementation, and therefore it's technically not 'the Java platform', it just looks alot like it. Google knows this, so they've been careful in their videos to only say 'written in the Java programming language'. Google and Sun are friends. This will be good for Java. Sun will no doubt provide some tooling support in NetBeans. I see no chance of any 'showdown' here.

FUD

[mritunjai]

Sun and Google are good partners, and I don't see them getting into legal minefield over this issue. Heck, Sun has never been a litigious, two main cases being MIcrosoft (bastardizing Java) and NetApp (counter-suing them... in California vis-a-vis NetApp filing in lower Texas court).

However, there *definitely* would be issues raised by Sun over this issue. You can fork and modify their Java implementation all nilly-willy you want but you CANNOT call it Java unless it passes *all* the certification tests.

So unless Google certifies their implementation, it cannot be called Java, and if Google doesn't - there *would* definitely be issues. Sun doesn't take bastardization of Java lightly!

Re:FUD

[TheLinuxSRC]

The article does appear to be FUD, however your assertion "So unless Google certifies their implementation, it cannot be called Java, and if Google doesn't - there *would* definitely be issues. Sun doesn't take bastardization of Java lightly!" is not only difficult to parse, but unnecessary. The article states: "By contrast, Google carefully appears to avoid calling Android a Java platform. Google describes the Android software development kit as a set of tools that lets developers create applications using Java."

Re:FUD

[m2943]

Sun and Google are good partners

Really? In what way? If anything, Google keeps demonstrating that one can build enormously scalable and highly reliable web services completely without Sun hardware.

So unless Google certifies their implementation, it cannot be called Java,

And it is not called "Java", it is called "Android". What Google is saying is that you can use Sun's Java environment to create applications for Android, which is completely correct.

Sun doesn't take bastardization of Java lightly!

No, Sun prefers to do all the Java bastardization themselves (Java 1.6, what a p.o.s.).

How about an Android for this Web ?

[kyashan]

A bit offtopic...

How about Google bringing decent Java performance on the Web ? Possibly with OpenGL ES like for Android.
Java on web browsers has possibly gotten worse with years. Sun loaded it so much with useless crap and didn't even try to get a proper way to vsync an applet (very important if you are trying to make a media application/game that requires the basic concept of frame-rate).

Current multi-media web dev is relegated to Flash, but I'm sure that there are many skilled programmers out there that would be glad to have a lean Java VM & API working in web browsers. Sun gave up long time ago, Google could take over and make it ubiquitous.

Re:How about an Android for this Web ?

[mhall119]

Java on web browsers has possibly gotten worse with years. Java 6 update 3 contains improvements to both install and startup of the JVM within web browsers.

Current multi-media web dev is relegated to Flash, but I'm sure that there are many skilled programmers out there that would be glad to have a lean Java VM & API working in web browsers. Sun gave up long time ago, Google could take over and make it ubiquitous. A new spec for easily embedded media components is in the works, hopefully it will make it into Java 7, and will be a good compliment to Java FX script on the web. There is talk about plugging it into existing media frameworks like GStreamer or VLC, to bring in all of their supported formats. Sun may have deglected multi-media, but it's not quite forgotten yet.

Re:How about an Android for this Web ?

[samkass]

A new spec for easily embedded media components is in the works, hopefully it will make it into Java 7, and will be a good compliment to Java FX script on the web.

I'm looking forward to Sun's renewed interest in the desktop (as someone who develops desktop Java applications). However, creating yet another media component stack on Java is a pretty boneheaded move. Clean up JMF or help FMJ succeed, then link it to the scripting engine. That would be 100x more useful than yet another media framework they'll build then ignore to rot.

Re:How about an Android for this Web ?

[mhall119]

As someone who has worked with JMF, I can tell you that no amount of "cleaning up" would make it feasible for someone developing an applet or application that just needs to play a media file. You also wouldn't want to load the entire JMF just to play a file. I think it's better to make light-weight media widgets, and only employ the JMF if you are going to need more control over editing and playback. After all, there are image widgets, not image manipulation frameworks that you have to extend just to put an icon in your application window.

Re:How about an Android for this Web ?

[kyashan]

I'm not holding my breath. They've missed their big opportunity with the web already. People were writing cool media applets (allow me a plug) and Sun practically ignored those, stuff like Java 3D is a sign of old corporate business thinking. They should have embraced the more hacker-oriented developers.
It's 2007 and there is no solid reliable way to do your own rendering on a web browser.

Please, no more updates, this thing can only grow worse.

Re:How about an Android for this Web ?

[kyashan]

Abuse: troll on what basis ?

Re:How about an Android for this Web ?

[superNag]

In a way, they've done that with GWT. And it's in many ways similar to Android: use Java for development, then recompile into something else (HTML+JavaScript or Dalvik bytecode).

Slashdot is being sensational

[bogaboga]

The article that Slashdot links to is headed: "Google and Sun may butt heads over Android." Key word: "May".

Then Slashdot modifies the headline to say: "Google, Sun Headed for Showdown Over Android."

Question is: Does anyone of these reporters work for either company in order to have this seemingly serious situation? I doubt it.

J2ME

[notknown86]

IMHO, Android fills a void in Java Mobile applications by providing API to build richer applications (lcdui, in particular, is limiting) - more useful for Smart Phones which contain the ability to provide these types of functionalities. If J2ME filled every void, Android as an API wouldn't be needed (though Android as an OS could still fill a void). According to the article, JME requires a licencing fee. Android does not - this precludes building on the existing platform (unless, of course, Sun actually did waive the fee). Regardless, isn't it possible that this is a fragmentation where the positives outweigh the negatives?

Re:J2ME

[onefriedrice]

> Android fills a void in Java Mobile applications by providing API to build richer applications...

Yes, good. Richer applications. Probably the only thing like it (technically) is the iPhone SDK which isn't available to 3rd parties yet. Personally, I prefer Objective-C to Java anyway, and we've already seen some great 3rd party apps on that platform. The obvious problem is Apple hardly seems to want to support an open API on its own phone, let alone make it available to other phones. It's not too late, but it doesn't seem like this is something Apple would pursue. But IMO, this is or would have been a great opportunity for Apple to get a piece of this pie.

Apple is interesting. Some things they do make you smack your head and wonder what on earth they are thinking, but then you look at their amazing financial statements and you wonder how they do it. I guess one thing you can say is they know their customers well, meaning casual consumer top interests are not necessarily our own here at Slashdot. Anyway, now I'm off-topic. 'Night.

Re:J2ME

[hey!]

The problem with J2ME is that it isn't a product. It's a specification -- or worse a set of specifications that have different implementations on different vendor devices.

J2ME is just like Unix was when Windows came along and kicked its ass off the low to midrange. Every hardware vendor had its own Unix, and while any Unix would have kicked Windows ass in technical terms, in effect you ended up tying your applications not only to your platform vendor, but to your hardware vendor as well. Windows not only gained a critical mass faster, it also gave customers at least one degree of freedom in their future purchases.

Unix came back to the low end when highly interoperable FOSS versions became available. I'm really excited about the potential of Dalvik to be ported to smart phones and PDAs; it could be the Linux to J2ME's Unix.

Ahhhh, Slashdot

[ZombieRoboNinja]

Title: "Google, Sun Headed for Showdown"
Summary: There MAY be trouble brewing between Google and Sun...
TFA: Google COULD get in trouble with Sun, according to some analyst (but both parties declined to comment)
Reality: Move along, nothing to see here...

Re:Ahhhh, Slashdot

[Kingrames]

This could be going places.

Upcoming blogs:
Google, Sun Fight to the death, thousands injured
Sun uses death star to kill google, but google holds up giant mirror. news at 11.
Google, Sun have massive war. everyone invited. Two japanese cities nuked.

Re:Ahhhh, Slashdot

[bladesjester]

Sun uses death star to kill google

Let's not get AT&T involved in this.

Re:Ahhhh, Slashdot

[ArcticFlood]

AT&T? Surely you mean Hitachi.

Re:Ahhhh, Slashdot

[bladesjester]

No, I mean AT&T. Their logo used to be a deathstar looking space station with a little spaceship racing away from it. Their current circular logo is a highly stylized version of their old one.

Achilles Heel

[Vulcann]

I really think Google needs to look at more than one development language to target Android applications. Being only centered around Java is bad for more reasons than just a potential lawsuit. It locks out so many developers who are eager to contribute to the platform.

Re:Achilles Heel

[mhall119]

With a good Java platform, you can use Javascript, Groovy, Ruby, Python, and several others.

Re:Achilles Heel

[Anonymous Coward]

"It locks out so many developers who are eager to contribute to the platform."

would this not be true regardless of what language they picked? for example, as a java developer with little interest in developing desktop applications, i'm locked out of contributing code to many of my favorite linux applications which are invariably in c/python/perl. how is this different?

while there are historical reasons to avoid java for oss projects - those are largely gone with the gpl'ing of java.

danger too

[Anonymous Coward]

same guy @goog wrote the Danger jvm. Oh I see! Get the one with the bigger bankroll, got it! Thx.

honest to god

[pugugly]

I read this for a second as "Google, Sun Headed for Showdown Over Asteroid", and thought Google *might* be overreaching - .

Pug

Why?

[Tony]

How does Java lock out any developer? If you're a developer, you can learn Java if you don't already know it. If you're unwilling to learn a new language, then *you* are the one selecting yourself out, not the platform.

I had to learn C#. You can cowboy up and learn Java.

Re:Why?

[m2943]

I know Java just fine, I just can't get my work done in it.

Fortunately, it looks like Android also supports C and C++; Java is only needed for the PIM-like apps, and for that it's sufficient.

Re:Why?

[Anonymous Coward]

You "know" Java, but you can't get your work done in it, but you can in C and C++, even if the platform you're using has identical APIs, libraries, etc, available for Java, C, and C++.

Uh-huh.

I seriously doubt you know Java.

Does that work?

[Estanislao Mart�nez]

The only sore point is that Android doesnt include a complete and compliant Java stack (neither JME or JSE), only a subset, so they wont be able to certify it as a compliant implementation, and therefore it's technically not 'the Java platform', it just looks alot like it. Google knows this, so they've been careful in their videos to only say 'written in the Java programming language'.

IANAL, but I bet you that actually doesn't work legally. Saying that the programs would be "written in the Java programming language" is enough to lead reasonable people to conclude that they would be providing a compliant Java environment, and thus, grounds for a complaint on the part of Sun. I.e., you don't get a pass to have your product to ride on Sun's Java(TM) product's reputation and value in the marketplace just because you use the word "language" instead of "platform."

Re:Does that work?

[Breakfast Pants]

But you actually use Sun's javac to compile the initial phase. If I wrote a compiler that took executables produced by MS's Visual Studio and compiled them into some virtual machines bytecode, and it didn't worth with executables from GCC or any other compiler, I could say "you write your programs using Microsoft Visual Studio, and then run the result through this convertor" in full legality; I couldn't even describe my product if I weren't allowed to. This is in fact exactly what Google has done.

Change the name.

[SanityInAnarchy]

There used to be something like this with JavaScript, though I don't think Sun ever owned that -- wasn't it Netscape? Ah, well...

I remember Microsoft re-implemented it from scratch, but because someone owned the name "JavaScript", they simply called it "JScript".

So, Google is now selling the brand "Android", which is a shift from the pseudo-codename "gPhone". It seems like they're in an ideal position to say "Fine, we won't call it Java." And they will be careful to refer to it only as the "Android language", "Android libraries", and "Android runtime" in their official documentation -- even though many people will simply call it "Java" anyway.

So, threatening legal action when all you own is the name -- that's not always stupid, but here, they're going up against Google. Seems to me, they'd be throwing away a lot of perfectly good free PR for Java -- especially if Android kicks Java ME's ass.

Re:Change the name.

[halycon404]

I could be remembering this completely wrong, its been a few years since I've looked at JavaScript, much less payed attention to it. But...

Netscape incorporated Java Script, I don't think they ever actually "owned" it though, in so much as Java Script was more of an idea out in the wild long before it was a formal language. The inventor of Java Script came up with the idea while working for Netscape, he's the lead developer for Mozilla now(I think?). The whole JS idea was really a clever hack that he cludged together that tricked browsers into handling some information in ways it normally wouldn't. Over time it got added to and browsers started officially supporting the hack because it was useful.

Re:Change the name.

[ClassMyAss]

Jonathan Schwartz's blog post seems to indicate that Sun would prefer to milk this for the publicity rather than cause a fuss over it. Whatever happened behind the scenes, I took that post as a white flag from Sun, basically saying, "Look, we're not on board for a bunch of reasons, but we've got no beef here, let's all try to get along and spin this to each of our needs."

Even if the VM is not officially Java, you're still ending up with a whole lot of development energy invested in Java, which is good for Sun. I really hope there's no way they are stupid enough to bring this to court just to make a few bucks...

Re:Change the name.

[nospam007]

from Wikipedia:

JavaScript was originally developed by Brendan Eich of Netscape under the name Mocha, later LiveScript, and finally renamed to JavaScript. The change of name from LiveScript to JavaScript roughly coincided with Netscape adding support for Java technology in its Netscape Navigator web browser. JavaScript was first introduced and deployed in the Netscape browser version 2.0B3 in December of 1995. The naming has caused confusion, giving the impression that the language is a spinoff of Java and has been characterized by many as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new web-programming language. [1] [2]

To avoid trademark issues, Microsoft named its implementation of the language JScript. JScript was first supported in Internet Explorer version 3.0, released in August 1996 and included Y2K compliant date functions, unlike those based on java.util.Date in JavaScript at the time.

Netscape submitted JavaScript to Ecma International for standardization resulting in the standardized version named ECMAScript.[4]

Re:Change the name.

[Ba3r]

google does have deep pockets, and sun is not exactly rolling in dough

Re:Change the name.

[inline_four]

It seems like they're in an ideal position to say "Fine, we won't call it Java." And they will be careful to refer to it only as the "Android language", "Android libraries", and "Android runtime" in their official documentation -- even though many people will simply call it "Java" anyway.

I don't think that's gonna fly, if it came down to that. If you look at the Dalvik libraries, there's a good deal of common J2SE API, which are there for a reason -- to make your pre-existing Java code run on this platform. For instance, Apache Commons libraries should just recompile for Dalvik straight out of the box. Not only are those libraries using "java.*" packages, they need those libraries to work. So even if Google renamed "java.*" packages to "android.*" packages, it might not pass the muster in court unless they actually stopped using cloned Sun's libraries, which would be a hard pill to swallow.

But I'm with the other posters. I don't think Sun's really gonna move on this. Wouldn't be much to gain for them.

Re:Change the name.

[SanityInAnarchy]

So even if Google renamed "java.*" packages to "android.*" packages, it might not pass the muster in court unless they actually stopped using cloned Sun's libraries, which would be a hard pill to swallow.

Given our court system, you may be right.

But understand, all of that is GPL'd. (Or am I wrong about that?) The fact that it's GPL'd means Sun has no control over it except the name and the requirement that it also be GPL'd (and thus have source code available). Similarly, the only control anyone has over Linux is whoever owns the trademark and logo.

But I'm with the other posters. I don't think Sun's really gonna move on this. Wouldn't be much to gain for them.

I'll agree with you there.

Re:Change the name.

[inline_four]

What I also found curious is that we already have a precedent for this situation: GWT. It's almost the same thing as what happens here:

1. Write stuff in Java against a subset of J2SE API with Google's proprietary API added.
2. Compile to standard Java bytecode.
3. Cross compile to something else (JavaScript in the case of GWT).
4. Run in something other than a JVM (DOM with JavaScript in the case of GWT).

GWT has been out in the wild for some time now and Sun doesn't seem to care.

headline is kind of cool

[JeanBaptiste]

A number which is 10 followed by 100 zeros in a cage match against a hydrogen fusion reactor which accounts for 99.8% of the mass of our solar system. The whole thing happened over a misunderstanding regarding a robot designed to have human features.

Re:headline is kind of cool

[game kid]

Sadly, they called off the cage match a day later. They agreed that fighting over Google's new android girlfriend was just silly.

Would've been fun to see James "The Java Guy" Gosling taking on the giant GMail server room.

it's a real issue

[m2943]

while over looking the fact that Sun has GPLed Java

Releasing software under the GPL wouldn't give Google patent rights, since Google is not basing their software on Sun's.

and that other groups have produced versions of Java with out getting sued

Quite to the contrary: all conforming Java implementations that have ever been produced are produced under license from Sun, and Sun has used legal threats to ensure that.

There are a bunch of non-conforming implementations where Sun has chosen not to press the issue yet, but that doesn't tell you that Sun doesn't have the patents or doesn't enforce them. And, if you look at USPTO, you'll see that Sun has dozens of Java-related patents, some of them on fundamental aspects of the platform like bytecode verification.

OTOH, I suspect Google was careful about this, and this is one of the reasons Google didn't use a standard JVM. In the end, all Android shares with Sun Java is a fairly generic programming language and some fairly generic core APIs.

Re:it's a real issue

[steve_l]

AFAIK, the sole patents are -as you point out- on mechanisms for bytecode verification. But there is no guarantee that google dont have a different solution to the problem.

To make life more complex, Sun are actually breaking their own Java Community Process rules by refusing to give apache access to the test kit for Java, so that the Harmony team can test their clean room implementation of the java 6 classes. Passing that TCK automatically grants patent rights, so by denying access to the test kit, sun are stopping Harmony declaring that it is an implementation of Java. (Note that Sun do offer access to the TCK for GPL-licensed open source Java runtimes that are mostly derived from Sun's own code; they dont want any other open source implementation to be called Java).

So: sun broke the contract with apache, but apache lack the lawyers to do anything about it. Now Sun may end up going up against intel and google. They'd be better of giving up the TCK to the harmony team, so that they can at least retain some control over what ships.

-steve

(apache member, but not involved in android, harmony or similar)

Re:it's a real issue

[m2943]

AFAIK, the sole patents are -as you point out- on mechanisms for bytecode verification

I wouldn't be sure those are the only ones; Sun has been quite busy patenting stuff around Java.

Dalvik source available?

[Anonymous Coward]

So has google released the source code to the Dalvik VM? Any links?

Re:Dalvik source available?

[Anonymous Coward]

They haven't released any of the Android SDK code, and don't plan to until late next year.

Don't forget Sun's largest customer segment

[AtariDatacenter]

Sun's biggest customer segment is the telco market.

Don't be so sure that Sun is willing to potentially work against them. If I had a wireless company or division, don't think for a second that I wouldn't pull weight with Sun to get them to put some heat on Android.

We dont want no showdown !!!

[unity100]

We want cooperation. at&t and the others are already trying to lay waste to telecommunication and internet. We have some alliance to stand against them.
Br. Cooperation instead of competition

Re:We dont want no showdown !!!

[squiggleslash]

There's no showdown. Sun supports Android and has said so publicly, just read Sun's CEO's response. Personally I thought the author of the story was an idiot, he could have made his article so much more interesting and just as likely and accurate!

Android? Dalvik?

[PhotoGuy]

I'm not terribly out of the loop when it comes to development technology, but have never heard of Android (in this context) nor Dalvik. Come on, editors, would ensuring a four or five word summary of what the heck these are, really be that hard to enhance the article, and avoid a few wikipedia lookups to simply read the news???

Thanks...

J2ME vs Android... lets get them to fight!

[Anonymous Coward]

Yeah sun's J2ME is great but the average phone can only use about 40k of RAM.

Android seems like the next step and if they release a phone with a keyboard... why would I need to program for anything else.

Sun, why don't you enforce J2ME carriers to access all the RAM of the phone? Then you can stay competitve without suing.

A bigger story - BSD libc + Linux

[btarval]

Well, I wouldn't quite say that it's a non-story. But IMHO there's a bigger story which has been missed. Namely, that Google decided to take a BSD-derived libc and include it as a part of their Android effort. This is running on top of Linux.

This is a blow aimed squarely at the Free Software Foundation, and RMS's efforts to establish GPLv3. Good luck in trying to square that one away.

Now, why in the world Google would do this is beyond me. IHMO it smacks of too much money, and too many engineers with not enough relevant things to do. But hey, if Google's goal is to try to minimize both versions of the GPL, well, I can think of no better effort.

Re:A bigger story - BSD libc + Linux

[BrainInAJar]

And this is precisely why, when Sun GPL'ed Java my response wasn't "yay, open source java", it was "Why on earth didn't they go CDDL?"

CDDL allowed people like FreeBSD and Apple to use the cool technology in OpenSolaris like ZFS & DTrace. It's a happy-fun-sharing license. GPL won't let you play nice with the other children.

I was wondering how long it'd take for someone to decide the risks of GPL just weren't worth it, and create their own JVM

Re:A bigger story - BSD libc + Linux

[DavidNWelton]

No, it was aimed squarely at having a smaller libc than glibc, according to the google guy who was hanging out on #android. It is an "embedded device" with space constraints, you know!

Re:A bigger story - BSD libc + Linux

[PipsqueakOnAP133]

Square that? Many of us don't need to.

I'm a total fan of open source projects. Except I don't like the GPL. I consider it too restrictive because realistically, I need to be able to work with different licenses and closed source projects.

If I make something derived from a GPL'd library, then yes, I'll GPL it only out of compliance.

But if I had a choice, my public works would be BSD-style because I'll put my money where my mouth is and share.

Re:A bigger story - BSD libc + Linux

[wolftone]

CDDL allowed people like FreeBSD and Apple to use the cool technology in OpenSolaris like ZFS & DTrace. It's a happy-fun-sharing license. GPL won't let you play nice with the other children. Um, no, not quite. CDDL allows FreeBSD and Apple to use things like ZFS and DTrace with very similar freedoms -- and responsibilities -- to the GPL. It is almost the same sort of happy-fun-sharing license as the GPL. The essential difference is not a matter of the "viral clause" because they both have it. The difference lies in the fact that CDDL insists on certain things regarding patents; and being a different license than the GPL, it's a sticky point to mix the two on the same system.

In short, CDDL and GPL let you play almost exactly as nicely with the other children... just not with each other.

Re:A bigger story - BSD libc + Linux

[BrainInAJar]

Incorrect.

CDDL has a viral clause wit a very limited scope. That is, it is limited to the file, rather than GPL's "product".

There is nothing in the CDDL that prohibits the use of GPL code ( or the use of CDDL code in a GPL project ), other than you cannot change the license. Since the GPL wants you to change the license ( to the GPL ), this is where the fundamental difference is.

So yes, it's the GPL that doesn't let you play with other children... it wants everyone to be GPL or BSD

Re:A bigger story - BSD libc + Linux

[drinkypoo]

This is a blow aimed squarely at the Free Software Foundation, and RMS's efforts to establish GPLv3. Good luck in trying to square that one away.

Not really. The GPL doesn't disallow that kind of behavior for a reason - because part of the idea of the GPL is to permit interoperability. If that were against the spirit of the GPL, it would be explicitly disallowed. But that would also mean that the GPL was unnecessarily restrictive of choice, and it would not be as popular as it is today.

The point of the GPL is NOT to force all software to be GPL. It's coercion, maybe, but not force. You have a choice - you can write that software all yourself, or you can choose to go GPL and be able to use all that GPL code.

You might note that there is no reason you can't have a complete BSD userland on top of a Linux kernel, or vice versa, although substantial port work would have to be done to get the whole thing there, probably. Linux has some BSD-like structures to make that sort of thing easier already...

Re:A bigger story - BSD libc + Linux

[HiThere]

This is technically almost correct...but only because the GPL was there before the CDDL was. Were the time order reversed you could make the exact same argument about the CDDL.

OTOH, the CDDL, as I remember it (not certain...I haven't kept up with Sun's license versions) had special advantages for the company that originated the software (or perhaps just for Sun). But this might have been an earlier license, or an earlier version of the CDDL. (The one I'm remembering was based off the MPL. I looked it over and decided that:
a) It's not *THAT* bad. If I *must* use it I can, but I'm sure going to try to avoid it.
b) I can avoid it, so I will.

For me one of the real advantages of the GPL is that I know what the license means without having to buy a lawyer. Buying a lawyer is a large overhead expense. If you already have one on staff, I can see why you might have different accounting rules...you don't have the same expense structure. So I have generally preferred to only use OSI approved licenses. With their recent changes, however, I guess I'll have to switch to only using licenses that they approved before 2005 (a bit of slack for safety and ease of memory) or which have been approved by the FSF. I'm not doctrinaire the way the FSF is, but so far they've been a trustworthy, if a bit over restrictive, guide.

OTOH, I'm trying to remember back to that old Sun license based around the MPL. They deleted a paragraph that seemed pretty important, and since I decided I could avoid the license, I don't remember exactly what it said, but it was about patents. All-in-all I think I trust the GPL (both versions 2 & 3) more than I trust the CDDL. IANAL, and perhaps that's why, but it's also the case that I read the licenses, and *THAT* may be why.

Re:A bigger story - BSD libc + Linux

[BrainInAJar]

"the real advantages of the GPL is that I know what the license means without having to buy a lawyer."

Really? Can you dynamically link to a GPL library with non-GPL code?

are you sure? 100% sure?

"I don't remember exactly what it said, but it was about patents."

The CDDL explicitly grants you immunity from patents. the license says that they cannot sue you for infringing on any patents contained within the CDDL code, and if anyone's going to be sued for patents, it's Sun ( so if you extend OpenSolaris, for example, assuming you don't add any new patent infringements, you can't be sued by anyone for redistributing it. ie: you add some non-patent-infringing code to the kernel, redistribute it as $YOU-laris... NetApp can't sue you for infringing on their WAFL file system )

Re:A bigger story - BSD libc + Linux

[HiThere]

That sounds like the explanation they gave at the time.

I read the original license, read their changes, and wasn't satisfied. But I didn't need to use that license, so I didn't ask a lawyer.

As for your question "Can you dynamically link to a GPL library with non-GPL code?", I try to avoid getting NEAR to the edges of legal agreements. If I had to do what you are suggesting, I'd either contact the licensor, and get their explicit approval, or get a lawyer and get HIS explict approval. So far I've never needed to investigate that disagreement (and I'm aware that many non-lawyers are in disagreement over this particular detail...so I count that as a part of what I know about the license).

Re:A bigger story - BSD libc + Linux

[serge587]

I don't know how relevant the argument for space constraints is anymore when it comes to modern mobile devices. Seems to me like an outdated (and convenient) piece rhetoric to be thrown around. A few megabytes seem trivial when you're talking about multi-GB storage capacities.

That's only my perception though.

Re:A bigger story - BSD libc + Linux

[Anonymous Coward]

Good, then I'll take your BSD-licensed stuff, rename it, and sell it. And you don't get anything in return, not the money nor the code.

Fair?

No.

GPL is good because it enforces people to play nice. If it were not so, GPL-software would be just another resource to wildly rape and exploit without giving anything in return.

Re:A bigger story - BSD libc + Linux

[LWATCDR]

"This is a blow aimed squarely at the Free Software Foundation, and RMS's efforts to establish GPLv3. Good luck in trying to square that one away."
You mean the version of GPL that has the anti-tivo clause in it. Gee I wonder why Google wouldn't want to use that...
BSD LIBC has been used in Linux before. Several commercial Linux programs have used bsd libc so they could statically link it with their software. lgpl doesn't allow this. It allowed the the commercial software companies to create executables that just worked with out having to make their software FOSS.
I am just waiting for GPL V3.1 where the FSF will make it illegal to link a programed compiled with a GPL compiler to a none GPL libc.

Re:A bigger story - BSD libc + Linux

[AceJohnny]

A few megabytes seem trivial when you're talking about multi-GB storage capacities. We're talking "RAM" here. Oh, and no swap space.

Yes, in this field, "minimizing the memory footprint" is very important.

Re:Android? Dalvik?

[Anonymous Coward]

You haven't heard of Android? Sorry mate, but you are out of the loop. Android

Summary of the story

[Ed Avis]

There could be trouble between Google and Sun, according to someone. Google's Dalvik has advantages, according to some people, but it also has disadvantages. According to a developer not working for Google or Sun, it is possible that Google didn't pick Dalvik for technical reasons, although we don't know. There could be trouble for Google, say some people, because of 'intellectual property' Google may or may not have used, although we don't know what that 'intellectual property' might be. Stefano Mazzocchi says he doesn't know what Sun would do, but he is curious. Nobody working for Google would comment. Nobody working for Sun would comment.

Next week: why some people say that Microsoft could be in unexpected difficulties if it launches its own Linux distribution, which many observers have seen as likely, although others disagree.

Dalvik is really a a

[shareme]

Folks I already covered this.. Dalvik is an emulator VM as on OHA devices the esmertec JVM is deployed which as a Sun IP license held by esmertec. Google can get around Sun's IP as long as it does not claim the Dalvik emulator VM is not java or the java platform. Although, yo9u have to consider it a major goof on Google's part as esmertec does in fact have a JVM emulator and there also exists emulators that are full foss such as microemulator. Major goof in having th issue muddied as there is no conflict with Sun IP as long as Google does not claim that Dalvik is java and most j2m MIDP emulator interfaces have been open source by Sun as in UEI for example. When you want answers as a mobile expert Fred Grott Mobile expert http://www.jroller.com/shareme

Thank you!

[Gary W. Longsine]

Just when i was wondering why the hell I was still slogging through the comments for this article, I found yours. You made the entire 90 seconds worth while.

Dalvik is _not_ Open Source

[Hugo Graffiti]

Sun is a staunch advocate for open source, so it would hardly appease the open source community to sue Google over an open source software stack

The Dalvik VM is not open source. Not only is it not open source, there has not even been a spec published for the Virtual Machine. Which is handy for the mobile phone companies because they can place their proprietary code inside the Dalvik VM and thus control the way the APIs are used. (Because you can only access them from Java code).

Java isn't /really/ GPL'd

[Anonymous Coward]

It would seem as if no none has actually bothered to read the license that Sun is using. Please note at the bottom: ""CLASSPATH" EXCEPTION TO THE GPL". That is the whole thing which is brewing here. Now check out the Java ME license and you'll see what this is all about.

Re:w00t!

[KeefP]

Are these first posts automatically added by slashdot when the story is posted?

Sun Digs Android

[ThePhin]

At least, that's what Jonathan Schwarz says in his weblog post on the topic.

Hold on.

[ToasterMonkey]

The unresponsive Gui (see zend framework) often makes people think that Java is slow. Unresponsive is slow. I understand your argument that GUI unresponsiveness makes an application "slow", but he means that bad GUI programming leads people to think the entire language/platform is slow by nature, which is untrue.

Lack of progress bars in an application doesn't make Java slow, for example.

Microsoft re-implemented it

[infonography]

Well know when they are involved when it gets on stage and dances Like this or tosses chairs in boardrooms.

Warning not safe for stomach.

Has anybody noticed a connection...?

[Anonymous Coward]

A little something from last year... a connection folks might have overlooked: Google CEO Dr. Eric Schmidt Joins Apple's Board of Directors...

Quite frankly, it appears that Google together with Apple might have PWND Sun/Java. And they both benefit because with Java weakened by fragmentation and the incompatibilities it would cause the market would continue to be divided into silos where people are forced to pay money for platforms that lock them in.