4 ms·

To be fair, Oracle released Java 7 and especially Java 8 with a bunch of goodies and improvements that increased productivity and brought new paradigms to the l

To be fair, Oracle released Java 7 and especially Java 8 with a bunch of goodies and improvements that increased productivity and brought new paradigms to the language in an elegant way (considering it's still Java). But Google already de-facto forked the language a long time ago for use in Android, so these improvements were nowhere to be found in Android for a long time. The mention of Jigsaw is a red herring. Jigsaw, after long years of design-by-committee, suddenly devolved into a proxy war between enterprise players invested in existing module solutions. It's not about making parts proprietary at all; rather, it's about protecting existing investments in modularization ecosystems, the kinds of which form an important part of several companies' business models, all interspersed with legitimate technical and practical concerns about how to be prescriptive without being overly restrictive. The concern whether parts of a Java implementation can be made proprietary doesn't depend on the Jigsaw question, because there are several Java implementations today that are proprietary in part or whole, ranging from mediocre to marvellous, and they still manage to attract clientele. However, I do agree that Kotlin is a signal to Oracle. It's a signal that Google has given the Android programming question, and the Java question a good amount of thought, and may have found a way to slowly transition off of a technology whose use literally resulted in them being sued, outcome notwithstanding; with Kotlin they can leverage compatibility with the lowest levels of the Java platform (and thus, all existing Java-coded Android code), give people a modern language that offers niceties and high productivity -- all courtesy of a partner whose interests align well with those of Google, and with whom they have cooperated before. With Kotlin, Android can migrate off of Java without throwing away their existing investment in the body of code that happens to run on Android today, and do so in a way that makes it likely that developers will migrate voluntarily, vs. being forced.

slackingoff2017 9y ago
The story is not as simple as it seems on the surface. Google used Apache Harmony which was discontinued because Oracle would not give Apache a TCK license. Without being able to run the Technology Compatibility Toolkit, Apache Harmony could not become a certified compatible Java implementation. This would greatly limit usage, so Apache pulled the plug on the project. Oracle killed Apache Harmony which is how Android got "stuck" at Java 6.
- knight17 9y ago
  I did not know that Android's 'stuck at Java 6' situation was due to the Apache Harmony project-Oracle scuffle. Statement by the ASF Board on our participation in the Java Community Process: > Through the JSPA, the agreement under which both Oracle and the ASF participate in the JCP, the ASF has been entitled to a license for the test kit for Java SE (the "TCK") that will allow the ASF to test and distribute a release of the Apache Harmony project under the Apache License. Oracle is violating their contractual obligation as set forth under the rules of the JCP by only offering a TCK license that imposes additional terms and conditions that are not compatible with open source or Free software licenses. The ASF believes that any specification lead that doesn't follow the JCP rules should not be able to participate as a member in good standing, and we have exercised our votes on JSRs -- our only real power on the JCP -- accordingly. We have voted against Sun starting and continuing JSRs, and have made it clear that we would vote against the JSR for Java SE 7 for these reasons. https://blogs.apache.org/foundation/entry/statement_by_the_asf_board1 https://blogs.apache.org/foundation/entry/statement_by_the_a...
- niftich 9y ago
  This saga goes back to Sun Microsystems and Apache Harmony. Harmony, as originally announced was to be an Apache 2.0 License cleanroom reimplementation of the Java platform, complete with the standard library and a VM [1]. There was a lot of confusion [2] going forward, because copyleft folks like GNU were working on Classpath, a similar project, under the GPLv2, and none of that code was license-compatible with the Apache License. This was one of the high-profile catalysts of the harmonization of open-source licenses that happened later, contributing to the future GPLv3. Harmony ran into plenty of other challenges, but despite the odds it managed to produce a working J2SE 5 implementation. It was speculated that Sun was theoretically okay with a copyleft open source Java, but not one that wasn't copyleft, like Harmony. Specifically, they laid out conditions in the license for the Java Compatibility Kit, the conformance test suite needing to be passed to claim that you're "Java", that disallowed certain "Field[s] of Use" i.e. natures of deployment [3][4]. The "Field of Use" restrictions that Sun has imposed restrict software certified with the TCK to "general computing devices" which would for instance restrict use on kiosks or mobile devices. [5] The Field of Use restrictions limiting J2SE 5 implementations to "General Purpose Computing Devices" and excluding special-case appliances, kiosks, mobile computing devices and other interesting applications constitutes an "additional restriction" that would be unacceptable to us (the ASF), and equally to the FSF (by the GPL's no-additional-restrictions policy). [6] Oracle initially supported Apache on the matter, but reversed their stance once they bought Sun [7]. Reading Sun's Field of Use restrictions heavily insinuates that covert, embedded, non-copyleft deployments -- like the future Android, a mishmash of old Harmony code, various other open source code, and closed source code -- are the exact kind of application they were hoping to curtail. Instead, Sun released OpenJDK under the copyleft GPLv2. [1] https://lwn.net/Articles/135111/ https://lwn.net/Articles/135111/ [2] https://lwn.net/Articles/184967/ https://lwn.net/Articles/184967/ [3] https://phys.org/news/2007-04-apache-harmony-sun.html https://phys.org/news/2007-04-apache-harmony-sun.html [4] http://blog.joda.org/2009/03/sun-apache-ip-in-pictures_9067.html http://blog.joda.org/2009/03/sun-apache-ip-in-pictures_9067.... [5] http://www.theserverside.com/news/thread.tss?thread_id=46094 http://www.theserverside.com/news/thread.tss?thread_id=46094 [6] http://mail-archives.apache.org/mod_mbox/www-jcp-open/200707.mbox/%3c468C1923.5000807@rowe-clan.net%3e http://mail-archives.apache.org/mod_mbox/www-jcp-open/200707... [7] https://arstechnica.com/information-technology/2010/11/apache-foundation-to-vote-down-java-7-protesting-oracle-abuses/ https://arstechnica.com/information-technology/2010/11/apach...
nurettin 9y ago
In the meanwhilr, I've veen using java 8 features on android fpr more than half a year by incorporating jack into the build system. Now this is incorporated by default and jack is no longer needed. So I'm perpetually surprised when people mention "stuck at java 6" on hn. Have you guys no first hand experience on the platform? Just chatting?
- pjmlp 9y ago
  Maybe because even with Android N, one cannot use all the official Java 8 API? And then since Android N is only 7% of the market, it means giving up on the stream libraries and the remaining features that are Android 7 only? Finally, because lambdas are implemented with inner classes instead of new JVM bytecodes like on the real thing, Java 8 code on Android will have a performance impact? And yes, there is also a lack of Android knowledge on HN, as many don't even know the restrictions the NDK has.
  - nurettin 9y ago
    You know you can use Android N (and later) and still target Android 19 and still use lambdas, right? Or did you mean something else? Maybe the developer page confused you. Can you clarify this for me? And yes, I know you can't use all features of java 8, but this isn't what the posts are on about. They just ignore all facts and go straight to "android is stuck at java 6" and nobody really challenges them on this belief. I guess neither will you.
    - pjmlp 9y ago
      I do have Android development experience, but I have more Java experience all the way back to the early JDK releases, including having read enough papers about several JVM implementations. The issue regarding lambdas has to do how they are implemented, by making use of inner classes instead of doing what Oracle has done in Hotspot and is being followed by most third party JVM implementations, meaning making use of invokedynamic infrastructure, thus being as if there was special bytecodes for lambdas. This allows for more performance and optimization opportunities, which are much harder to achieve with plain inner classes. Also those of us that like Java, always mean both the language and platform when talking about Java. The current situation is that now we need to write Android specific libraries instead of being able to pick any random Java 7 or 8 library and use it on Android applications, without any change.
needusername 9y ago
To be fair, jlink is entirely proprietary and intentionally unspecified.

slackingoff2017 9y ago

The story is not as simple as it seems on the surface. Google used Apache Harmony which was discontinued because Oracle would not give Apache a TCK license. Without being able to run the Technology Compatibility Toolkit, Apache Harmony could not become a certified compatible Java implementation. This would greatly limit usage, so Apache pulled the plug on the project. Oracle killed Apache Harmony which is how Android got "stuck" at Java 6.

knight17 9y ago
I did not know that Android's 'stuck at Java 6' situation was due to the Apache Harmony project-Oracle scuffle. Statement by the ASF Board on our participation in the Java Community Process: > Through the JSPA, the agreement under which both Oracle and the ASF participate in the JCP, the ASF has been entitled to a license for the test kit for Java SE (the "TCK") that will allow the ASF to test and distribute a release of the Apache Harmony project under the Apache License. Oracle is violating their contractual obligation as set forth under the rules of the JCP by only offering a TCK license that imposes additional terms and conditions that are not compatible with open source or Free software licenses. The ASF believes that any specification lead that doesn't follow the JCP rules should not be able to participate as a member in good standing, and we have exercised our votes on JSRs -- our only real power on the JCP -- accordingly. We have voted against Sun starting and continuing JSRs, and have made it clear that we would vote against the JSR for Java SE 7 for these reasons. https://blogs.apache.org/foundation/entry/statement_by_the_asf_board1 https://blogs.apache.org/foundation/entry/statement_by_the_a...
niftich 9y ago
This saga goes back to Sun Microsystems and Apache Harmony. Harmony, as originally announced was to be an Apache 2.0 License cleanroom reimplementation of the Java platform, complete with the standard library and a VM [1]. There was a lot of confusion [2] going forward, because copyleft folks like GNU were working on Classpath, a similar project, under the GPLv2, and none of that code was license-compatible with the Apache License. This was one of the high-profile catalysts of the harmonization of open-source licenses that happened later, contributing to the future GPLv3. Harmony ran into plenty of other challenges, but despite the odds it managed to produce a working J2SE 5 implementation. It was speculated that Sun was theoretically okay with a copyleft open source Java, but not one that wasn't copyleft, like Harmony. Specifically, they laid out conditions in the license for the Java Compatibility Kit, the conformance test suite needing to be passed to claim that you're "Java", that disallowed certain "Field[s] of Use" i.e. natures of deployment [3][4]. The "Field of Use" restrictions that Sun has imposed restrict software certified with the TCK to "general computing devices" which would for instance restrict use on kiosks or mobile devices. [5] The Field of Use restrictions limiting J2SE 5 implementations to "General Purpose Computing Devices" and excluding special-case appliances, kiosks, mobile computing devices and other interesting applications constitutes an "additional restriction" that would be unacceptable to us (the ASF), and equally to the FSF (by the GPL's no-additional-restrictions policy). [6] Oracle initially supported Apache on the matter, but reversed their stance once they bought Sun [7]. Reading Sun's Field of Use restrictions heavily insinuates that covert, embedded, non-copyleft deployments -- like the future Android, a mishmash of old Harmony code, various other open source code, and closed source code -- are the exact kind of application they were hoping to curtail. Instead, Sun released OpenJDK under the copyleft GPLv2. [1] https://lwn.net/Articles/135111/ https://lwn.net/Articles/135111/ [2] https://lwn.net/Articles/184967/ https://lwn.net/Articles/184967/ [3] https://phys.org/news/2007-04-apache-harmony-sun.html https://phys.org/news/2007-04-apache-harmony-sun.html [4] http://blog.joda.org/2009/03/sun-apache-ip-in-pictures_9067.html http://blog.joda.org/2009/03/sun-apache-ip-in-pictures_9067.... [5] http://www.theserverside.com/news/thread.tss?thread_id=46094 http://www.theserverside.com/news/thread.tss?thread_id=46094 [6] http://mail-archives.apache.org/mod_mbox/www-jcp-open/200707.mbox/%3c468C1923.5000807@rowe-clan.net%3e http://mail-archives.apache.org/mod_mbox/www-jcp-open/200707... [7] https://arstechnica.com/information-technology/2010/11/apache-foundation-to-vote-down-java-7-protesting-oracle-abuses/ https://arstechnica.com/information-technology/2010/11/apach...

nurettin 9y ago

In the meanwhilr, I've veen using java 8 features on android fpr more than half a year by incorporating jack into the build system. Now this is incorporated by default and jack is no longer needed. So I'm perpetually surprised when people mention "stuck at java 6" on hn. Have you guys no first hand experience on the platform? Just chatting?

pjmlp 9y ago
Maybe because even with Android N, one cannot use all the official Java 8 API? And then since Android N is only 7% of the market, it means giving up on the stream libraries and the remaining features that are Android 7 only? Finally, because lambdas are implemented with inner classes instead of new JVM bytecodes like on the real thing, Java 8 code on Android will have a performance impact? And yes, there is also a lack of Android knowledge on HN, as many don't even know the restrictions the NDK has.
- nurettin 9y ago
  You know you can use Android N (and later) and still target Android 19 and still use lambdas, right? Or did you mean something else? Maybe the developer page confused you. Can you clarify this for me? And yes, I know you can't use all features of java 8, but this isn't what the posts are on about. They just ignore all facts and go straight to "android is stuck at java 6" and nobody really challenges them on this belief. I guess neither will you.
  - pjmlp 9y ago
    I do have Android development experience, but I have more Java experience all the way back to the early JDK releases, including having read enough papers about several JVM implementations. The issue regarding lambdas has to do how they are implemented, by making use of inner classes instead of doing what Oracle has done in Hotspot and is being followed by most third party JVM implementations, meaning making use of invokedynamic infrastructure, thus being as if there was special bytecodes for lambdas. This allows for more performance and optimization opportunities, which are much harder to achieve with plain inner classes. Also those of us that like Java, always mean both the language and platform when talking about Java. The current situation is that now we need to write Android specific libraries instead of being able to pick any random Java 7 or 8 library and use it on Android applications, without any change.

needusername 9y ago

To be fair, jlink is entirely proprietary and intentionally unspecified.