Skip to main content

Java One 2009 Day 0

Posted by cayhorstmann on June 1, 2009 at 10:37 PM PDT

Today is day 0 of Java One, AKA “Community One,” with a focus on
open source and community projects. With the economy being what it is, and Java
One stretching the definition of “early bird” specials past the
breaking point—the discount was good until today—I was fearing for
the worst, but there definitely were crowds today.

Here are some of my impressions from today.

Guillaume Laforge gave a nice presentation on what is new in Groovy 1.6. An
expanded version of the talk is href="http://www.infoq.com/articles/groovy-1-6">here. I was most impressed
by the ability to manipulate abstract syntax trees. For example,

class Event {
    @Delegate Calendar when
    String title, url
}

All of Calendar's methods are added to Event and
delegate to the when object. In Java, this would be an absolute
no-no. Annotations are not supposed to change the classes that are being
annotated. But Groovy isn't Java, and in a more dynamic world, these
transformations make perfect sense.

I really want to like Groovy, but what is holding me back is (a) the rather
ad-hoc process in which Groovy rediscovers what has been known in other (mostly
functional) languages for a long time and (b) the stubborn resistance to
producing a language spec.

As for (a), consider the sections on ”multiple assignment” and
“optional return for if/else and try/catch/finally blocks” in the
InfoQ article. In
Groovy, you can now write

def (a, b) = [1, 2]

What's with that mishmash of parentheses and brackets? In Scala, you'd write

val (a, b) = (1, 2)

That's because Scala—like so many of its predecessors—has
tuples. And Scala—like so many of its predecessors—has conditional
expressions that return values, without having to wait for version 1.6.

Perhaps I quibble. But the lack of a spec really bothers me. Suppose I add
two @Delegate fields to a class. What happens if one method
signature is shared by both delegates? I asked about the spec, and Guillaume's
response was that a spec was not really needed. The Groovy API documentation is
excellent, and there is an extensive set of test cases. (Note to
self—check that out.) Well, the API documentation for
@Delegate is href="http://groovy.codehaus.org/gapi/groovy/lang/Delegate.html">here, and
it doesn't seem to answer my question.

JSF 2.0 can work very nicely with Groovy, and I understand that the lack of
a spec is making it difficult for the JSF spec to acknowledge that fact.
Hopefully, one of these days, the Groovy folks will get around to a formal
spec.

Dan Allen gave a great presentation on running Seam on Glassfish, and what
pitfalls one encounters. Mostly, the issues are JNDI naming, exploded WARs, and
other distasteful topics. It all adds a dose of reality to app server
portability.

Sharat Chander and someone who admitted to being in marketing talked about
Project Kenai. David Geary and myself are href="http://kenai.com/projects/corejsf">hosting a project there for our
Core JSF book. The site works just fine, but I never understood why it
describes itself as “more than a forge”. The speakers were hinting
at great things to come, in terms of continuous integration, testing, and
deployment, so that will definitely be worth watching.

I met up withDennis Cosgrove of alice.org at
the show floor. If you haven't checked out Alice, do it now! It is a super-cool
environment to teach programming to middle and high school kids. The new
version—now in beta—has two enhancements. It has characters from
the Sims that are a lot smoother than the old wireframes. And you can program
in Netbeans, in addition to the Alice IDE. Next semester, I will try this out
on freshman students, replacing the old “print all prime numbers <
n” with problems that use the Alice cast of characters.

eeepc.jpeg

My favorite talk of the day was a “lightning talk” by href="http://masafumi-ohta.blogspot.com/">Masafumi Ohta on running OpenSolaris on an Eee PC. Now here is a true
hacker. Apparently he even got Second Life running!

Finally, I stumbled into a “bring your own laptop” lab on the href="https://glassfishplugins.dev.java.net/eclipse34/index.html">Eclipse
Glassfish plugin, brought to you by Ludovic Champenois (AKA Ludo). I had
used that plugin with good success, as did my software engineering students
last semester. We used Java EE 6 + JSF 2.0 on Glassfish v3 with Eclipse, and it
all worked out. Except, that there was some flakiness with the adapter. My
students figured out how to solve this by downloading the Eclipse + adapter +
JavaDB bundle that Ludo provides, but I stubbornly refused to do that and ran
into grief when Glassfish v3 updated. It turns out that you need to manually
check the update site for the plugin:

(It doesn't help that the update site is called
https://ajax.dev.java.net/eclipse.)

When the Glassfish plugin broke for me, I had a miserable time testing my
JSF 2.0 examples with Tomcat for the last several weeks. I look forward to
going back to Glassfish! If you are still using Tomcat, you should really have
another look at Glassfish or another app server.

This year, Sun has been very generous in admitting students to Java One for
free. In fact, one of the lab participants who ran into trouble in that lab
turned out to be one of my students—good choice on her part; she is
starting a master's project using this stuff. I ended up being pressed into
service with troubleshooting because she ran Linux. The issue was a space in a
file name :-)

This being day 0, I have no profound observations yet. There seems to be
cautious optimism about EE 6, JSF 2.0 and even OpenSolaris and Java FX on the
conference floor. Interestingly, I ran into a group of my students and asked
where they were going. The cloud talks, duh.

Comments

Cay, I look to you as my eyes and ears at JavaOne when I can't attend in person. Keep up the good work of sorting through the chaff to find the kernels of wheat!

@blackdrag. I think your post gets to the heart of why Groovy is, well, different. You have this parser that has somehow grown organically, and you are at its mercy. In a more formally defined language, one might have stepped back, looked around at the usual constructs (such as tuples and statement values), and developed a grammar capable of dealing with them. When I say "I want a spec", I want to know what exactly is the valid syntax of the language and what is the semantics of the language constructs, at a level of detail that allows (1) a user to understand the behavior without running experiments or reading implementation source and (2) an implementor to provide an independent implementation. I think Groovy has moved far enough from Java that a "diff from the JLS" approach isn't going to work out too well. I agree that quite a bit of the spec can be in the form of API documentation, but the quality of that documentation would need to be improved. Many JSRs have successfully produced specs with mixtures of narrative and API docs that were appropriate to their problem domain, so this can be done. For Groovy, I imagine that the narrative would include the grammar, control structures, type system, object model, metaobject protocol, and annotation processing.

Cay, I must say I do wonder about you. Here you go and say that you don't like the way the Groovy people rediscover functional stuff, and then all you provide as example is multiple assignment. I think that is unfair to both. Unfair to Groovy and unfair to functional languages. Functional languages are so much more than optional returns in structures they may not even have, or to have something like multiple assignment. If that is really all Groovy has to learn from functional languages, then it sheds a totally wrong light on what Groovy has still to learn. Having optionals of any kind is to me no part of being a functional language. Then multiple assignment... you cannot really say that is a feature that got suddenly in out of nowhere. http://jira.codehaus.org/browse/GROOVY-158 is 5 year old feature request and http://jira.codehaus.org/browse/GROOVY-1543 is 3 years old. There were simply more important other things to handle first. Then about the syntax... you cannot compare Scala and Groovy here. They have both a very different syntax when you go to the parser level. Same it is when you compare Java and Groovy. It is true that the Groovy parser is originally a Java parser, but it got modified so often and so much, that the Groovy parser developed into a completely different direction. Only on the surface they share many equal things. The originally targeted syntax was "def a,b = x,y". Now the parser did not easily allow this. Groovy has no notation of tuple like Scala has, so both x,y or (x,y) couldn't reuse existing constructs. The only thing Groovy has as some kind of tuple is the list syntax, which makes it [x,y]. Then the thing mostly equal to Scala would be: "def [a,b]=[x,y]". But again this was a problem, because in Groovy types and variables share the name space (unlike Java) and "foo[a,b]=[x,y]" had already been valid already if foo is no type. To not to enlarge the problem with variables and types sharing the name space a different solution had to be found, and that was then "def (a,b) = [x,y]". And since "foo(a,b)" is normally a method call the parser has to go till the "=" to actually recognize, this is a multiple assignment. It is still not a very nice solution then, but the alternative would have been to not to add it then... again!... remember? 5 year old feature request? And because I am at it, let me tell you something about (b) too. Being stubborn about writing a language spec? That implies we don't want to, never tried to, we don't intend to and we see it as wrong doing so. That is wrong, 4 times. Yes, we had several tries already. We tried to write a GLS as a delta to the JLS for example. But got stopped because the question of copyright became very unclear and we did not get explicit permission from the sun folks here. Also it is not even clear what all has to go in the spec. Groovy is very API driven. Take the API away and you have almost nothing left that differs from Java. Still it does not explain most of the things you see when executing Groovy programs. If we would produce such a spec it would be mostly useless, an alibi spec. And such a spec is really not needed. mean, let use say you read, that a property get action is done by executing the method getProperty(String) and then the spec ends, because all that goes on from there is done by the specific class. Then what do you do? In case of a Groovy builder you would be totally lost. Even in understanding how a Groovy Closure works, this would not help you at all. So when you say: "I want a spec!". Then you should actually tell what you mean with that.