Skip to main content

Letter from an Occupant

Posted by editor on October 24, 2006 at 7:19 AM PDT

Someone in Java-ville wonders why useless statements compile

One of the key traits of Java is its philosophy of "failing early". Strong typing, among other things, allows the compiler to catch problems that could otherwise linger at runtime. So maybe Java developers invest a certain level of trust in the compiler, thinking that once your code compiles, you've reached a certain threshold. It may still misbehave, but at least the obviously broken stuff has been accounted for. Right?

Maybe not. Today's Feature Article, looks at the curious case of the statement:

if (condition);

This compiles, but it is always meaningless, since the semicolon implicitly creates an empty "then" block. And that begs the question, or more to the point, the not-so-stupid question.
(Not So) Stupid Questions 14: Why Do Pointless if Statements Even Compile? opens up for discussion the idea of whether the compiler should be responsible for catching things that, though they may be syntactically legal, are meaningless, useless, and probably unintentional.

We hope you'll join in the conversation, and think about the big picture. To wit, maybe a semicolon after the if statement is syntactically legal, so it makes sense that it should compile without complaint. If that's your position, then consider the following code:

public class EarlyReturn {
    public static void main (String[] arrrImAPirate) {
        int i = 0;

Does this compile?  Why or why not?  Should it or shouldn't it?

See you in the not-so-stupid question discussion...

In Java Today

the Java Desktop Community notes a fun game applet posted as part of a Japanese-language blog: NekoZori.  The Desktop Community page comments: "the page probably makes more sense in the Japanese locale.  Cat flying around in a boat.  There's something strangely appealing here. The game was included in a roll-up of physics simulation games, more about this particular game here. Also, be sure not to miss the author's zombie game and variations."

  Java 3D 1.5 beta-1 has been released, and adds support for two new platforms -- Mac OS X (via the JOGL pipeline) and Windows/XP 64-bit -- as well as a few new features and most of the planned bug fixes, including  JOGL Rendering Pipeline,  non-power-of-two textures,   NIO image buffer support for textures,   by-reference support for geometry indices,   rendering error listeners, and vecmath accessors/mutators

The transcript of last week's Ask the Experts session on Swing has been posted.  "In this session, Swing Architect, Scott Violet, Swing Technical Lead, Shannon Hickey, Java 2D Engineer, Chris Campbell, and AWT Technical Lead, Oleg Sukhodolsky answered a variety of questions about building graphical interfaces using Swing."

Kohsuke Kawaguchi has an administrative update on some of his projects in System-level projects moved under the java-net project in today's Weblogs: "Over the last few years, I've been involved in many of the 'system-level' projects, which provide tools and services for any project owner. Gary kindly moved them under the java-net project to show the authenticity."

Ben Galbraith is trying to figure out how to deal with
Heaps of Memory:
"Is there a way to determine the largest set of strongly referenced heap data a process creates at any one time?"

Kirill Grouchnikov long-running series on scalable graphics pays off with striking examples in
SVG and Java UIs part 6: transcoding SVG to pure Java2D code:
"This entry on using SVG in Java UIs describes the utility to convert SVG to pure Java2D painting code."

Joshua Marinacci has more to say about SwingX's design philosophy in
  today's Forums.  In

Re: Painter Refactoring: Solving the Layering problem, he writes:
"I've looked through the original thread and come up with a new proposal. In the six months since we originally discussed this I've written a lot more painters and started figuring out what I will really want to do with them in practice. I think that having a layering ability is important, though I want to preserve a simple API. I've also come to realize that there is absolutely no reliable way to separate a normal component's foreground and background. The Windows Look and Feel implementation of a button, for example, does not provide a way to draw the text separate from the background without making specific hacks just for this look and feel. This means we need to figure out how our layering system will address these issues."


has some JDIC work to contributes and asks how to do so in Re: how do I add to cvs so I create a patch for submission?: "I am trying to upload all my changes for the Mac implementation of the TrayIcon service. I have re-read the instructions for submitting a patch, and after following them, (as I expected) none of the NEW files I have created are in the patch file. This is because I am not able to do a "cvs add" on the new files, since I don't have add permission. Since these files are not added to the cvs meta-data on my local repository, when I do the diff and patch, cvs doesn't know anything about the new files so they don't get picked up and put in the patch."

In today's News Headlines :

Registered users can submit news items for the News Page using our news submission form. All submissions go through an editorial review before being posted to the site. You can also subscribe to the News RSS feed.

Current and upcoming Java Events :

Registered users can submit event listings for the Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of it will be archived along with other past issues in the Archive.

Someone in Java-ville wonders why useless statements compile