Tempers Erupt at Conference: Multi-Line Strings in Java

CodeToJoy Newswire
Satire City, CA
Jan 30, 2008

At a recent Java conference, tempers flared and developers ultimately took to the streets in protest over a controversial feature proposed for Java 7.

Prior to the conference, the proposition of multi-line string literals seemed benign: the concept is not new, and is found in many languages. An example:

String thePoint = """
i still
love
java""";

Unfortunately, the issue exposed deep philosophical divisions within the Java community, and civic unrest ensued.

The School of Grafters

At the main presentation, one academic group pitched their proposal for multi-line string literals. Their thesis:

• "In another thirty years people will laugh at anyone who tries to invent a language without multi-line strings."
  
• This new feature will free programs of much of their accidental concatenationicity.
  
• Multi-line strings can be seamlessly woven/grafted into the language, without an extension to the existing Java type system.
  

Though the other speakers showed signs of dissent, the presentation went well until the final point:

• The implementation of multi-line strings could be a straight-forward application of Generics.

At this point, the crowd began to shift uneasily and talk amongst themselves. Several presenters from the panel began to openly question the proposal. Finally, after a moment of chaos, the moderator brought the segment to a close, and introduced the next speaker.

The Block Camp

From the outset, it was clear that this group was more conservative, and desired to block the proposition. The presenter made the following points:

• The usage of multi-line strings will encourage an exotic style of string concatenation, possibly fostering dialects and hindering string portability.
• A new feature should have a minimal addition to the lexical surface area: surely the + symbol has a higher power-to-weight ratio than """.

Again, the speaker was persuading the audience until the final point:

• James Gosling wrote, circa 1997, that Java is a "blue collar language" which modestly gets the job done. It's practical, not theoretical!
  

At this point, an audience member yelled, questioning a rumor that Gosling was a member of the School of Grafters. Another asked what Gosling thought of the issue in 2008 (versus 1997). Chaos threatened to erupt again, until security guards ominously appeared at the door of the auditorium.

The Junkies and Dead-ends

Finally, the last speaker on the panel walked to the podium. In a quiet voice, he confessed that he was a feature junkie and that he represented a group of developers who were irrationally drawn to new features such as multi-line strings. He described the inner turmoil of being a junkie: living with both feature lust and also the burden of backward compatibility. His only solace was to consider Java a dead-end with respect to new features.

It was a tender moment, until his conclusion:

What's the big deal anyway? Why not use multi-line strings in Scala, compile the code down to bytecode, and just use that?

At this point, the crowd erupted for the final time, streaming past the guards, and spilling into the streets. Soon, they carried placards and bull-horns, appealing for unity.

The mob protested for several hours until, finally, local police brought in staff from JetBrains to hand out free IntelliJ licenses.

Leveraging the Daily Standup

The daily standup meeting is a major conduit of information. I have recently realized that it can be leveraged not only to provide project status, but also to convey useful tidbits, much like the "help tip" that applications provide on startup.

One idea is to pick a theme for a week and have one person, per day, expound on that theme.

Some example themes:

• A favourite shortcut in the Java IDE
• A 30-second explanation of a domain term (in my current domain, microbiology, this is highly alluring)
• A "wouldn't it be cool if?" brainstorm question about your current app

It must be brief, and one must be careful that the standup doesn't turn into a party. It can be fun, but not a long social event.

If a daily tidbit is too much, then pick a particular day (e.g. Friday) and work with that. The point is that, over time, your team can really piggyback some great information on top of the routine status.

Does your team leverage daily standups? Any daily or weekly rituals? I'd love to hear any themes/tricks that you do that are outside of the norm.

myTunes: Groovy and JFugue

I write this from CtJ HQ, waiting on a heat repair. The experience has been rather infuriating. I am tempted to write a personal rant or make a comic , but instead I thought I would make some music with JFugue and Groovy. As I've blogged before, it is completely addictive.

The Setup

My friend and colleague (we need a new term for that), Lance Finney, has written a comprehensive article over at the OCI Java News Brief.

For a blog post, we don't have to be as formal with respect to background, examples, or setup. Let's jump in. Here's the setup:

• Install Groovy
• Put the JFugue jar in the classpath

Examples

The following examples are trivial both from a coding standpoint and musical arrangement. The point is two-fold: (a) Groovy makes everything easier and (b) playing with music is fun. As I've mentioned, this might be a great way to introduce kids to computing.

Eg. 1 Crazy Train

The first example is minimal. This is the main hook to Crazy Train, which sounds rather eerie on the default instrument of piano. (As a musical aside, it is interesting that this hook uses each note in the F# natural minor scale -- quite rare for blues-based rock of that era.)

import org.jfugue.Player

new Player().play("""
F# F# C#6 F#
D6 F# C#6 F#
B A Ab A
B A Ab E
""")

Eg. 2 Ode to Joy

With Groovy's G-Strings, there is a temptation to pick Bach's Air on a G-String. However, this obligation is trumped by choosing part of the extraordinary melody from which this blog's theme is derived. (Check out this tribute by Leonard Bernstein).

(Note: G-Strings are used in the next example. This one has hard-coded rhythm notation.)

import org.jfugue.Player

// q = quarter note, i = eighth note
// the "." acts like the dot in music notation

new Player().play("""
I[60]
E E F G
G F E D
C C D E
Eq. Di D
E E F G
G F E D
C C D E
Dq. Ci Cw
"""
)

Note that I[60] sets the instrument as French Horn. Here is a list of MIDI instruments.

Eg. 3 Waiting for the Repairman Blues

Not that it compares in any way, but here is a little bluesy hook that I wrote on guitar some years back. Thanks again to Groovy's G-strings, we can set the rhythm as a relative variable: this allows one to tweak rhythm settings across an entire piece. (It's easy to see that a DSL in Groovy would be good fit for this subject).

import org.jfugue.Player

// q = quarternote, i = eighth, s = sixteenth
// doo, be, bop are relative: easier to read and tweak

def doo = "q"
def be  = "i"
def bop = "s"
def hum = "w"

def phrase1 =
"D${doo} E${doo} D${be} E${be} C#${doo} A${doo} R"

new Player().play("""
I[55]
${phrase1}
C${doo} F#${doo} C${be} F#${be} B4${doo} G${doo} R
${phrase1}
C${bop}+F#${doo} C#${bop}+G${doo}
C${bop}+F#${doo} C#${bop}+G${doo}
E${hum}+B4${hum}
"""
)

For this example, the instrument is an Orchestra Hit. This has a dual effect: (a) possibly introducing you to a commonly used MIDI sound and (b) distracting you from the rhythm problems in the 3rd bar. (It should be played more fluidly. This is left as an exercise for the listener.)

Bottomline

Try it out... Tinkering in this way is both easy and enchanting. It isn't hard to imagine a custom Ant task that plays homegrown tunes based on the success or failure of a build.

Software Electricians and The Art of Wiring

A friend is working on a web application that uses Seam and Hibernate/JPA. Many POJOs with many annotations. The project has a sophisticated build process involving CruiseControl, JBoss, and Selenium.

Recently, he made this interesting comment:

It's weird that the build XML is much more complicated than the application.

The business logic is non-trivial yet straight-forward. He went on to say that, aside from writing unit tests, much of the work is annotating the POJOs and working with configurations.

To wit, his team employs Software Electricians: they spend most of their time on the wiring, debugging the annotations.

ps. Yes, I'm using "wiring" rather loosely here. It is most often associated with XML configuration; I'm expanding it to include extra-syntacticular logic (i.e. outside of Java syntax).

Language Concertos and the Tech Cadenza

Cadenzas

We are all familiar with extended guitar solos. Until a few years ago, I didn't realize that instrumental solos at rock concerts were a modern day form of cadenza. A cadenza is simply a section of music where "the others" stop playing so that a soloist can take the spotlight, often showcasing tremendous virtuosity. Even if you aren't a classical music buff, you may have seen situations where the orchestra stops and the violinist lets 'er rip (e.g. in a violin concerto).

The concept dates way back to at least the Classical era (circa 1775). Interestingly, in those days, improvisation was a key component. (To quote an old professor: the notion that jazz invented improv is "one of the many lies you've been led to believe".)

In Technology

While reading a post on Neal Ford's blog, I realized that the modern day cadenza for computer languages is undoubtedly Web Frameworks. It is a chance for a given language/platform to really show its stuff. I suppose that it is a relatively beefy opportunity: showcasing MVC, persistence, a web presence, etc.

For one, I would like to see some new problems as cadenzas. At a recent talk on Scala by Tim Dalton, the audience was treated to an excellent exposition of the language. During Q&A, someone mentioned Lift, a nascent web framework for Scala.

Under my breath, I said "oh oh". Now, I haven't used Lift and wish them the best, but I'm not sure that I have room in my brain for another web framework. Plus, I'm enjoying the dueling guitars contest between Rails and Grails.

A New Cadenza?

I haven't used Scala, but of all the features presented in the talk, the true standout is the Actor concept, a type of abstraction for concurrency. For my money, that might be a big opportunity for a new Scala concerto: featuring a MapReduce cadenza.

That would bring me to a standing ovation.

I'm an Isolationist !

Isolationism

No, this isn't a commentary on geopolitical trade agreements or transaction levels. It's a simple idea that re-inspires me every few months.

Long ago, back in C++, Bruce Eckel's books taught me the importance of studying something in isolation. Write a little program: then experiment, tinker, learn.

I'm grateful for his C++ and Java books but I think that this sense of curiosity is the single most important lesson. Naturally, many developers do this -- but not all.

These days, I've been doing a fair amount of work with Hibernate, which has been a learning experience. Early on, I spent about 2-3 hours setting up a sandbox (i.e. an isolated testbed).

That was the best time I have spent in a loooong time. I might post the download to a site, but for now here is the gist.

• Ant, Hibernate, and a text editor (I use jEdit). No IDE.
• Tasks to build a couple of POJOs (plural for mapping associations/collections)
• Tasks to build and run a driver program (for reading/writing/transactions)
  
• Tasks to generate SQL (using Hibernate tools) and rebuild/populate the DB
• An overall task that starts everything from scratch

This is hardly rocket science. But it has been terrific:

• Because the sandbox is not tied to a large project, everything is ultra fast, and available during the main project's compiling and testing.
  
• It is a "headful" and no more. I can return to the sandbox after a couple of days and remember what I was studying. Better yet, I can confidently start hacking on the new problem: the Ant tasks obliterate the old DB so every run is a brand new day.
  
• No IDE means that the sandbox is available if the IDE is busy on your main project. Yes, you do lose code completion but, given the mindset, it's worth it.
• Very little noise: e.g. you can enable SQL logging and actually understand the output.
• The sandbox can be easily shared with others. Believe me, other teammates will usually ask for it, once they see its effectiveness. Any given sandbox instance acts as a type of foothold, which most developers appreciate. Most of us are independent rock-climbers: we don't want hand-holding per se, but we all need a foothold to start from. (Eric generalizes this idea for effective downloads of 3rd party libraries.)

If you encounter a new technology, Hibernate, Spring, web services -- you name it -- build an isolated sandbox. I often fall into a trap where it seems too much of a speedbump to bother, but I've re-learned that it is time well spent...

Many companies are still using Java 1.1 ?

As many blog readers know, Bruce Eckel posted a thoughtful piece on Java vis-a-vis closures and language features. As an aside, he writes:

People who don't want to deal with these changes don't upgrade, and those people tend not to upgrade anyway, out of conservatism. Many companies are still using Java 1.1 for that reason.

That caught my eye. Java 1.1, really?

At the beginning of meetings, the StL Java User Group often holds informal polls to see which versions of Java are being used. From that, and from common sense, I respect that JDK 1.3 and 1.4 are still widely used. I wouldn't be surprised if JDK 1.2 is out there somewhere, in much fewer numbers.

But JDK 1.1 ? To the point that one can say "many companies" ?

An Informal Poll

Enlighten me, readers. Which version of the JDK are you using? What was the lowest version you have used in the last 2 years? I've been on JDK 1.6 for the last 2 client sites, but I realize that is quite rare.

JFugue and The Charm of Computing

(Ed's note: I just flew in from Canada -- and man, are my arms cold. A belated Happy New Year to all the fans/readers/critics of CodeToJoy.)

If you want some fun, check out this article by my friend and colleague, Lance Finney, over on the OCI Java News Brief.

It covers 2 projects for writing music in Java: JFugue and ABC4J.

I have only played with the former, JFugue, but it is a blast! Lance's examples are easy to start with. If you are like me, it is impossible to resist tweaking them to come up with some new melodies.

Also, if you are like me, you might try JFugue with Groovy: it works fine. There are some distinct advantages that I will post later on in the week (hint: G-strings, which may be the only time that term is both salacious and musical).

After reading through the article, I spent some time mapping a little jingle from my guitar to a JFugue program. It was absolutely addictive, and brought me back to the days of no-frills computing in high-school: a time when we truly worked on a program for the pure joy of it. Just a text-editor and some immediate feedback through sounds. Fantastic.

I think JFugue might be a terrific way to introduce children to computing, esp. if they have a bit of a musical background. Don't use the fancy GUI editor: make them hammer it in like we did in the old days!