| ←Older revision |
Revision as of 14:44, 12 August 2013 |
| Line 1: |
Line 1: |
| | [[wikipedia:Apache_Harmony|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]] [[API]]s. | | [[wikipedia:Apache_Harmony|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]] [[API]]s. |
| | + | |
| | + | == Incomplete and 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 resulting to 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? |
| | + | |
| | + | === [[JDK]]8 Profiles: The end of fragmentation === |
| | + | |
| | + | After a long struggle it seems that the fragmentation may be gone with [[JDK]]8 (plus if we wait two or three years more). [[JDK]]8 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 [[JDeveloper#Common Ground|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? |