Java book sales back up
Tim O'Reilly (for whom I work) looks at book sales as one of many indicators of trends. It is not his only source of information, but at last year's Open Source Conference (OSCon) he showed a chart detailing a drop in Java book sales in the months that preceeded the conference this past August. It was a tough OSCon for Java developers - the audience applauded at this revelation.
Java programmers noted that the next release of J2SE included major changes to the language and that it was unlikely that people would buy soon to be out of date books. In addition there was a growing number of third party and open source frameworks that had not yet been documented in books. It's hard to say such things out loud in a gathering of Perl, Python, etc. developers and not sound like a bunch of whiners. So, for the most part, we quietly grumbled amongst ourselves.
In his weekend blog on The Rise of Open Source Java, Tim updates his slide from last year to include results up through a week or so ago. He comments:
You can see that there was a sharp uptick in Java book sales starting in July of 2004 -- Java's share of all programming books sold is up about 3% since June of '04. A lot of this growth spurt occurred shortly after JavaOne and the new Tiger release, which happened around that time. All of the top titles were revised, and saw a healthy sales increase as a result. However, when we analyzed new books (versus revisions), it appears that a substantial portion of Java's sustained growth, outside of the classic titles, has come from books on Open Source Java projects, such as Spring, Struts, Lucene, and AspectJ, which collectively performed at nearly double the unit and revenue volumes of new books on their non-Open Source counterparts.
Long before this trend was noted, OSCon Program Chair Nat Torkington doubled the size of the Java track from last year and invited me back as track chair. It was tough to choose among the many strong submissions but I think we've built a solid track and look forward to seeing you in the beginning of August in Portland. Shameless plug: head to the registration page today as it is the last day to save $400 on the registration.
Can the AJAX label include Java applets? In today's Weblogs, Hans Muller explores this a bit in his post If You've Got a Name - Check out this Applet.
"Applets are old and AJAX is new: the hot technology du jour, the saving grace for developers who've toiled for years, trying to make browser applications palatable. While the AJAX discussion lumbered along, I kept an eye on my neighbors' screens. On my left, an interesting looking animated application appeared. Given the discussion, I assumed that the application was some AJAXian miracle, like Google maps, [but] I discovered (insert trumpet fanfare here) that what I'd been watching was an applet."
Jean-Francois Arcand posts his debut entry on
Grizzly: An HTTP Listener Using Java Technology NIO.
"Writing scalable server applications in Java technology has always been difficult. Before the advent of NIO, thread management issues made it impossible for an HTTP server to scale to thousands of users. I'm gonna start blogging on Grizzly, the HTTP Connector based on NIO shipped in GlassFish."
Ben Galbraith offers a solution to applications that require different versions of a jar file in
Classloading in J2EE Applications
"We're increasingly seeing frameworks co-exist in an application that in turn rely on different versions of the same libraries. And the solution is?"
In Also in
Java Today ,
Bruce Eckel has moved his blog to artima.com and posted on his experiences with Object Design. He stresses that design must be simple and that people have difficulty separating abstraction levels, saying "we are drawn to the complexity that we know." After a long rant on UML, the piece ends with the observation that " if you insist that complete information must be available at every stage, you rapidly converge on analysis paralysis on the project level, and the waterfall approach on the method level. On the other hand, accepting that information is incomplete allows a project to become remarkably nimble. At each stage you know you will only be able to mine some of the information about the project, and when a vein begins to dry up you move on rather than wasting time trying to pry out every possible nugget. From experience, you know that you'll move forward a lot faster by moving on, into a design pass, or even by pseudocoding your design."
Laszlo offers a dramatic rethink to rich internet application development. You code not with procedural declarations, but with XML markup. You don't compile; a servlet does that for you. And your code runs in the user's Flash plugin, even though you don't need to know the first thing about Flash to use Laszlo. In Exploring Laszlo Classes, Attributes, and Events, Satya Komatineni shows you how to set up and start writing Laszlo applications.
In Projects and
the JavaDesktop Community project XUI strives to make coding GUI's easier, and now it offers a greater level of attractiveness by integrating the Synth L&F and SVG. "With these visual enhancements we hope to silence the most vocal LAF critics. Well OK, being practical we hope they will at least have less to carp about!"
From the Mac Java Community: Apple has released WebObjects as part of XCode 2.1, for free. This Java-based application server is commonly used for building e-commerce sites, most notably Apple's Online Store and the iTunes Music Store. As recently as May 2000, WebObjects had cost US$ 50,000.
In today's Forums, TomWitmer asks if
USB (and javax.comm) support benefit from support of unsigned types? A few of us discussed it in another thread. It's possible to work without unsigned types, but as Java communicates with more devices, devs are going to need simpler ways of exchanging unsigned data with those devices. The two times I've run into this issue, I was working in someone else's protocol. Both instances were resolvable through much bitmasking and up-conversion (uchar -> short, ushort->long, etc.), but direct support for unsigned variables would have greatly simplified that effort