void javaBlog() throws TeenSpeakException;

Some lines are too good to pass up. I have spent paragraphs trying to explain the sea change toward simplicity in Java. I should have taken the "grade 9" approach:

I *heart* POJOs.

as coined on Eric Burke's blog.

If someone makes bumper stickers from this, I want royalties. Eric just couched it in a post; I'm the visionary.

I'm also claiming:

• OMG, Junit, BFF!
• Be thread safe: POS!

Actually, this could have legs.... feel free to add your own!

Art and XML: Reactions Against Complexity

Recently, I've thought about a common theme between art and computer science: the "reaction against complexity".

This phrase seems to come up a lot in art, whether it is music, architecture, or visual art. Almost all of the schools (e.g. the Impressionists) seem to come about in reaction to something. Often, it is complexity.

The Bubble

I wonder if anything sets out to be complicated. It often seems like there is an idea that is embraced, then added to, reused, refactored, and eventually pushed into an ever-expanding range of uses. Then, there is a lightning bolt that jars everyone into the realization that, "hey, we are in an era of complexity right now -- how did that happen?".

Here's some examples from art... (These may be grossly over-simplified!)

Grunge

An easy, contemporary example is hard rock/metal in the late 1980s (in North America and Europe). Throughout the decade, the style had grown from its bluesy roots in Led Zeppelin to having shrill, operatic vocals, and guitar solos with amazing technical virtuosity. Bombastic looks and videos ruled the day.

Then along came a band out of Seattle, and nothing was the same. Seemingly overnight.

Cool Jazz

In the 1940's, a primary form of American jazz was bebop. Bebop was known for its fast tempos and sophisticated ideas for melody, harmony, and rhythm. Miles Davis, in his first stint as band leader, took things in a new direction with a landmark recording called "Birth of the Cool". To quote this website, "The cool jazz style has been described as a reaction against... [the excess] of bebop and is generally more relaxed". There's that phrase again.

Modern Architecture

Modern architecture is a style that began in the early 20th century. It's characterized by simple geometric lines and a distinct lack of ornamentation. Ultimately, it led the way to the skyscraper. To quote one of the founders, Ludwig Mies van der Rohe: "Less is more". (Sound familiar in the geek world?)

To paraphrase Wikipedia, some historians feel that the Modern school is a "reaction against" the excesses of the movement known as Art Nouveau (an example is here).

Convention over configuration

This is not news but we geeks seem to be emerging from an orgy of XML (aka The Bubble), where it has been used for everything. Most of this use is predicated by configuration: Struts 1.x, EJB 2, and the list goes on.

Of course, the lightning bolt has been Ruby on Rails. Most readers will know that the bumper sticker for the RoR camp is "convention over configuration": just do the natural thing with a minimal, simple set of files, and the framework will take care of the rest. Why over-specify everything all the time?

Similarly, annotations have simplified EJB 3 and JAX-WS. XML is invaluable, no doubt, but perhaps the days of excess are over? I have heard several speakers talk about the "old days of XML hell" with "legacy" frameworks (which are only a few years old).

Perhaps this is Struts 1.x?

Perhaps the historians will talk about a new age of frameworks "as a reaction against complexity"....

The Upshot

Whether it's in your own project or in the Java scene, keep an eye out for complexity and note the reactions to it. It's fun to guess what the "next bubble" will be. Based on patterns in art, my guess is that annotations themselves will be the Next Bubble. They fix a problem, are being embraced, then added to, reused -- wait, haven't we heard this before?

Java: What's All the Excitement About? (1997)

In this post, Weiqi Gao quietly mentions that the St Louis Java User's Group had a talk by Mark Volkmann, 10 years ago this month, on Java: What's All the Excitement About?

It's a quick, fun read to go back in time with the slides. I don't think we need another "10 year retrospective", but here are some random thoughts.

• There's dozens of issues that have been wildly successful. Suffice it to say that, despite stumbling out of the gate, Java is certainly a Hall of Fame language and platform.
• The performance issue is continually pushed to the next layer. Ages ago, C probably wasn't fast enough. Then C++. Then Java. Now it's Groovy and JRuby. Plus ça change, plus c’est la même chose!
  
• Garbage collection algorithms have been the "NASA Space Program" of Java: it is amazing what bright people can do with focus and purpose.
  
• Webapp technology has changed drastically, and yet the Java space still doesn't agree on a framework.
• Does anyone explicitly use the Security Manager/policies etc? Perhaps in the EJB space?
  
• It's been 10 years of installing Java programs. There are no words better than the drawings on this timely blog which promises sweet relief in Java6.
  

Unit Testing and the Turing Slot Machine

A dear friend is a neuropsychologist. She has a zillion interesting brain factoids but one relevant one is the allure of the "inconsistent reward".

My paraphrased essence is that we are drawn to situations where there is the possibility of a reward. It has to be Goldilocks: never being rewarded is daunting; being rewarded too easily is boring. This phenomenon explains computer games, gambling, ...

And unit-testing, IMO. I have said before that unit-testing is fun: "like getting a row of limes on the Turing Slot Machine. It is an electrochemical buzz, broadcasting to our dopamine receptors." Personally, I find a palpable tension while the tests are running, just before the outcome.

A thought for a Friday: Maybe the Java IDE's should represent JUnit results as the spinners on a mini slot-machine? "Big money, no whammies...."

The Big Tent

I recently attended a StL Java SIG meeting: a presentation on JRuby by Mark Volkmann.

As a Groovy fan, I have been a bit concerned about the press on JRuby lately: it's well known that Sun hired 2 major guys (Nutter and Enebo) for JRuby support, and had big plans to hit JRuby V 1.0 at Java One (they hit V 0.9.9 -- is Wayne Gretzky on the design committee?)

With all this hoopla, I wondered: what's up with Groovy? After all, 2 years ago when I was into Jython, Groovy had all the mindshare, with its own JSR etc. I can't keep up...

Some comments at the Java SIG expanded my view, though... To borrow an analogy from the American political parties, I've realized that the JVM is a "big tent" which can acommodate a lot of players and viewpoints. There's room for all kinds of tools and languages. I recently heard on Java Posse that there are dozens -- hundreds! -- of languages that run on the JVM. Someone pointed out that Groovy is doing just fine on its own: it has left the nest and doesn't need Mama Sun anymore.

A final thought: in the Microsoft world, a big initiative for one language does not necessarily spell bad news for the others.

A Bumper Sticker for Java Concurrency

Bloch recommended ... that final is the new private. Mark all fields final by default (blank final is OK) and only remove final if you an demonstrate a need too. This encourages safety and immutability.

-- Elliot Rusty Harold on Joshua Bloch's Java One presentation (it isn't clear who coined the phrase)

Easter's Laws of Concurrency

I've been reading Brian Goetz' Java Concurrency in Practice. It has some mind-expanding thoughts on how subtle it can be to have threading problems in Java (or any language).

The book, and Amdahl's Law, has inspired me to codify a warning to junior developers (apprentices, in the parlance of Code to Joy), and as a reminder to the senior devs (composers).

Preface

A program is said to be thread-effective if it is:

• (a) thread-safe
• (b) efficient with respect to concurrency (e.g. throughput, UI responsiveness, etc)

Define a program's probability of thread-effectiveness (PTE) to be a metric ranging from 0 to 1, where 1 is complete certainty of thread-effectiveness.

Easter's 1st Law of Concurrency

If you don't know if your program is thread-effective, then its PTE is approximately 0.

Easter's 2nd Law of Concurrency

If you think that your program is thread-effective, then its PTE follows the specified equation:


where:

• C is a random constant between 0.01 and 0.025
• E is experience

Experience is difficult to define in practice, but an approximation is:






where:

• P is the number of programs successfully debugged with respect to thread-effectiveness
• B is the number of books read (in their entirety) on thread-effectiveness

Easter's 3rd Law of Concurrency

If a progam's thread-effectiveness is not optimal, problems will eventually manifest themselves. This manifestation will follow neither Murphy's Law nor the related Law of Demos.

Instead, the problems will manifest themselves, in production, long after you have moved onto other issues and have forgotten the intricacies of the design. This will leave you to rely on the quality of design and documentation as the primary means of fixing the problem.

JVM Tunneling

I've blogged on this idea in the past, but didn't have a term for the thought.

Define JVM Tunneling to be the phenomenon where certain languages, by running on the JVM, encounter ultra-low resistance as a proposed addition to a project or organization. The most successful JVM tunnelers are languages that compile to bytecodes and whose installations require the addition of a single jar to the classpath.

Primary examples are Groovy and JRuby.

One Word for Your Career: Lemmings

To be a virtuoso code composer in Java (or any language), one needs to understand concurrency and the memory model of the platform.

Many of us, myself included, should study and learn as much as we can about these subjects: they truly separate the masters from the apprentices.

The best resource going these days for Java is the book Java Concurrency in Practice. Get it. Just get it. After all, at your next interview, some of your competitors will have read it.

Here's a blog on a study group for the book.

re: title. What's with the lemmings you ask? Many, many moons ago in grad school, I played a wonderful computer game called Lemmings. The gist was that there were many lemmings who would flow from one place to another. They weren't very bright. The game-play was for you to control gates, ramps, and other control structures to guide the little buggers to safety, and to prevent them from causing chaos.

As the levels ratcheted up, the game became frenetic, both in terms of speed and the number of lemmings. I would play with a girlfriend -- one would observe and shout out shorthand commands; the other would operate the devices.

I now realize that we were pair-programming in a multi-threaded environment. If you played the game, you know that the analogy is profound.

ps. From the "brushing teeth after posting dept": this is crazy but I wonder if something like Lemmings could be used to visualize tests against multi-theaded programs. Sort of like a generalized, 2D version of JUnit's green/red bar. As you run the program, the display shows threads (lemmings) exploring the program/data space. It wouldn't be used to prove correctness but rather to show, visually, what is going on for a given execution. It might be illuminating.

pps. An idea that is much smaller in scope. If UML is used to represent the relationships and contracts between objects graphically, is there any such representation for concurrency?

Life After Ant

Here's an interesting post on new-age build tools like Rake and Gant.

A moderately new thought (for me) on build tools:

Things that we use _all the time_ tend to resist change. For example, in natural language, the verbs “to be” and “to have” are notoriously weird because they aren’t made “regular”, as is the tendency with less-used verbs. We don't think about "to have" or "to be": we just use them. All the time.

Similarly, build tools have amazing resilience. The industry suffered with ‘make’ for decades. The fact that Ant saved us from ‘make’ is enough for it to go into the Hall of Fame.

I'm in no hurry to see Ant go away. I am intrigued though by Gant.