JXTA/JXSE 2.7 is out, but what about the future?

The final release of JXTA/JXSE 2.7 finally came out in March 2011. Two releases in 9 months, this is epic considering JXTA's history.

The highlights of this release include:

• Multiple peers in the same JVM - Yes, this long awaited feature is now available. It is possible to run multiple peers in the same JVM. Although most engineers won't use that possibility in their applications, it is key to implementing JUnit tests.

• JUnit collocated tests - A set of JUnit collocated tests has been implemented, which is a huge improvement to guarantee Q&A. This has proven tremendously useful to make sure we did not introduce regressions when refactoring or implementing new code. Code coverage is not complete yet, but key features are.

• Continuous  Integration - A continuous integration system has been implemented via http://mikeci.com. For more information, send an email to the development list.

• HTTP2 - A new HTTP transport has been implemented. It is not compatible with the existing one, but it solves a key shutdown delay issue encountered with current HTTP implementation.

• Routes & hints suggestions - Hints have been removed from the code, as they proved useless and misleading in most cases. Nevertheless, there is still a possibility of making suggestions in the endpoint service for those who want to.

• JXTA Security Enhancements - An implementation of secured peergroups and communication between peers is now available, though it should be considered beta and experimental.

• OSGi - The introduction of OSGi in 2.6 is a mitigated success. The 2.7 release makes it easier/possible to run JXTA within OSGi. However, a 'clean' implementation would require a redesign of the JXTA API, which itself requires major refactoring of the code.

On the up side, JXTA can be now considered as a stable P2P framework with a TURN implementation of NAT traversal. On the down side, the idea of loading services on peers is IMHO FUBAR and should probably be abandoned. A clean-up of the JXTA protocol specifications is also necessary, including deprecations. The framework is being used in production successfully by some companies, but has not been battle tested on a large scale.

Around October/November 2010, Oracle officially announced it was withdrawing from the project, via its representative on the JXTA board. This was no real surprise for the community, since Sun Microsystems had progressively withdrawn from the project since 2008. JXTA board elections should have been organized by its member in July 2010, but they did not perform their duties. No one, really complained too. Legally, the Oracle/Sun representative is still in charge and Oracle owns the JXTA brand.

Following this announcement, the community voted to move to the Apache Software Foundation (ASF). Since Oracle would not transfer the brand name, we voted for a new name too: Chaupal. ASF required us to move to the Apache License 2.0 to clear out potential intellectual property issues; we are under Apache License 1.1. We made a request to Oracle's representative who answered that Oracle needed time to review it's Intellectual Property. It has been nearly 6 months now. No follow-up or answers, even after reminders were sent. An email was sent to Mr. Edward Screven for clarification, no answer.

Yes, this confirms that Oracle's support for Open Source and Open Standard's is strictly limited to that serving their interest (dare I say void?). Indifference and isolation rules. Cannibalizing the brand value of Open Source products (Kenai, OpenOffice, MySQL, unbreakable Linux...) they have not developed themselves and ostracizing those who have developed it, is not an issue. I guess it becomes a need when developing healthy and nurturing relationships is not an option.

May be "Preferring to solve problems, rather than manage their consequences (...)" means substituting wealth and appearance for substance, while consequences of feeling dry inside are not felt. You can observe the world and yourself from a distance as much as you want, instead of really participating to the party, it won't ever give you what the open source community produces for free.

Oracle, stop biting the hand that is feeding you. It is not food and it does not make you lovable.

Back to JXTA, I have decided to put an end to the leadership of the JXTA project under current circumstances. With a couple of community members, I have started the Chaupal project on Google Code. The objective is to create a new P2P framework from scratch with a clean code base and a sound architecture based on experience acquired with JXTA, while guaranteeing a 'true' application of the Open Source spirit.

If anyone wants to take over the JXTA leadership, tell it to the user mailing list.

P.S.: I almost forgot. The Practical JXTA II book is now available online for reading at Scribd. Those looking for some information about NAT traversal will be delighted by the new chapter covering this topic.

JXTA/JXSE 2.6 is out

After more than a year of hard work, JXSE 2.6, the Java implementation of the JXTA protocols, is finally out.

"Euh... what is JXTA again? Remind me? Ooooh yeah, that P2P Open Source project started by Sun Microsystems in 2001!!! I remember... super-hard to make work, somehow buggy, poor documentation. I couldn't understand the behavior under the hood. Had high hopes, gave it a try, finally gave up! Well, what's new with that?"

The 2.6 release has been an opportunity to start resorbing the huge technical debt accumulated in the code. We started by trimming tons of dead code and refactoring tons of other to make it more readable. There is still more to come. One sequential bit at-a-time.

That is not all:

OSGi

It is now possible to start the JXTA network as an OSGi bundle. The Apache Felix OSGi implementation has been integrated in JXSE as a dependency and can be used as the standard OSGi framework.

Task Manager

In order to reduce the consumption of threads and other resources, a single task manager object has been implemented to use a single thread group. Serious impact on performance. Can run 300 peergroups on a MAC smoothly.

Cache Manager

New implementations of the cache manager based on Apache Derby, H2 or Berkeley DB are now available. These can replace the current standard b-tree file system implementation. No more of those small files on your drive. Advertisement fetching is now much faster overall.

Configuration Objects

Easy to use configuration objects, based on the Properties Java class, are now available to set-up the NeworkManager. These can be easily saved and loaded from XML documents.

Connectivity Methods

A new set of monitoring methods between EDGE, RENDEZVOUS and RELAY has been implemented. Now, a peer can really know where it stands in the network.

New TCP Implementation

A new implementation of the TCP layer based on the NIO Netty has been implemented. The intention is to NOT re-invent the wheel any further and delegate what can be delegated to existing performing libraries.

Documentation

Finally, a long awaited relatively comprehensive documentation of what is happening 'under the hood' has been made available in the new Programmer's Guide. The code remains somewhat of a maze, but this time we have a map to dodge the Minotaur.

Maven

And last but not least, we are finalizing the migration of the project to Maven. Artifacts will be posted in an open source repository offered by Sonatype. Soon, continuous integration will not be a dream anymore.

This comes on top of solving a long series of small bugs, including a nasty lurking one when attempting to establish a connection between NAT-ed peers. It just would not work.

"So, what's next?" - Well, we are looking forward at finishing the migration from Java.net to Kenai, a new HTTP protocol, more refactoring that will speed-up the code, implementing NAT traversal for TCP and running multiple peers in the same JVM. The latter is the last missing link to a full test driven development environment. This has prevented us from implementing a complete set of JUnit tests. All remaining issues are now well-identified and just need to be processed one by one.

JXTA/JXSE 2.5 is still part of Glassfish. Sun has lowered its participation to the project since the end of 2008, but some individuals remained very active in participating to the knowledge transfert. We don't know what the participation of Oracle will be. The possibility of moving to Apache has been raised.

"Any books?" - For those who do not want to go through the programmer's guides, the JXTA protocols specifications, Googling and trying to run obsolete examples found on the net, I have revised the first edition of Practical JXTA.

This book is an introduction to JXTA, JXSE and P2P for software engineers. It contains a new chapter covering NAT traversal issues.