JCP 2.6 - Are we there yet?
The Java Community Process version 2.6 was put into place yesterday.
The article that appears on TheServerSide , explains that the changes are "designed to encourage more participation by a broader range of developers and simplify the process of creating compatible Java technology APIs. " Critics have complained in the past that by the time a spec is released for public review, it is too late to do anything about it. To address this, "As part of JCP 2.6, each new JSR must include a transparency plan, which outlines the tools and techniques that the Spec Lead will use during the creation and development of the specification, for communicating JSR progress at each stage."
Doug Lea helped led the way by showing that this openness could benefit the evolution of a JSR. He is quoted in the article as saying, " I'm pleased that open processes like those used already in a few JSRs will now become the expected way for JCP specification efforts to proceed. We found in JSR166 that opening up channels for involvement by interested developers improves specifications, tests, and implementations. It's also more productive and pleasant. Expert Groups can accept good ideas and critiques early enough to make a difference, and can produce final deliverables with more confidence that they will be widely accepted and used."
The changes in JCP 2.5 and 2.6 seem to have opened up the Java Community Process and made it easier for the community to get involved. What do you think?
Also in Java Today , Carol McDonald writes that you shouldn't wait until the end of creating an application to think about performance and scalability any more than you would delay your plans for including security. In her java.net blog entry Some J2EE Performance Tips she stresses paying attention to how you use resources such as CPU, memory, bandwidth, and database. She points to a variety of resources including J2EE Design Patterns and the Blueprints resource. She finishes the article with a nice summary of tips and techniques together with more links. Add this article to your bookmarks.
Jayson Falkner writes about client side caching in Another Java Servlet Filter Most Web Applications Should Have . In his last article he wrote about server side caching and this time he creates " a filter that can modify HTTP response headers with the intention of using it to modify the client's web browser's cache. Client-side caching isn't as obvious as server-side caching, but it can be incredibly helpful, and it's near-trivial to implement."
In today's Weblogs , Chris Campbell takes a look around what's going on in client side Java in On Fat Cats and Fat Clients . He's encouraging more people to download the J2SE 1.5 beta and take it for a ride. He also is advocating higher level libraries so you don't have to spend your time writing low level code.
Malcolm Davis writes about Specification Insight. When it is time to learn a new technology, the specs are a great place to start. He points out that specs give you insight into the workings of a technology and explain mindset, features, description of interfaces, location of additional resources and other related specifications. He concludes that "The only problem with this approach is that you may get irritated at people that don