What do I know[!?]

In case you don't know yet, JXTA-C 2.2 had been released. Here is the release note. Thanks to Stefan, we now also provide a .msi installer for Win32 users.

Simon, I did not read from the article that you implied JXTA team is unprofessional. :-)

When it comes to license, I am with you we should all try to use existing OSI licenses. It's very true that each license tried to address some issues not covered by other licenses. As the licenses are evolving, it is much more likely to pick one can match the needs of a project.

I joined JXTA team in Dec, 2004, so I don't know much of the history. But looking at the JXTA license, it is basically an Apache 1.1 license with names replaced. Personal opinion, I would like to see JXTA been re-licensed under Apache 2.0, which seems to be a natural fit.

Stephanie announced the next JXTA kitchen will be held in September.

SAVE THE DATE!!  SAVE THE DATE!!  SAVE THE DATE!!  SAVE THE DATE!!
---------------------------------------------------------------------

You are invited to attend our upcoming JXTA Kitchen to be held at
Sun's Santa Clara campus, Monday, Sept 26th and Tuesday, Sept 27, 2005.

  Come join us and...

     - Hear the newest updates from the JXTA team at Sun

     - Bring your code & meet with JXTA experts from around the world

     - Enjoy 1:1 meetings with a JXTA team member

     - Discuss and share exciting new ways to use JXTA

     - Eat, drink, and have a great time!


SAVE THE DATE!

     WHEN:  Monday, September 26, 2005 - All day group event
	    Tuesday, September 27, 2005 - 1:1 meetings w/JXTA staff

     WHERE: Sun Offices, Santa Clara Campus (Building #21 and others)
            4120 Network Circle, Santa Clara, CA

Shane Isbell was asking about status of JxtaRuby, it turns out we are going to start a project to create Ruby binding based on JXTA-C project.

Another project initiative worth to mention is Symbian C++ binding.

Woohoo, I have been advocating create different language bindings based on JXTA-C. The benefit are obvious, we can concentrate resources to create a strong solid base for core function. On top of that base, applications can be implemented in different languages without starting from scratch, suffering from yet another partial(if not buggy) implementation. Although JXTA core protocols are relative small and maybe easy to implement, but to make it a complete platform to innovate next-great-thing would need more than that.

There is a must read thread if you care about package management on OpenSolaris. It's great to know that pkgbuild is available as open source and can build Solaris(SVR4) pkgs from a RPM spec file.

In an ideal world, I would like to see a build infrastructure separated from the package management system(PMS). Any choice of a build infrastructure should be able to work with a choice of PMS. In that case, you can easily update your system with the build infrastucture to build up-to-date packages on and for your system. The key is, the build infrastructure and the PMS need to agree on the package naming to resolve dependencies, which is what makes such separation hard to achieve.

The way I see pkgbuild, it uses RPM as a build infrastructure for SVR4 PMS. If the same spec file can be used to produce both RPM and SVR4 pkg, that is a a big step. Now, if we create a repository for src.rpms based on Solaris 10 or Express ...

With the great debut of OpenSolaris today, JXTA project is joining the party by releasing 3 versions today. We have released JXTA-C 2.1.1 and JXME 2.0. Java SE is also coming. Believe me, this is absolutely a coincidence, but shows you how much we appreciate and are actively contributing to the open source community.

I got an inquiry about the plan for next release of JXTA-C, I guess it won't be a bad idea to post it here as well.

As you may already know, JXTA Java SE version is having a quarterly release schedule and the next one is targeted on June 14th, 2005. I would like to see JXTA-C, as another language binding, to be released together, so we can send out a signal that JXTA is not only for JAVA, but a language independent P2P protocol suite. After all, one of the three objectives of JXTA is "Platform independence".

With all the cleanup I had done and based on the current status of the main branch depends on a not-yet released apr library feature(apr_dbd to be more specific), it should be reasonable to make a 2.1.1 release on June 14th based on the JXTA_C_APR_096_HOTFIXES branch, and then we will decide on when to release 2.2 the Disneyland release. :-)

So here is proposed schedule for 2.1.1 release:

• New code freeze: immediately. There is no new feature will be added into this 2.1.1 release. The significant changes for this release is that we clarify rules(http://wiki.java.net/bin/view/Jxta/JxtaCRefCount) about sharing/releasing Jxta_object and changed the Jxta_listener behavior to be compliant with those rules, which had been committed.
• Beta release: 5/24, 2005
• Release: 6/14, 2005

As for the 2.2, we will see how soon will apr 1.2 be released. Most likely, we will have the release in September, and with the 2.2, you can expect(at least) the following great features:

• Rendezvous server implementation by Mike Duigou
• Extended XPath based search capability by Rick Keiner
• New CM implementation based on SQL by Rick Keiner
• Support building JXTA-C as a DLL on Win32 by Stefan Lankes

Rock on!

As bondolo mentioned, we are making nice progress in JXTA-C project, the upcoming release is going to have some great features. However, I have been focusing on cleanup for a while.

One of the goals for the cleanup is to nicely shutdown all threads and to eliminate memory/object leaks after signing off the JXTA network. In the past version, some of the threads may stay idled until the process is stopped, and leaks are pretty bad. And the reason: Abuse of reference count.

In JXTA-C, there is an object model implements reference count, so you instantiate an object with reference count 1, sharing the object will increase the reference count, and release the object will decrease the reference count, after the reference count reduced to 0, the object was destructed and memory used will be freed.

Here is a typical pattern(bad and wrong) I found in the implementation:

1. object A instantiate object B and release it in destructor.
2. object B share the object A, release it in destructor.

Do you see what's wrong? A cross reference which causes none of them to be released. Having reference count implemented does not mean you don't need to think of when to share/release it. It only helps you to make sure the object's existence as long as you hold a reference count on it.

Another regular mistake I observed is whether an object should be shared. I use following rules to make it consistent therefore avoid such mistakes:

1. When making a function call to get an object, the caller should release the object after done with it, and the callee should share the object before passing it back to the caller.
2. When an object was passed to a function call as a parameter, no share/release involved. In case the callee want to keep the object the later usage, the callee should do the share.

Simple, isn't it?

As for the thread, it's very typical that the thread will need to reference the object creates it. But do a strong reference by sharing the object is not a good idea. Why? Stopping the thread in the object's destructor, you know what will happen, don't you? Even if you can stop the thread in other place instead of in the destructor, holding a reference to keep the object from been released is not a good idea. You should actually make sure the thread was stopped before the object been destroyed.

Anyway, with all the cleanup, now JXTA-C is in a good shape and you know we are committed to a high quality standard.