The ground is shaking beneath Java

The ground is shaking beneath Java on two ends. On one end is Android, on the other X10.

As previously discussed, I'm attracted to the Harmony implementation of Java because of its Apache licensing. Android fits into this strategy nicely as it incorporates much of Harmony. Openness wins. Distributed computing and onerous licensing are inimical. Android has been released under the Apache v.2 license.

As the world moves towards multi-core, IBM's experimental concurrent programming language X10, an offshoot of Java (shy generics for now^[1]), is poised for action. According to Vijay Saraswat's Report on the Experimental Language X10, Version 1.1, June 30, 2007,

X10 may be thought of as (generic) Java less concurrency, arrays and built-in types, plus places, activities, clocks, (distributed, multi-dimensional) arrays and value types. All these changes are motivated by the desire to use the new language for high-end, high-performance, high-productivity computing.

X10 is licensed under the Eclipse Public License 1.0.

Licensing, that's a go.^[2] Java-based security. Shall we assume that's a go?^[3] Now it's time to delve in.

I'm sure Java will come out of all this tumult strengthened, though perhaps reincarnated.

Names

I hope both of these movers and shakers do come up with better names. Android?? It's a bit embarrassing to put on your resume, like Groovy. And the name X10 makes it difficult to do Google searches due to the ubiquitous information about that other X10.

Notes

1. ↑ Generics, that revolution with which Java shook itself, is expected anytime soon in X10's next release. Android includes generics.
2. ↑ Maybe not. See the 4th bullet in the update and errata section at the end of Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME.
3. ↑ Maybe not completely with Android, but perhaps enough for working with distributed code.

Update (Nov 26, 2007): Interesting post on Android, OSGi, and classloading - OSGi on Google Android using Apache Felix

Java and the dangers of GPL

Don't get me wrong. I am a GPL fan in spirit when it's combined with a linking exception. Initially I applauded Sun's choice for Java's open-source license. I am also grateful for the monumental efforts of Richard Stallman and Eben Moglen in helping move the world of software forward. However, GPL version 3, released two months ago, suffers from 2 flaws, fatal flaws, fatal not only to the healthy evolution of GPL but also to that of Java.

Flaw #1 - The anti-tivoization clause for consumer hardware is a limitation inimical to free software. I agree with Linus Torvalds that this clause is a critical mistake. I may write about this in more detail later, but for now, consider only how this stunts development of security for distributed applications. My objection is not merely practical. My objection is in principle. Freedom in bits, freedom in property, no control over how I use bits in my own property or how others use them in theirs, that's where this world is heading. Dictating what I can or can't do with the software in certain hardware smells of controlliness (yes, that's a word I just made up, but I bet you know what I mean), inimical to the type of flexibility we need to move this world ahead... fast.

Flaw #2 - Here's the clincher, a flaw that even shows a high degree of, dare I say, hypocrisy (Torvalds dared). The license itself is not open to changes. You will be punished if you use a license with flaw #1 corrected. Richard Stallman and Eben Moglen will not let you fork it. I was shocked to find this out. No free-software heretics welcome. You're locked in for the ride no matter how arbitrary the car driver. This is the GPL trap. (See the video below.)

What to do? Sun currently licenses Java under GPLv2 with the linking exception. I do hope that Sun adds another open-source license for Java and does not merely move to GPLv3 unthinkingly. I also hope that the Creative Commons adds another open-source software license to its repertoire. In the meantime, I'll continue to use Java as is, but I'll be keeping my eye on Apache Harmony, though it's currently lacking a Mac version. In the grid world to come, the freedom to securely ensure that software be accountable is essential, no matter where it runs.

I find it sad since I find exciting value in the GPLv3 apart from these 2 dissuasive defects.

Here is an excellent, informative presentation on GPLv3 given by Sapna Kumar in June to the Triangle Linux Users Group. According to Kumar (1:13:03), Stallman will not let you modify the GPL license on your own even if you call it by another name. The Free Software Foundation enforces this through copyright.

Newton Discovery

I've discovered Newton, and now Newton's downloading on my Apple.

Newton uses OSGi for local components and Jini for remote components, combining them both into a distributed component framework, with some SCA thrown in for good measure to describe how to assemble the components all together.

A good starting point to learn about Newton is The Newton Component Model.

Newton is available under a GPL or commercial license.

Here's a presentation on Newton from the 10th Jini Community Meeting last year.

Hat tip: Fun with OSGi

See also: OSGi in a dynamic service grid