Retropiler: Java 8 Standard Library Backport for Android | Hacker News Reader

Retropiler: Java 8 Standard Library Backport for Android

github.com

78 pointsgfx61 comments

Quoting u/JakeWharton on Reddit to here:

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

How is this not covered by the classpath exception?

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

Just a guess, though. IANAL and all of that.

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?

I checked again:

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

2) Android's OpenJDK fork is licensed under GPLv2 + Classpath Exception (see https://android.googlesource.com/platform/libcore/+/master/L...)

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

This is fixed now. The README now state GPL + Classpath Excemption

I think JakeWharton's point is right.

Issued: https://github.com/retropiler/retropiler/issues/6

Why aren't Java runtime environments install-able on Android like they are on almost any other operating system?

Because Android does not run a normal JVM.

Think you missed a "not" in there. =)

Oops, so I did. Thanks, added.

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.

Java ME has been dead for a solid decade.

Latest Java ME Embedded release is under a year old, supports Raspberry PI and STM IoT platforms etc: https://blogs.oracle.com/java/java-me-embedded-83-release

Yes, and there are sill new versions of Eiffel and Fortran coming out.

I meant dead practically, not literally.

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.

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.

But hey, lets fork Java and do no evil.

[1] - https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

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

1: http://www.pcworld.com/article/253666/a_timeline_of_oracles_...

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.

Better read it again, it does not apply to embedded systems, because Sun wanted to sell J2ME licenses.

You are talking about Oracle JDK and it's "field of use" restriction which prohibits usage on embedded systems (see http://www.oracle.com/technetwork/java/javase/terms/license/...). But I am talking about Open JDK which does not have this restriction (see http://openjdk.java.net/legal/gplv2+ce.html) and can therefore be used by Google for Android.

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.

Funny how the search results for Android documentation speak otherwise.

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?

Maybe, how compatible is MySQL SQL with MariaDB SQL?

They're compatible for the most part as MariaDB is supposed to be a drop in replacement for MySQL, but there is a list of incompatibilities.

https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibi...

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

> As for Symbian, J2ME wasn't even the primary development platform - it was C++/Qt.

How much Symbian development have you done?

I used to work for that little finish company.

Many small companies were doing J2ME on Symbian as a way to write portable code across multiple devices.

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.

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

It's possible, but somewhat unattractive due to JDK size and isolation from the native ART runtime I guess.

There seems to be a Java 9 OpenJDK Android port here: http://openjdk.java.net/projects/mobile/android.html

Since Android N the Java implementation is actually OpenJDK so I guess this is primarily useful to support older Android versions.

It doesn't use Dalvik anymore?

"Java is four things." - jwz

https://www.jwz.org/doc/java.html

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.

Could be! I still laugh every time i see that wrinkly breakfast, though.

> the person [..] that hasn't in fact grown up yet.

One of the greatest accomplishments an adult can achieve.

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)

They did change runtimes from Dalvik to ART, from Android L on.

Not since 5.0 (Lollipop).

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

https://en.m.wikipedia.org/wiki/Dalvik_(software)

The Dalvik runtime was replaced with ART in Android 5.

This is not 100% true, because the Android team cherry picks features from OpenJDK.

I advise anyone that actually cares about Java™, to spend some time reading AOSP commits regarding OpenJDK integration.

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.

Not it is not, as I said read the AOSP commits.

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.

Because Google has broken Java portability, I cannot just take a random Java library and have it work on Android.

Thanks to Google now I need to search for Android Java libraries, instead of Java libraries.

Funny every time I search for Java on https://developer.android.com/develop/index.html I get several hundred results, and yet Google doesn't call their fork Java, go figure.

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.

>Because Google has broken Java portability

Android was never intended to be used for Java portability so nothing has been broken.

>I cannot just take a random Java library and have it work on Android.

Android is not compatible with Java so why would you expect a random Java library, meant to work with Java, to work on Android?

>Thanks to Google now I need to search for Android Java libraries, instead of Java libraries.

A comprehensive list of libraries that work with Android has already been created so why would you need to look for Java libraries?

>Funny every time I search for Java on https://developer.android.com/develop/index.html I get several hundred results, and yet Google doesn't call their fork Java, go figure.

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?

Are there still open positions at the Android team?

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.

I thought the Android team is switching to native Java 8 support anyway?

https://android-developers.googleblog.com/2017/03/future-of-...

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.

According to this table: https://developer.android.com/studio/preview/features/java8-...

you can use Lambda expressions and Method References with any Android version... but without Java 8 libraries...

Kind of.

They are supporting Java 8 language features depending on the Android platform version.

Some Java 8 library APIs have been adopted, but require the latest Android versions.

Finally, the JVM bytecodes like invoke dynamic and method handles aren't supported thus making libraries that use them, unusable on Android devices.

Coming in O by the looks of it: https://source.android.com/devices/tech/dalvik/dalvik-byteco...

Yeah, given that Android N after one year is at 6%, ....

That is the nature of the beast except for retropiling. Method handles may be a hard set of features to implement on that path.

Reply on news.ycombinator.com