I just noticed that www.xom.nu is redirecting to www.elharo.com. I suspect I broke it while testing some redirect scripts for Refactoring HTML. It should be fixed shortly.
OK. It's fixed now. It's a little surprising that the site was broken for probably two days and nobody noticed. Either XOM is so clear that nobody need to read the documentation or not as many people are using it as I'd like. Today I had the displeasure of using both DOM and dom4j on another project I've been working on (For non-technical reasons I'm not at liberty to go into, XOM is not an option on this project.) and they were both appalling. JDK 1.5's DOM implementation was flat-out buggy and dom4j was broken by design. I am astonished that developers are still using these products. I was sorely tempted to bring in JDOM, but I didn't want to introduce yet another dependency. I ended up settling for Jaxen.
Sun has published the second maintenance release of JSR-154 Java Servlet 2.5 Specification. Changes mostly clarify a few points.
Nokia has posted the finished spec of JSR 264, Order Management API, to the Java Community Process. According to the spec,
This API specifies minimum requirements for Order Management Systems supporting end-to-end creation and management of Products, Services and Resources instances through Orders or Work Orders.
Systems solutions implementing this API will deliver the core functionality required from a modern Order Management System. Order Management API specification implementations may vary between vendors – the specification defines the implementation interface (not the implementation of the actual system) and the interface can also be further extended.
The OSS/J Order Management API provides significant extension of the previous JSR-089 OSS Service Activation API (JSR-264 replaces previously defined OSS/J Service Activation API JSR-89, which will be deprecated when this JSR is released), specifically:
- Addition of orders capable of provisioning Products and Resources
- Ability to create and manage Work Orders (WO)
- Ability to create, accept and manage bulk orders Resolution of positioning in relation to other OSS/J APIs (e.g. Inventory)
- Ability to provide the API for Order Management in an industry agnostic fashion (i.e. not restricted to the Telco industry)
Hewlett-Packard and BEA have posted the early draft review specification of JSR 309: Media Server Control API. Quoting from the JSR,
This JSR defines an API for the generic Media Server Control. Modern IP and SIP based Media Servers are designed to perform various smart functions with media streams. Most of the Media Servers are also designed to act as an MRF (Media Resource Function) in 3G and IMS environments. Typical non-exhaustive functions provided by the Media Server would include IVR, Conferencing, Speech Recognition Services, TTS (text to speech) Services, etc.
There are several industry accepted specifications defining Media Server control protocols designed to support interactions between application servers and media servers. Those protocols provide access to Media Server functions. In most cases protocol functions can be abstracted at the business application level to provide common functionality for application developers. This JSR will define an interface that is intended to be the standard API to write multimedia applications and services for both IP and converging networks. This specification work does not intend to specify any aspect of the media server control protocols.
For developers, Media Server Control API is intended to provide a standard API for developing and deploying new media rich applications for the Java platform without a prior knowledge of the underlying Media Server Control protocols. Moreover, a Java application that invokes Media Server Control API can use any compliant implementation with any compatible Media Server. Furthermore, developers will be able to implement interoperable applications and services that can run over a variety of protocols with various Media Servers.
The central focus of this JSR is to provide an abstracted API for external Media Servers that may be controlled via different protocols from the application server. The proposed API is not protocol specific. Media servers are usually controlled by an Application Server that will have the implementation of the proposed API. API will allow extensions for protocol optional functions or Media Server optional capabilities.
Requirements:
The initial version of Media Server Control API is targeted to support capabilities such as IVR and Conferencing, both individually and combined within the same session. The API will be designed to handle the fact that different media servers may differ in capabilities. This will require defining packages, profiles or API capability for the application to query the level of support of a media server.
This list of requirements is not complete and this will be explored further in the expert group ? for example, additional support could be defined for ASR, TTS, or RTSP-based streaming, etc. It is intended that the priority of each of these enhancements be defined by the expert group with the goal of defining the API in an incremental manner satisfying a bulk set of requirements in each release. This is done to ensure timely delivery of the API as well as in order to gain experience with some of the more advanced features prior to standardization.
Version 1.1.8 of the Kaffe open source Java virtual machine for various Unixes has been released. This release adds a PowerPC JIT among other new features and bug fixes. This release updates GNU Classpath to 0.93; compiles with gcc 4.1; removes the javax.comm, javax.servlet, microsoft and pjava extensions. adds a Xynth Windowing System based AWT backend, and adds ports to i386-GNU/kFreeBSD, i386-Interix, and x86_64-openbsd.
I've posted the notes from yesterday's "Human Factors in API Design" session. I've posted the notes in PDF for the moment (Blech) because I haven't yet had the time to figure out how to degunk the HTML PowerPoint generates so Firefox can read it. Apparently this is a known problem. Maybe I should just import the presentation into OpenOffice Impress and export it from there?
Update: The XHTML export from OpenOffice is too stupid to use, but the HTML export is plausible. The notes are now available in a more browser-friendly format.
Thanks to some help from the SD Best Practices Speakers lounge, I may now have fixed the links to some of my other blogs. I still don't understand what happened, but the suggestion of putting xsltproc into verbose mode gave me enough info to fix the problem.
This page seems to be fixed at the moment. If it borks itself again, holler; but I may or may not be able to fix it until I get back to New York tonight. Anyone know if there's wireless in Boston Back Bay station yet?
The closing keynote is CodeGear's David Intersimone on "Future of Software Development in a Virtual World". I was hoping it was about virtualization (an increasingly important and interesting subject) but apparently it's about Second Life. Aren't we over that yet? The keynote seems to be broadcast remotely from inside Second Life. The audio is bad. The video is worse. This session is so monotonous it could have been delivered by a speech synthesizer. For all I can tell, it is being delivered by a speech synthesizer. Developers come to conferences to hear speakers live and discuss with them live. If they're going to do it in Second Life we might as well have stayed home.
I've posted the notes from this morning's session on Fuzz Testing at Software Development Best Practices in Boston. This is the first time I've delivered this material. Overall I think it went well. There are some new ideas here that aren't widely known and need broader dissemination. One of the attendees pointed out that Steve Capps' The Monkey predates the Wisconsin work that is normally considered the first fuzzer.
Sun's posted the first official feature complete beta of NetBeans 6.0, its pure Java IDE for various platforms. I spent a little time playing with it, and it's definitely getting there. It's quite clean, overall, and serious competition for Eclipse, at least at the base level. I can't quite find my way around it as easily as in Eclipse--I never did figure out how to make one project reference another--but that's just a function of my years of experience with Eclipse. For someone starting from scratch, I have little doubt NetBeans would be a much easier product to use. The biggest flaw I noted was that some of the menu items like "Options" bring up dialog boxes but don't end in .... Otherwise, I couldn't find any problems.
Yes, I know some of the links below are borked. I don't yet know why. None of the stylesheets that generate these links have changed lately, and the Atom feeds they're reading from appear to be correct. It may have something to do with an intermittent network error between Mokka mit Schlag/The Cafes and IBiblio. I am working in repairing it.
Seems to be fixed now. Holler if it gets borked again.
OK. It's broken again. This really makes no sense. What could have changed to cause this? Until I figure this out I'll just turn off the links to the other blogs.
Hewlett-Packard has released the finished version of JSR 263 Fault Management API. Quoting the executive summary,
Currently, the OSS fault management functionality supported by an OSS through JavaTM API is contained within the OSS Quality of Service API (JSR90). A software vendor that wishes to only implement fault management functionality is faced with the dilemma of being “partially compliant” to the OSS Quality of Service API”; and partially compliant is simply a statement that software vendors would prefer not to make.
This API, The OSS Fault Management API (JSR 263) was initiated to separate the two APIs, fault management and performance management from each other to enable software vendors to implement those portions that they would like to implement, and to be able to make the statement that their product is compliant to one or both of the aforementioned APIs.
The OSS Fault Management API focuses creating an interoperable fault management API that is compatible with the 3GPP Release 6 Alarm IRP. In accordance with the OSS through JavaTM Design Guidelines, the API defines JVT, XML/JMS and Web Service implementation profiles.
It's 8:30 A.M. Norway time at JavaZone. There's a "rocket ship" outside the front door blowing smoke through the hallways. Nobody seems to know where the speakers check in. Me and two other speakers from Britain got sent through the parking area into a hard hats only area where a guard rescued us. (My wife suspects the guards thought we were asking where to bring the amplifiers. That sounds probable, especially given what was about to happen on the show floor.)
The conference is opening with a very loud death metal band that started playing at the stroke of 8:00 (A.M., not P.M.) Hmm, looks like they breathe fire. Most people in Norway do speak English, but not everyone; and most especially not when you have to shout over the death metal to be heard. Update: I'm told it's actually "Neue Deutsche Härte" metal, not death metal. I confess the musical subtleties escaped me.
Sorry. No pictures. My wife has the camera this morning. I still don't have a badge, so I'm not sure if I'll be able to get into any sessions other than my own. I should be able to get into mine. Most of the guards seem to just wave you on through if you blabber at them long enough. I'm not sure any of them understand what I'm saying--I'm not sure if anyone understands anything anyone is saying over the death metal--but they probably figure that if they let you through you become someone else's problem. At least there's wireless.
Bjarne found me on the show floor and told me where the speaker's lounge was. Just int time too. I think the band was about to start juggling knives. (That or swallowing them, but I really didn't want to stick around and find out.) The speakers lounge is hiding upstairs in a restaurant that seems well-protected from stray flying knives. Up here he death metal is a relatively low background rumble, It's still not my choice for early morning easy listening, but at least the stomach-rumbling bass lines are muted sufficiently. Along the way I ran into Tobias who promised to find me my badge so I should be squared away soon.
I caught the tail end of a session on a Contributing to Open Source at whihc once again the myth that Java is somehow incompatible with the LGPL was repeated. It seems that no matter how many times the FSF and others deny this canard, it just keeps coming back. It's the Java equivalent of, "Iraq was responsible for 9/11", "Republicans are the party of fiscal responsibility", or a "A dying child in the hospital wants you to send him postcards." It is a dangerous meme that seems completely immune to the truth.
There is no validity to this claim whatsoever, and I wish people would stop propagating this myth. The whole idea is based on the mistaken belief that the LGPL treats static and dynamic linking differently, but it doesn't. A variant sometimes claims that it is inheritance that makes the LGPL incompatible with Java. That is also false. Of course, it is hardly just Java that supports inheritance or dynamic linking. If Java is incompatible with the LGPL, so is C++, Objective C, Smalltalk, Eiffel, Python, Perl, AppleScript, and pretty much every other language invented in the last 15 years. There is nothing unique about Java that in any way affects its compatibility with open source licenses, LGPL or others.
The second morning session has Markus Krüger talking about Performance Analysis with JMeter. We're a little cramped in here, and there's no wireless so I probably won't take notes on my laptop. Bottom line: seems like a good tool. I should explore it further when I get home.
My own session on Refactoring HTML went well. We had about 200 people in attendance and most of them stayed for the whole thing. I did have to go through so many points at lightning speed. It would have been nice to be able to give a few more details of exactly how to implement some of these refactorings and some more evidence that they are in fact good ideas; but in 60 minutes you can't do more than hit the high points. Maybe next year I can do a full day class on this somewhere. I'll post the notes here soon.
The next session I'm attending is Mike Aizatsky's JavaScript Puzzlers. I don't really know JavaScript well, but I feel like it may be time to learn more.
JavaScript returns undetermined from functions with no return value (like Python's None). Weird and very un-Java-like. Also, there are no ints. All numbers are floating point numbers. I remain convinced this language should never have been renamed JavaScript. Not that it's a bad language, just different.
On the other hand, JavaScript does share Java's (and C's) broken semantics
for switch. It also contains octal literals.
Does anyone ever use those any more? Did anyone ever use them?
Why did the designers of JavaScript have to keep the
broken parts of Java?
For the next session I'm torn. There are two I really want to see: one on Apache Wicket and a case study about replacing JMS with a simpler, homegrown solution that stores all the state in the database. I've been banging my head against JMS a lot for the last few months, so I'll probably go to that one if there's room. Then again I'm quite tired after a week in a foreign time zone, the Apache talk is in the same room, and the JMS talk is across the arena. Hmm, looks like the Apache folks are advertising "a refreshing lack of XML". That's a bug, not a feature. Web applications are one of the two cases where you need XML the most. Not only that: their very first Hello World example is namespace malformed! Finally, it all sits on top of the hideous servlet architecture, including web.xml. The place where XML arguably doesn't belong is the one place they keep it. I think I'll go listen to the JMS talk instead.
Lunch was cold sandwiches: skink og ost (ham and cheese) and similar. However, for the afternoon snack they seem to have roasted an entire cow and are now slicing it up on the exhibit floor. I wish I had my camera. Normally my carnivorous instincts would be intrigued, but I'm afraid the combination of jet lag, speaker stress, and the rich Norwegian food has disabled my digestive system for the time being. Still, a whole cow?
The speakers here are an unusually diverse group. I only know about three of them. Normally I see the same faces cycle through these conferences again and again. Most folks aren't giving more than one session, and several are delivering presentations in Norwegian. There's also a decent sized exhibit floor. Roughly half the companies exhibiting seem to be here to recruit Norwegian speakers for developer jobs. Definitely not a replay of the typical U.S. conference.
Eirik Maus's session on replacing JMS was very interesting. In brief, the speaker's company (BBS) had wasted a year trying to make an IBM JMS server work for banking applications. They replaced its 2GB of JAR files with twelve homegrown interfaces and an Oracle database, and now it works and is more reliable. The database server is now a single point of failure, but previously the NFS server where the single transaction log was stored was a single point of failure. He also noted that 90% of their failures were related to redundant systems designed to eliminate failures. The more redundant, fault-tolerant pieces they pulled out of the system, the fewer pieces there were to fail and the more reliable the whole system became. Some of the problems with JMS he attributed to IBM's specific implementation, but others he felt were a direct consequence of the architecture and not fixable by any vendor. One problem was undocumented serialized objects stored inside the database. When a message did get stuck, it was impossible to use SQL to unstick it because you didn't know what it said.
For what will probably be my final session of the day (I need some sleep and aspirin) I'm listening to Thomas Helberg and Per Hengshoel talk about Scripting in Java 6. I'm not sure if this will be anything new I didn't hear at JavaOne, but I'm hopeful.
Even I'm more tired than I thought or this session is in Norwegian. I think I may go home early. I think Kirk Pepperdine speaks English. I'll switch rooms.
OK, this talk is in English. I'm good. He's starting with a Google video by Plaxo's Joseph Smarr from OSCon. (Anyone have the link?)
Being methodical and getting good solid measurements is important for performance.
Three performance testing antipatterns:
Memory leaks never cure themselves. If a problem cures itself, the problem is load. The generational count of an object tells you what is leaking.
I'll be in Norway for JavaZone for the next week. Updates here will be a little slow until I get back.
Sun has announced that next quarter's financial results are going to be late due to problems in installing new accounting software. I suppose +it's not quite as embarrassing as it would be if Peachtree announced they were going to be late due to software install problems, but it's still pretty bad.
IDRsolutions has released JPedal 3.22, a pure Java library for extracting content from PDF files and rasterizing them. Text fragments are extracted as XML elements with font and location information. Images are extracted in both their raw formats and their clipped and scaled formats as TIFF, PNG, or JPEG files. New features include AES encryption and JavaScript Form Validation. JPedal is published under the GPL.
Adobe has posted the first public beta of Flex 3.0, its "cross platform, open source framework for creating rich Internet applications that run identically in all major browsers and operating systems....The Flex 3 public beta marks the first significant deliverable for the open source Flex project, beginning with the availability of nightly builds, a public bug system and product roadmaps for both Flex Builder 3 and the Flex 3 SDK. View the community process to understand how you can participate."
SK Telecom Co., Ltd. has posted the public draft review of JSR-298 Telematics. This describes an API for controlling automotive electronics. Comments are due by October 1.
I've made some adjustments in the mod_rewrite filters on Cafe con Leche. The immediate reason is to allow me to serve .phtml files instead of .html files, and the reason for that is to improve the recommended reading by using del.icio.us as my backend, instead of the homegrown scripts and text files I've been using for the last 10+ years. If nothing goes wrong, the changeover should be transparent. However something always goes wrong when I play with mod_rewrite. Please do let me know if you notice any problems, like a page stuck in an infinite reload loop, or a page that can't be accessed. Once it's all debugged, I'll probably switch Cafe au Lait over to a similar system. That should actually be the easier changeover, since this site already uses .phtml files instead of flat .html.