Harmony
From APIDesign
(→JDK9) |
|||
| (3 intermediate revisions not shown.) | |||
| Line 7: | Line 7: | ||
The project had to be very careful who to hire. Anyone who might have seen a line of original [[Sun]]'s [[Java]] implementation (even if it was not open source, there was a ''src.zip'' in the [[JDK]] root directory) had to be ruled out. | The project had to be very careful who to hire. Anyone who might have seen a line of original [[Sun]]'s [[Java]] implementation (even if it was not open source, there was a ''src.zip'' in the [[JDK]] root directory) had to be ruled out. | ||
| - | Another problem was to verify whether the implementation is or is not compliant? The usual style is to run a [[TCK]] - however the [[TCK]] was not [[open source]] either and [[Sun]] wanted a payment for access to the official [[TCK]]. [[Apache]] Foundation rejected to pay anything (which at the end resulted in them stepping out of [[JCP]] committee years later). Rather than that they wrote a set of tests from scratch (based on reading the official [[API]] [[Javadoc]]) and they run them on both [[Java] implementations [[Harmony]] and [[Sun]]'s [[Java]]. Whenever the test results diverged, they fixed [[Harmony]] ([[chapter 15]] discusses this testing approach more deeply and shows how powerful it can be if mixed with [[RandomizedTests]]). | + | Another problem was to verify whether the implementation is or is not compliant? The usual style is to run a [[TCK]] - however the [[TCK]] was not [[open source]] either and [[Sun]] wanted a payment for access to the official [[TCK]]. [[Apache]] Foundation rejected to pay anything (which at the end resulted in them stepping out of [[JCP]] committee years later). Rather than that they wrote a set of tests from scratch (based on reading the official [[API]] [[Javadoc]]) and they run them on both [[Java]] implementations [[Harmony]] and [[Sun]]'s [[Java]]. Whenever the test results diverged, they fixed [[Harmony]] ([[chapter 15]] discusses this testing approach more deeply and shows how powerful it can be if mixed with [[RandomizedTests]]). |
But of course, when there is enough tests? Never. So certain parts of the [[Harmony]] implementation diverged a lot from the original as they there was really much less tests than necessary and even the original documentation was more than poor (like in case of [[Swing]]). | But of course, when there is enough tests? Never. So certain parts of the [[Harmony]] implementation diverged a lot from the original as they there was really much less tests than necessary and even the original documentation was more than poor (like in case of [[Swing]]). | ||
| Line 15: | Line 15: | ||
=== Fragmentation of [[Java]] === | === Fragmentation of [[Java]] === | ||
| - | Since the early days of [[Java]] [[Sun]] was afraid of fragmentation of [[Java]] (and fought hard against [[Microsoft]] to prevent that) and [[Harmony]] was | + | Since the early days of [[Java]] [[Sun]] was afraid of fragmentation of [[Java]] (and fought hard against [[Microsoft]] to prevent that) and [[Harmony]] was going to do exactly that. To remain in control [[Java]] [[Sun]] took its last chance and finally decided to create an [[OpenJDK]] project - its own open source version of [[Java]]. The start was not fast, but slowly other vendors ([[IBM]] and [[Apple]]) got convinced to contribute to [[OpenJDK]] rather than [[Harmony]] (which [[IBM]] originally supported significantly). After [[IBM]] left [[Harmony]], the project vanished. The unity was here again and the fragmentation was gone... |
...up until [[Google]] came with [[Android]] (based on some fork of [[Harmony]]) and made its [[Dalvik]] [[VM]] the most successful mobile operating system. So successful that [[Android]] almost became synonym for [[Java]] (ask [[Android]] developers whether they speak [[Java]] and they will say yes, even it is not de-jure true). | ...up until [[Google]] came with [[Android]] (based on some fork of [[Harmony]]) and made its [[Dalvik]] [[VM]] the most successful mobile operating system. So successful that [[Android]] almost became synonym for [[Java]] (ask [[Android]] developers whether they speak [[Java]] and they will say yes, even it is not de-jure true). | ||
| Line 26: | Line 26: | ||
Is that the long awaited happy end? Does not it arrives a bit too late? | Is that the long awaited happy end? Does not it arrives a bit too late? | ||
| + | |||
| + | === [[JDK]]9: [[Jigsaw]] === | ||
| + | |||
| + | 2017 update: The [[JDK]]8 profiles came and went on almost unnoticed. [[I]] am not aware of much/any developers that would have actively changed their libraries to match [[JDK]]8 profile 1, etc. However this year it seems that [[Jigsaw]] is coming and the stress to re-target libraries to run with ''java.base'' slimmed down [[JDK]] may appear again. At least the [[Graal]] compiler project needs that and [[I]] spent last few weeks fighting with various problems including our use of [[PropertyChangeListener]]. | ||
Current revision
Harmony is second (after GNU Classpath) major re-implementation of Java libraries. These days it does not seem to be actively developed in spite of being used as a base for Android APIs.
Contents |
Incomplete and Mostly Wrong History of Open source Java Implementations
There was a strong push to make Java open source which Sun was rejecting for a long time. As a result Apache's Harmony project was established. Its goal was to write a compliant implementation of Java from scratch under the Apache open source license.
The project had to be very careful who to hire. Anyone who might have seen a line of original Sun's Java implementation (even if it was not open source, there was a src.zip in the JDK root directory) had to be ruled out.
Another problem was to verify whether the implementation is or is not compliant? The usual style is to run a TCK - however the TCK was not open source either and Sun wanted a payment for access to the official TCK. Apache Foundation rejected to pay anything (which at the end resulted in them stepping out of JCP committee years later). Rather than that they wrote a set of tests from scratch (based on reading the official API Javadoc) and they run them on both Java implementations Harmony and Sun's Java. Whenever the test results diverged, they fixed Harmony (chapter 15 discusses this testing approach more deeply and shows how powerful it can be if mixed with RandomizedTests).
But of course, when there is enough tests? Never. So certain parts of the Harmony implementation diverged a lot from the original as they there was really much less tests than necessary and even the original documentation was more than poor (like in case of Swing).
Clearly re-implementing something as huge as whole JRE was behind capabilities of anyone. The biggest success of Harmony (prior to become a base for Android) was the ability to launch Eclipse (due to its distinctive refusal of Swing and usage of own proprietary, but open source SWT).
Fragmentation of Java
Since the early days of Java Sun was afraid of fragmentation of Java (and fought hard against Microsoft to prevent that) and Harmony was going to do exactly that. To remain in control Java Sun took its last chance and finally decided to create an OpenJDK project - its own open source version of Java. The start was not fast, but slowly other vendors (IBM and Apple) got convinced to contribute to OpenJDK rather than Harmony (which IBM originally supported significantly). After IBM left Harmony, the project vanished. The unity was here again and the fragmentation was gone...
...up until Google came with Android (based on some fork of Harmony) and made its Dalvik VM the most successful mobile operating system. So successful that Android almost became synonym for Java (ask Android developers whether they speak Java and they will say yes, even it is not de-jure true).
There was the lawsuit after Oracle's acquisition of Sun in which Google defended Android successfully. Looks like legal actions are not going to prevent fragmentation. But as fragmentation is real and hurts developers a lot, why not take a technical action to fight with it?
JDK8 Profiles: The end of fragmentation
After a long struggle it seems that the fragmentation may be gone with JDK8 (plus if we wait two or three years more). JDK8 is going to come up with profiles and the smallest one does not include Swing, neither CORBA, neither bloated XML parser and other crap which made Java so heavy weight (instead of modular) over the years. The smallest profile consists of about three thousand classes. That is something that can be re-implemented. But even better - it is something that can be re-used! As such I'd expect that in future the compact1 profile will be the Common Ground that will unify various Java-like solutions and let them become real Java and prevent fragmentation forever.
Is that the long awaited happy end? Does not it arrives a bit too late?
JDK9: Jigsaw
2017 update: The JDK8 profiles came and went on almost unnoticed. I am not aware of much/any developers that would have actively changed their libraries to match JDK8 profile 1, etc. However this year it seems that Jigsaw is coming and the stress to re-target libraries to run with java.base slimmed down JDK may appear again. At least the Graal compiler project needs that and I spent last few weeks fighting with various problems including our use of PropertyChangeListener.
Follow
