User: Password:
|
|
Subscribe / Log in / New account

Classpath Exception not included in the mobile edition

Classpath Exception not included in the mobile edition

Posted Aug 17, 2010 20:04 UTC (Tue) by nim-nim (subscriber, #34454)
In reply to: Classpath Exception not included in the mobile edition by SilverWave
Parent article: A very grumpy editor's thoughts on Oracle

Except that Dalvik is not JavaME. If it's close to something, that's JavaSE. Even Oracle wrote it before buying SUN
http://www.oracle.com/technetwork/database/berkeleydb/bdb...

(This, BTW, is one reason Android has rolled over JavaME phones: SUN let the JavaME cash cow rot at Java 1.3 level, while phone hardware improved, making the improvements of later Java versions interesting for mobile, and digging the competitive advantage trench Google would use later)

The *only* reason Android used Harmony as a base for Dalvik is the fundamental distrust of the Android team for anything GPL-ish. Remember that the core Android team came from Danger, which was quite happy to let itself acquire by Microsoft.

The fact that Android runs a Linux kernel despite this deep GPL distrust is quite a testament for the technical quality of the modern Linux kernel. Android certainly didn't swallow this GPL code pile with pleasure.


(Log in to post comments)

Classpath Exception not included in the mobile edition

Posted Aug 18, 2010 8:07 UTC (Wed) by dgm (subscriber, #49227) [Link]

I had the idea that the main reason behind chosing Harmony was that Google wanted to allow propietary development on Android, and that was not possible using OpenJDK class library, as it is GPL's (not LGPL'd).

Also, a pair of notes: Isn't JavaME in version 6, just like JavaSE?
And Harmony is not the base for Dalvik. Dalvik is the VM, Harmony a class library. As a result, Harmony is code that, together with application code, runs on Dalvik.

Classpath Exception not included in the mobile edition

Posted Aug 18, 2010 10:46 UTC (Wed) by paulj (subscriber, #341) [Link]

That's not true, OpenJDK is under a GPLv2 + "ClassPath Exception" licence. Here's the text of that exception:

"CLASSPATH" EXCEPTION TO THE GPL

Certain source files distributed by Sun Microsystems, Inc. are subject to the following clarification and special exception to the GPL, but only where Sun has expressly included in the particular source file's header the words "Sun designates this particular file as subject to the "Classpath" exception as provided by Sun in the LICENSE file that accompanied this code."

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

That exception makes it explicit that the ClassPath libraries so marked can be linked with other applications without affecting the licensing of the application.

The JavaME edition has some additional libraries, specific to mobiles obviously, which do NOT offer this exception - they're GPL only. Hence why many users of JavaME chose to get a proprietary licence from Sun. Google do not use those APIs anyway, AFAIK. I.e. it does seem that there were no licensing obstacles to Google using the OpenJDK, at least in terms of wanting to avoid applications having to be GPLed (Google might have started its Dalvik work while Sun were still in the process of GPLing the JDK - anyone remember the exact timeline?).

Given that Google generally went out of its way to avoid having any GPL code in Android, it seems that their motivation was simply to avoid being restricted in any way by copyleft. I wonder if that choice was made on a rational basis, or out of less rational, base GPL hatred/fear.

Classpath Exception not included in the mobile edition

Posted Aug 20, 2010 10:08 UTC (Fri) by dgm (subscriber, #49227) [Link]

But again, JavaME is NOT covered by that exception. Thus the only way for Google to stay in the clear would have been to use the _full_ JavaSE, not a subset.
With the emphasis put on leanness as shown in Dalvik design, I can guess this was just ruled out?

Classpath Exception not included in the mobile edition

Posted Aug 20, 2010 10:39 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

Again, your argument is defeated by the fact that what Google finally produced is a lot closer to JavaSE than JavaME (Harmony is a JavaSE not ME clone)

JavaME was written for the kind of phones the iPhone and Android stormed over: clunky, limited hardware where the software was an afterthought because the phone industry worried more about ringtones and MMS than about the user experience

It takes more than a ME moniker to define what's needed on a smartphone.

Classpath Exception not included in the mobile edition

Posted Aug 26, 2010 12:42 UTC (Thu) by willjcroz (guest, #62784) [Link]

AFAICT the use of JavaSE/Harmony libraries is complicated by the field of use restrictions issued by Sun for the OpenJDK JCK compliance test framework (required to 'comply' and get patent license). It's use on anything other than a standard computer on a desk is prohibited from what I have read.

See the open letter to Sun from Apache Harmony team:

http://www.apache.org/jcp/sunopenletter.html

and its related FAQ:

http://www.apache.org/jcp/sunopenletterfaq.html

From what I can find, Apache Harmony project's concerns have not been addressed. Unless you know otherwise, in which case please post details of how Sun addressed this.

Classpath Exception not included in the mobile edition

Posted Aug 27, 2010 11:41 UTC (Fri) by mjw (subscriber, #16740) [Link]

> AFAICT the use of JavaSE/Harmony libraries is complicated by the field of use restrictions issued by Sun for the OpenJDK JCK compliance test framework (required to 'comply' and get patent license). It's use on anything other than a standard computer on a desk is prohibited from what I have read.

There are no such field of use restrictions in the OpenJDK JCK:
http://openjdk.java.net/legal/openjdk-tck-license.pdf
There are lots of other problems with it though, primarily that it is proprietary and you need to sign a NDA to not discuss the results...

> From what I can find, Apache Harmony project's concerns have not been addressed.

The problem with their concerns is that they are unverifiable because they did the "negotiations" in secrecy without involving the bigger libre java community. They probably really got a bad deal, but it is hard to help out if they keep the details hidden: http://gnu.wildebeest.org/blog/mjw/2007/04/21/openjck/

Classpath Exception not included in the mobile edition

Posted Aug 20, 2010 11:32 UTC (Fri) by mjw (subscriber, #16740) [Link]

> But again, JavaME is NOT covered by that exception. Thus the only way for Google to stay in the clear would have been to use the _full_ JavaSE, not a subset.

You seem to be confusing the "specification" with the "implementation" and what Android/Dalvik actually supports.

The full GPL implementation that Oracle/Sun distributes is called PhoneME: https://phoneme.dev.java.net/ https://phoneme.dev.java.net/source/browse/phoneme/legal/

The OpenJDK implementation under GPL (+ exception) that they distribute is an implementation of JavaSE.

Some of the specified libraries overlap (although there are some subtle differences in behaviour) but neither is a full subset or superset of the other.

An example of usage of both PhoneME, OpenJDK and GNU Classpath, JamVM or Cacao derived implementations on embedded devices is the Bug: http://community.buglabs.net/kgilmer/posts/45-BUG-OpenJDK

Another example that blurs the lines between SE and ME (and happily combines code from various free implementations, PhoneME, OpenJDK, GNU Classpath, Cacao, etc.) is MIDPath http://midpath.thenesis.org/bin/view/Main/

Android/Dalvik resembles the Java SE variant the most. It doesn't reall resemble any java variant directly. But it doesn't include anything in ME that is not in SE. It can be seen as a subset of the SE libraries, with specific Android libraries added. The implementation is designed to run well on small devices, but isn't JavaME like.

Classpath Exception not included in the mobile edition

Posted Aug 22, 2010 5:00 UTC (Sun) by paulj (subscriber, #341) [Link]

It doesn't matter. Google are NOT using JavaME - they're using a subset of SE. So the OpenJDK GPL+CE implementation is there for their taking and should be acceptable - modulo the fact that Google don't seem to like the GPL much.

Classpath Exception not included in the mobile edition

Posted Aug 18, 2010 11:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

> Java ME started out as an effort to bring Java back to its original
> roots: as a language and environment for writing embedded applications.
> The baseline ME profiles are pretty bare; I did some CLDC development
> years ago and had to implement my own buffered streams and various data
> structures just to get by. Even the biggest profiles are still fairly
> restricted, and I don't believe any of them have ever graduated beyond
> Java 1.3-level featuresets. So Sun did a great job of getting Java ME on
> devices, back when people cared about Sun...and then they let mobile Java
> stagnate to a terrible degree while they spent all resources trying to
> get people to use Java EE and trying to get Java EE to suck less.

http://blog.headius.com/2010/08/my-thoughts-on-oracle-v-g...

> Android breaks new ground in the device category because it is a Java 2
> Standard Edition(J2SE) platform, whereas the previous generations of
> Java-based devices are predominantly Java Micro Edition (Java ME)
> based. There are significant differences between J2SE and Java ME in
> terms richness of libraries and APIs and this creates a big opportunity
>for improved application capabilities. Most notable are the
> full-featured Java 5 language support, libraries like java.util.* and
> collections, and full multi-threaded support built on the Android Linux
> kernel.

http://www.oracle.com/technetwork/database/berkeleydb/bdb...

> As of 2008, all Java ME platforms are currently restricted to JRE 1.3
> features and uses that version of the class file format (internally
> known as version 47.0). Should Sun ever declare a new round of Java ME
> configuration versions that support the later class file formats and
> language features, such as those corresponding JRE 1.5 or 1.6 (notably,
> generics), it will entail extra work on the part of all platform vendors
> to update their JREs.

https://secure.wikimedia.org/wikipedia/en/wiki/Java_Platf...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds