When it was announced that Doug Lea's concurrent library was being added to the core set of Java classes, I had a classic movie moment:

A typical corporate development environment: cubicles with high walls, drab grey color, and harsh artificial lighting. A developer is seen happily working at his workstation. A small message appears on the screen. All that is seen is the message:

Doug Lea's concurrent library brought into the JDK

The programmer's typing has stopped and a loud thump is heard. The scene quickly shifts back from the screen to show the developer's head on the desk. The scene continues to move back and upward.

DEVELOPER

Noooooo!

The programmer's hands move up to his head as he lifts his head, leans back and continues the cry. Fade to black.

Why do I want that wonderful utility brought into one of the slowest revisioning software products of the modern era? Currently, if there's a problem with the concurrent library, I post a bug, Mr. Lea takes a look at it within a few days (a week if he's on vacation) and shortly thereafter there is a patch. Constrast this with what occurs now in the JDK: file a bug, get a cryptic response (if any) in bug parade, wait patiently for months if not years for bug parade updates, con anyone you know into voting for the bug at any chance they get, then, if the phase of the moon is just right with the angle of Mercury to the ecliptic, the bug will be listed as fixed in some version that is at least two versions ahead of the currently released JDK or in some obscure version, and finally, once the JDK version has finally come out, you download and test only to find out that something was broken because of the fix.

It was recently rumored that RFE's are being accepted and voted on for Java 1.6. There are dozens of additions that people are looking for in the JDK. Why do I need javax.swing or java.awt in my server application? Why do I need java.sql in my game? Why does anyone need org.omg.CORBA *grin*?

My RFE is this: remove everything from the JDK! Reduce "Java" down to java.lang.* (and possibly java.security). All other packages will be divided into separate projects and made open source. Sun will retain control over "Java the language". To the end developer, Java will appear unchanged.

In order to support the current uses of Java, the profiles paradigm (seen with embedded Java, for example) would be used. For example, there would be an applets profile and a server-side (J2EE) profile. Each profile will define the necessary packages and versions. To facilitate this, a robust jar versioning mechanism would be required. This would also benefit anyone that has ever had to deal with jar version hell. A first pass might be to use Package. Strict guidelines would need to be published to define how versions are numbered and updated. Sun can provide a test and certification process whereby versions are validated and signed.

There are going to be a number of snafu's that need to be rectified. For example, the current NIO implementation uses a trick in java.lang.Thread (look for blockedOn()) in order to handle some of its interruptable aspects (such as InterruptableChannel). The JDK provides an SPI to allow vendors to create their own NIO implementation, but given tricks like these, it's impossible for anyone but Sun to do. Separating java.lang from the other packages will force these issues to light and force them to be resolved. In this case, one can envision a java.lang.Interruptable, for example.

There might be a concern that this idea will cause there to be 400 java.util versions out there. To this I say: are there 400 versions of apache commons? The concurrent library? I will admit that back when Java first arrived on the scene, there was a bit of chaos. That has, for the most part, settled down and there are well understood and respected methods to producing open source software versions.

Another concern would be intra-package reuse. For example, the java.util maintainers prefer log4j whereas the java.io maintainers prefer the current Java logging API. I don't claim to have an easy answer for this but certainly a product management committee could be assembled where each package is represented. This committee would be responsible for coordinating and resolving issues such as this.

How does JSR fit into all of this? I honestly don't know. I suppose that it will do what it has always done but rather than have most of its results put into the JDK, they will become an open source project.

Kris brings up a number of reasons that dealing with the current JDK bloat is not easy.

A question was recently posted on the CJUG forum with regards to the following code:

    int i;
    i = 1;
    i = i++;
    System.out.println("i: " + i);

The poster wanted to know why in Java the result was 1 whereas in C / C++ the result was 2.

If you're like me, the first thing that popped in your head was: This person does not have a clear understanding of the postfix increment operator does. Let's tell him to go suck an egg and get a clue. But then I remembered back to the days when I didn't know what I was doing either and all of the kind and gentle people on usenet that steered me onto the path of knowledge.

In case you're having trouble getting over that hurdle, you can look at the problem as follows:

int[] a = { 0, 1, 2 };
int i;
i = 1;
a[i] = i++;
System.out.println("a[0]=" + a[0] + ", a[1]=" + a[1] + ", a[2]=" + a[2]);

which is slightly more palatable and results in the following:

a[0]=0, a[1]=1, a[2]=2

I'll spare the long winded answer to the reason why Java returns what it does and refer you to a Java forum posting. (Though if you want me to ramble on about it, just ask!) That takes care of the Java part, but what about C / C++? Well, if you didn't get all soft and squishy developing in Java all these years, you'll remember that the order of evaluation of operands of individual operators and the order in which side effects take place is unspecified in C / C++. You'll also start remembering about sequence points and all of that but before you begin to spasm uncontrollably, you'll remember that you've left all that behind you now. At the end of the day, the fact that the particular C / C++ compiler, runtime, etc resulted in 2 is simply luck of the draw. The expression is undefined. To quote Dale King:

...in C that statment might assign 0, 1, 42, -1 or any other value to i. It might crash your machine, erase your hard drive, or cause your computer to melt down. All would be acceptable results of executing that statement, since its behavior is undefined.

There is also Steve Summit's famous response which provides links to the C FAQ for more information.

As I have mentioned previously, I am in the process of writing a technology presentation for the physics department faculty and graduate students at my alma matter. I have been continually running into road blocks when trying to find the best way to describe common concepts in software engineering to people that do not work with software all day.

The topic for today is: software architecture. I did the ususal "define: software architecture" on Google for a baseline and then I queried a number of colleagues for their thoughts. I ended up with many variations on the theme: an arrangement of components to meet a particular objective. The problem with this is that for someone who does not work with software, components is completely undefined. Throwing in the word "software" into the definition does little to elucidate the matter.

I stumbled on this link and from that I was directed to a link at the SEI. (If you've read some of my other postings you know that I'm enamored with the CMM and by proxy the SEI). The SEI link provides a trove of information including a section that has user specified definitions. I haven't settled on my own concise definition as of yet, but the SEI has certainly given me more to go on.

The notion of unifying IM and email (and VoIP) is almost to the point of being trite with me. The fact that my IM messages are not stored together with my email threads (GMail-like would be simply sublime) is simply ludicrous. Not being able to just type in an IM window to an "offline" "buddy" and have it automatically send an email is mind boggling.

Given that there is already the necessary components in SIP to do both IM and email, there is no reason that a common infrastructure shouldn't be used. Using SMTP as it is used now should just be left in the corner to die like the mangy rabid dog it is.

The fact that Sendmail, Inc. sat idly by during the dot com days eating millions of dollars of VC's money while the internet raced by them at the speed of light angers me to unpreviously seen levels. Every time that I see some of Sendmail's VC's (I know a couple of them very well) I want to kick them in the teeth for letting David Anderson take what could have been the investment of a lifetime and squander it on absolutely nothing. I should mention that the reason I'm so mad has nothing to do with any investment in Sendmail, Inc. (which, thankfully, I do not have) but has everything to do with the fact that I don't have a unified messaging infrastructure.

And if you really want to see me livid, ask me about sm-X (Sendmail 10 which was previously being developed as Sendmail 9). Sendmail, in its current form, is some bastard turd left over from the "old days" of systems programming. When you look across your enterprise software, Sendmail is the only non-enterprise enterprise application. The only reason that it's still there is that it does what it needs to do quite well and that it's attached via some unseen force field to that belligerent admin that no one talks to that lives like a troll in the basement of most organizations. Attempting to wrangle Sendmail away from this admin would take the military force of a large first world country. I'm digressing. sm-X, rather than being the magic bullet that Sendmail, Inc. and the rest of the world needs to fix its messaging needs, is a complete rewrite in the same systems paradigm as the current Sendmail with essentially functional parity but they're replacing the impossible to understand sendmail.cf language with some other obfuscated language. When I asked the sm-X project leading why in the world were they taking away the only reason that the entire world hasn't migrated away from Sendmail (i.e. the sendmail.cf file and the savants that maintain it) and what was their plan to ensure that the existing installations would be able to migrate to sm-X his answer was: silence and no current plan. My current advice to the people of the world that use Sendmail is: RUN. Run and don't look back. The migration path from Sendmail 8 to Sendmail 10 is going to be a nightmare and with the well known problems that have occurred in Sendmail's past when moving just between minor revisions, you can just imagine what another full rewrite is going to look like. Start your own migration away from it now!

*heavy breathing* Alright, I finally got that all off my chest. I think I'm done for a while on the Sendmail topic. Did I mention that there's no conformance or regression suite to speak of for Sendmail? How in the world can large companies be expected to migrate to Sendmail 10? Is Sendmail, Inc. going to test, certify, charge up the wazoo for support, etc to do the migration? I would think that there is something sinister going on under the Sendmail, Inc. covers with regards to this whole Sendmail 10 thing if I didn't know for a fact that Sendmail, Inc. has no say over what happens in Sendmail (the code). They're just as surprised as the rest of us are when crap comes down the pipe.

Whew! Now I'm really done.

OK, so this was more of a long rant than an idea. Sorry. *grin*

Expressing intent only though code is lossy.

If it is accepted that a reason to weed though someone else's code is to find and remove bugs, how can the argument "the code is self describing" stand? The original intent has clearly become partially lost due to a defect.

There are at least two cases that exist in the presence of a defect:

1. The original intent is described through the code.
2. The original intent was improperly transcribed into code.

Without comments or some other mechanism to state intent, the two cases are indistinguishable. The first case is a much larger concern (i.e. risk) than is the second since it has the implication that other decisions were based on a flawed intent.

When a "code is self commenting" programmer is also a "crafty" programmer, you have the recipe for disaster. A crafty programmer is one that attempts to use small tricks such as over using a variable (e.g. a null value implies some other value does not exist) to achieve a goal. The problem with the resulting code is that the intent is obfucated. Anyone else reading the code typically has to scratch their head and wonder "is this intentional or a bug?". Information about the intent is clearly lost in the translation to code.

This paper presents manditory access control (MAC) in Java. Below is an excerpt:

... we have extended the JVM with functionality to do mandatory access control at the granularity of objects. Our implementation strictly separates the enforcement mechanism from the specification of polices. This allows flexible specification and enforcement of a wide range of policies. Moreover, we show that these techniques are implementable in current JVMs with minimal modifications to other JVM subsystems, while maintaining full backwards compatibility.

We have implemented this by adding an access control tag to each object, and modifying the virtual machine to check that tag at every data access to an object. Policies will take the form of predicates over these access control tags. Since mechanism and policy are strictly separated, various policies can be plugged in to the VM.

Why is it that with the advent of the digital camera with the LCD screen that everyone stopped using the viewfinder? Did you notice any of the professional photographers during the Olympics holding their camera out at arms length? (Yes, most of the new high end professional camers do have the LCD viewers.) Have you been to a wedding lately? Do those photographers hold the camera out at arms length? NO!

Now for the hundred thousand dollar question: Do you know why?

Holding the camera at arms length is probably the most unstable (read: results in blurred pictures) way a camera can be held. I'm sure that you can attempt to balance it on your toe or something for a less stable position, but for a practical shot with your shoes still on, arms length is the worst. My personal favorite is the "I'm so cool that I can do the one handed arms length shot". If you've taken any photography course or read any book on the subject you know that it's recommended that at least one arm is tucked tightly against the body for stability.

I will admit that for some shots (such as those close to the ground or very close to an object where the viewfinder parallax is greatest) that the LCD (especially if it is able to be turned separate from the camera) is invaluable. I will also admit that framing is somewhat easier with the LCD for some shots but in that case a tripod or monopod is recommeded. But for most shots, looking through the viewfinder with a stable platform (arms in and all of that) will result in the best picture.

If you're going to inundate the world with your crazy vacation, family, event or whatever pictures, for the love of all that is good and pure, don't hold the camera at arms length!

And yes, I'm considering making a Things that really tick me off category.

I have been dealing with enterprise storage solutions lately (kill me) and I ran across NTFS's file system filters. I had a good idea what they did from the name but years of development has trained me never to take a name at face value. While doing some splunking I found this MSDN article on XP System Restore. There are no shocking revelations but it did interest the academic side of me.

Given the capabilities of most PC's (internal speaker, microphone, a good deal of available processing power) it seems reasonable that software can be written to cancel out the noise from a PC. To go a step further, it seems reasonable that a card can be created to detect noise from within the PC case and cancel it out (even if this required a small external speaker that needed to be mounted on the case). The hardware solution would not consume any CPU processing or the microphone port. I would glady pay $20 - $30 for this service.

I've been called "the Idea Man" by many friends for as long as I can remember. When I was younger I had this glassy-eyed idea that at some point I would be able to realize (i.e. make real) the ideas that I have. As I have gotten older I have begun to see that I will never have time to get to even a faction of them.

So that the world may be a better place, I have made an idea category. I will begin to record the ideas as time permits. All of the ideas are copyright Rob Grzywinski but given the fact that I'm am making them available to all, I make no exclusive claim over them. All that I ask is that if you take one of these ideas and realize it that you mention my name. If you ever make money off of one of them, I would be more than happy to accept a percentage!

My programming category was getting over used so I have added a Development category. The distinction will be:

• Development: generic problems, concerns, issues, etc with development, computing and all of that jazz.
• Programming: specific code, framework or tollkit related items.

I will be resorting the entries into the categories as time allows.

I'm in the process of writing a presentation that I will be giving in early October entitled Computing to Support Scientific Research: How to stay focused on the science, not the software for the physics department at my alma matter. Given the audience, I want to ensure that all terms and concepts that I would typically use willy-nilly are well defined and concisely used.

One focus of the presentation is tools that have enabled or simplifed development of complex applications. In the abstract, frameworks and toolkits have provided enormous traction toward this goal. I quickly realized that I did not have a concise definition for either term (my thinking tends to be more visual which typically does not allow me to readily translate thoughts into succinct terms). A little searching has resulting in the following:

• Framework: A specification or implementation (code) that provides a general solution to some problem or aspect of applications.
• Toolkit: A collection of programming subroutine libraries that can be used to make development easier.

If the code path is taken, a framework is-a toolkit.

California Grill
Disney's Contemporary Resort
407-WDW-DINE

The California Grill is my favorite all-around resturant. The sushi is first-rate. Service is excellent. Food, put simply, is heavenly. And the view is sensational.

The trick to dining at the California Grill is to time your meal such that you finish the entree just as the fireworks begin at the Magic Kingdom. The lighting is lowered and a hush comes over the resturant as the eye-level fireworks seem to surround you in an amazing display. Once the spectacle completes, your dessert arrives (my pick is typically a heavenly souffle) and you are in pure ecstasy.

I spent some time a few days ago working with JBoss to determine if it would be a valid service oriented platform for autonomic computing. You can read my multiple JBoss JMX posts for more information. Until a more well defined service lifecycle exists ala JSR 77, the ability to autonomically manage a JBoss service is not possible.

I'm looking into OSGi, Avalon and Excalibur next. (If you're like me and forget how Avalon, Merlin, Excalibur, etc are related then refer to this.) Stay tuned for results.