> The runtime includes GPL classes which will force your application to GPL. Despite the Apache 2 license the project reports, do not use this unless you understand what adding GPL code to your application means. You are not subject to the classpath exemption when the code is bundled in your app.
If I package my Java app together with OpenJDK JRE then GPL code is bundled in my app and I can use "classpath exemption".
If I take OpenJDK JRE, fork it, make Retropiler out of it and publish it under "GPL plus classpath exception" and then package my Java app together with Retropiler then GPL code is bundled in my app - it is the same as above. Why I am not subject to the classpath exception in this case?
1) OpenJDK allows you to fork under a) GPLv2 or b) GPLv2 + Classpath Exception (see http://openjdk.java.net/legal/gplv2+ce.html, "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." where library=OpenJDK and exception=Classpath Exception).
3) Retropiler OpenJDK runtime is licensed under GPL only (see https://github.com/retropiler/retropiler, "The Java classes in runtime/ module which were copied from AOSP are licensed as GPL.")
They could fork OpenJDK and license it with classpath exception which would allow you to (statically or dynamically) bundle your app with OpenJDK under any license. But since they didn't include the classpath exception your app bundling parts of the Retropiler's OpenJDK fork must be under GPL! So you can use it only for open source projects...
At a guess, because you distributed the code. It is one thing for it to be in the platform and you are using it by virtue of another's actions. If it only works when you personally bundle and distribute the code...
Oracle sued Google for "stealing their java API specs" so they probably aren't touching the Android platform any time soon. However, there is a Java ME SDK that runs on constrained devices such as ARM phones. There is also an emulator called phoneME.
It is ironic how so many [1] JDK vendors were able to work together with Sun, now with Oracle, just Google seems to have some issues following the same rules and licenses.
Given that Java licensing seems to have been negotiated and was likely very different per company, the fact that some licensed versions exist doesn't actually give too much info. There are accounts of what happened when from the court filings though, and people have distilled that[1].
In any case, I hardly think prolonged failed business negotiations constitute failing to "do no evil".
Doing a business without the necessary licenses in place, forking the Java eco-system by creating an implementation that isn't able to run any random Java library due to partial implementation, is surely the contrary of "do no evil".
When Java 9 finally gets out, and looking forward to Java 10 roadmap, this situation is only going to get worse.
Everybody has rights to fork Java. Oracle gave those rights with OpenJDK under the GPL+classpath exception license. As long as you follow this license, you are free to do what ever you like with OpenJDK. Essentially it means you must stay GPL+classpath exception, but you can add/change/remove any part you like.
I also checked and there is no mobile restriction on the OpenJDK.
Are there any restrictions on what I can do with it?
OpenJDK is released under an well-known open-source licensing model, that places no restrictions on your
ability to run OpenJDK. Please check the legal section of the OpenJDK project site to understand the scope
of your rights and obligations.
The legal section contains the GNU General Public License, version 2, with the Classpath Exception.
So you're wrong. This also explains why Oracle went for the hail mary copyright claim on the SSO of those 37 Java API's - because it's all they had.
Well, it's not like they called it java. It was marketed as omer hung different, so it's not like you would expect all of Java to work when coding for it or for code targeting Android to work under a normal java implementation.
There are over 4600 references to MySQL in the MariaDB codebase. There are also 56 pages of search results in the MariaDB documentation that contain "MySQL". Is that also supposed to be funny?
Why didn't you post a link to all of the successful smartphones that used the JVM? Oh, that's right there aren't any and the ones that Oracle tried to make internally all failed.
Series 30 and Symbian smartphones were quite successful in Europe and already offered most of the features that american consumers think that were "invented" by Apple.
The S30 does support J2ME, but its successor, the S30+ completely abandoned J2ME and replaced it with MRE. As for Symbian, J2ME wasn't even the primary development platform - it was C++/Qt.
Also, court documents in the Oracle/Google trial also showed that Oracle tried to develop a Java smartphone and failed repeatedly because of their, and I quote from a internal Oracle presentation slide, "Very limited internal expertise to make smart decisions".
>How much Symbian development have you done? Many small companies were doing J2ME on Symbian as a way to write portable code across multiple devices.
None, but this doesn't change the fact that C++/Qt was the main development platform. I'd also wager that the C++/Qt apps were vastly superior to the J2ME apps.
>As for the Series 30+, the MRE was a market failure, never reaching a fraction of J2ME, Mediatek doesn't even support the SDK anymore.
Well, at least they're still making S30+ phones. The S30 stopped production in 2013.
So vastly superior that no mobile OS has been successfully with C++/QT on the market.
Symbian C++ alongside J2ME were vastly more used than C++/Qt ever was.
The adoption of C++/Qt was still being ramped up when the switch to Windows Phone 7 took place. Qt Mobility APIs were still work in progress just as an example.
Actually this angered many Symbian developers as they were still evaluating the transition to C++/Qt SDK when the news came out.
Fortran isn't dead. I'd bet money on there being more fortran programmers today than in the 70s, even if their slice of the programming language pie is proportionally much smaller.
Don't mistake other languages growing as another language being dead. Not all of computing is an exercise in following trends.
I don't quite understand what you mean because the entire class library is of OpenJDK since Android N. Sure desktop specific API's like Swing are missing and Android has its own API's for UI and stuff but all classes from standard Java are from OpenJDK in Android.
Before Android N they used to come from Apache Harmony and occasionally classes were borrowed from OpenJDK. But thats no longer the case since Android N.
Many methods don't have a full implementation, some classes have partial implementation and not every library class from OpenJDK is taken into Android.
I'm just confused as to why you think this is a problem? OpenJDK is an open source project and Google, or any other company, can fork it and trim as much undesirable fat as they wish. Additionally, as it has repeatedly been pointed out to you, Google does not call their fork Java not do they use any of the Java trademarks so your accusation that it fragments the language isn't true because it was never intended to be compatible with Java and the JVM. If Oracle has a problem with other companies forking OpenJDK then perhaps they should change the license for further releases or perhaps not make it "Open" anymore.
The difference, is that I don't live on Silicon Valley, I don't care about Google nor do I need to keep Android team happy to make a living.
What I care is that now I need to write two libraries instead of one.
Oracle (and Sun before) doesn't have a problem with companies that follow the license rules, there several commercial JDK vendors all of them nicely getting along with Oracle.
The Android SDK is a fork of the JDK. Did you expect them to rename every instance of the word "Java" to something else just for the sake of differentiation?
>What I care is that now I need to write two libraries instead of one.
I'm sure there are a plenty of libraries that work on either platform, but such is the nature of a fork. Support the platform you care about.
>Oracle (and Sun before) doesn't have a problem with companies that follow the license rules, there several commercial JDK vendors all of them nicely getting along with Oracle.
Google doesn't use the Oracle JDK they use the OpenJDK so why is a commercial license needed to use a forked version of an open source project?
"The successor of Dalvik is Android Runtime (ART), which uses the same bytecode and .dex files (but not .odex files), with the succession aiming at performance improvements transparent to the end users. The new runtime environment was included for the first time in Android 4.4 "KitKat" as a technology preview,[4][5] and replaced Dalvik entirely in later versions; Android 5.0 "Lollipop" is the first version in which ART is the only included runtime."
Dalvik is a Java runtime implementation (well technically not but let's keep things simple) just like OpenJDK's hotspot; It compiles bytecode to machine language which your device (PC, smartphone, etc.) can execute.
Bytecode is the thing the Java compiler produces (class files) from your Java source code.
Android N only switched to the Java API (base classes) of OpenJDK. As far as I know they didn't switch runtime environment.
(I know dalvik technically doesn't run bytecode but some other form of intermediary code optimized for mobile devices. I sidestepped that to keep things simple)
Oh jwz. Maybe we're the manchildren, but maybe it's the person who redirects all HN links to a picture of a hairy scrotum that hasn't in fact grown up yet.
The classpath exception is when the library is linked. Because Android DEXing involves converting all third party libraries to a single classes.dex file, this is contrary to most definitions of "linked". So using Retropiler will probably out you in violation of the GPL unless you can win in court saying that it is only linked.
Edit: technically dalvik and ART actually execute code from .odex and .oat files
One thing that might be possible but probably not easy is to force a multidex layout where all the Retropiler code is in a separate dex. I'm not sure how easy it is to force the build system to do this though.
That targets only Android 7 and above (and even then a subset of the features). If I understand correctly, this actually allows you to target any Android version at or above SDK 15 (Android 4.0.3), because it monkey patches your code to replace part of the standard library with external libraries. Then, when you decide to deprecate Android 6 support one day, you should be able to smoothly transition to fully native Java 8.
> The runtime includes GPL classes which will force your application to GPL. Despite the Apache 2 license the project reports, do not use this unless you understand what adding GPL code to your application means. You are not subject to the classpath exemption when the code is bundled in your app.
https://www.reddit.com/r/androiddev/comments/69rvf4/retropil...