Wednesday Nov 07, 2007

JXTA JXSE 2.5 Released!

At long last JXSE 2.5 "Turducken" is now finally released. It was a huge amount of work and I believe it's going to be a very significant milestone for the JXSE community. I've still got a few more "What's Cool About JXSE 2.5" blogs to write (there's so much that's cool) but now it's out and there is no reason for any JXTA developer to not be using it. I'm really thrilled with the number of people and companies that have contributed to JXSE over the last year. I very much hope that our community can continue to grow and take this amazing networking technology to all kinds of new places!

Sunday Oct 14, 2007

JXSE 2.5 : What's Cool #7 -- Logging

JXSE (JXTA for Java SE/EE 5.0) 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.

One of the first major changes to occur in the JXSE 2.5 development cycle was our transition from Log4J to java.util.logging. I previously blogged here how we used Jackpot to do the conversion between the two APIs. The instigator of our transition to use java.util.logging was the Shoal project. Since all of Glassfish already used java.util.logging they quite reasonably didn't want a second logging framework, Log4J, in order to use JXTA. This concern has been an occasional, but common, observation by JXTA deployers ever since java.util.logging first appeared in JDK 1.4. We've planned on changing to java.util.logging "eventually" for quite a while. The gentle nudge, and the offer of testing assistance from the Shoal, finally made doing the conversion a priority.

Following the conversion to java.util.logging the JXSE community has struggled a bit with the transition. The control mechanisms for java.util.logging are somewhat different from the Log4J controls and certainly not as familiar. Most of the initial bumps have smoothed out over the last nine months as the wikis, FAQs and mailing list archives have accumulated our increasing experience with java.util.logging.

As with any significant change there are inevitably comprises. Leaving Jog4J meant we lost the use of Chainsaw though we gained significantly with the availability of a wide variety of JMX tools.

During the entire life of the JXSE project we've regularly received requests to entirely disable logging including permanently disabling logging by removing it from the compiled code. Generally the request is made for two reasons; to reduce the size of the JXSE jar or to make it harder for end users to disassemble proprietary JXTA-based applications. With the change to java.util.logging it is now possible to selectively disable logging. The instructions are available as part of the JXSE 2.5 Javadoc (Which will be here once the page is updated for JXSE 2.5).

Tuesday Oct 09, 2007

JXSE 2.5 : What's Cool #6 -- PeerGroup Executor and ScheduledExecutor

JXSE (JXTA for Java SE/EE 5.0) 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.

JXSE 2.4 was the first version to require Java Standard Edition 5.0. For that release we used only a small amount of JSE 5 specific functionality. The requirement of JSE 5.0 was primarily about advancing the support matrix to include the then newly released JSE 6 and providing the opportunity to take advantage of new features in future releases. In JXSE 2.4.1 we started to make much greater use of JSE 5.0 specific APIs, and most significantly the new java.util.concurrent utilities. In JXSE 2.5 we have continued to make much greater use throughout the JXSE source.

The concurrency utilities provide several flavours of task executors. The Executor and ScheduledExecutor classes provide a convenient way to execute tasks without the overhead of the normal Thread lifecycle. For JXSE the use of Executor is a very good fit. There are a very large number of short lived operations or tasks that JXSE performs to maintain the JXTA network and to handle application I/O. JXSE currently makes fairly heavy use of Timer for periodic maintenance tasks. We expect that in future JXSE releases we will replace all of the Timer usage with ScheudledExecutor.

One difficulty we have found with Executor is that the default policy is not well suited to I/O frameworks. The standard policy uses a fixed base number of threads and a fixed size queue. If the queue fills then additional threads are started to a fixed maximum. The policy that would work best for JXSE and other I/O driven systems is a fixed base number of threads and a fixed size queue. Additional threads would be started for additional tasks to a fixed maximum. After that tasks would be queued to a fixed maximum at which point the task submitters would block until their tasks could be enqueued or executed. The effect of the default policy is that when the base of Threads are occupied new tasks will be started with much higher latency unless the system is entirely saturated with tasks.

The Executor interface does allow some policy to be controlled, but we haven't really figured out how to effectively override the standard policy. Suggestions and or contributions would, of course, be very welcome!

Thursday Sep 20, 2007

JXSE 2.5 : What's Cool #5 -- java.util.concurrent

JXSE (JXTA for Java SE/EE 5.0) 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.

JXSE 2.4 was the first version to require Java Standard Edition 5.0. For that release we used only a small amount of JSE 5 specific functionality. The requirement of JSE 5.0 was primarily about advancing the support matrix to include the then newly released JSE 6 and providing the opportunity to take advantage of new features in future releases. In JXSE 2.4.1 we started to make much greater use of JSE 5.0 specific APIs, and most significantly the new java.util.concurrent utilities. In JXSE 2.5 we have continued to make much greater use throughout the JXSE source.

The use of the java.util.concurrent package, also known as the JSR-166 utilities, within JXSE 2.5 has been primarily about simplifying the implementation, obsoleting use of JXSE private utilities (mostly net.jxta.impl.util.UnbiasedQueue) and improving performance by allowing greater concurrency. By making use of the concurrency utilities in JXSE 2.5 the implementation is easier to understand, debug and extend. Use of ConcurrentHashMap has been particularly useful in simplifying several areas which where very complicated due to concurrency requirements.

We have also found the java.util.concurrent.atomic utilities very useful for simplifying code which required atomic counters and atomic booleans. In a few places we have started to use the java.util.concurrent.locks utilities and expect that future versions of JXSE will make more use of these utilities.

The next entry in this series will talk about JXSE 2.5's use of the java.util.concurrent Executor and ScheduledExecutor.

Thursday Sep 13, 2007

JXSE 2.5 : What's Cool #4 -- Generics & enums

JXSE (JXTA for Java SE/EE 5.0) 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.

JXSE 2.4 was the first version to require Java Standard Edition 5.0. For that release we used only a small amount of JSE 5 specific functionality. The requirement of JSE 5.0 was primarily about advancing the support matrix to include the then newly released JSE 6 and providing the opportunity to take advantage of new features in future releases. In JXSE 2.4.1 we started to make much greater use of JSE 5.0 specific features. The most obvious examples are the use of Java Generics and Enums. In JXSE 2.5 we have continued to make greater use of both of these features and each are now used extensively through out the JXSE source. These two features have allowed us to greatly simplify and clarify the JXSE APIs and implementation.

The common case for Java generics involves being able to write type-safe algorithms which can be applied to any appropriate data-type. The most popular usage of generics is undoubtedly the Java SE Collection utilities. In JXSE 2.5 we have converted virtually all of our usage of the collection classes to make use of the generified versions. For example, where a JXSE API previously returned Vector it now likely that it will return Vector<PeerID>. According to Java language rules programs which reference the "raw" Vector type will continue to work.

There are several advantages to the genericized API. The contents of the result Vector are now explicit which makes the API clearer. This is the primary advantage. An obvious API is one which will be used correctly. Programs which use the API can also more easily avoid errors because they can be written with direct reference to the correct types. We've been able to find errors even within JXSE itself where the wrong type was being used. If you have been using older versions of JXSE we think you'll find using the updated versions of the APIs much more convenient and pleasing to use, especially if you use an IDE with code completion.

JXSE 2.5's use of enums is designed to be compile time compatible in all cases with previous versions of JXSE. Unfortunately, for internal language support reasons, programs which were compiled against 2.4.1 or earlier must be recompiled to use JXSE 2.5. The JXSE libraries have always tried to maintain version-to-version compile-time compatibility though, such as in the case of the conversion to use enum, it has not always been possible to maintain runtime compatibility. The primary advantages of using enum within JXSE has been to improve clarity and simply usage as well as to take advantage of enum properties such as the ability to use switch statements for enum typed variables.

About

mduigou

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today