Skip navigation
ANNOUNCEMENT: community.oracle.com is currently Read only due to planned upgrade until 29-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

Google released details about the Dart language today, and I am surprised howmuch more it is like Java than like JavaScript. I had expected either a prototype-based language, a streamlined JavaScript (boring), or something like Newspeak (interesting). The latter seemed plausible because Gilad Bracha is on the Dart team. But it's very Java-like, with optional typing.

class BankAccount {
  var _balance; // _ before field name makes it private
  BankAccount(this._balance); // short form for boilerplate constructor
  deposit(amount) { _balance += amount; } // no param, return types
  withdraw(amount) { _balance -= amount; } // automatically public
  get balance() => _balance; // property getter
}

main() {
  BankAccount acct = new BankAccount(1000); // var acct = ... also ok
  acct.deposit(100);
  acct.withdraw(500);
  print("balance: ${acct.balance}"); // string interpolation
}

Unlike Scala, it's not an expression-oriented language, but if a method merely returns the value of an expression, you can replacefoo(args) { return expr; } with foo(args) => expr;

(Yes, that semicolon is required. This isn't JavaScript.)

Like in JavaScript, we have closures.

main() {
  var balance = 0;

  deposit(amount) { balance += amount; } // Updates variable from enclosing scope
  var withdraw = (amount) { balance -= amount; }; // Function literal
  
  deposit(1000);
  withdraw(100);

  print(balance);
}

There are interfaces, just like in Java. Interfaces declare abstract methods, setters and getters, and factories.

interface Account factory BankAccount {
  Account(balance); // The factory class must supply such a constructor
  get balance();
}

class BankAccount implements Account {
  var _balance; 
  BankAccount(this._balance); // Here it is
  get balance() => _balance; 
}

main() {
  var acct = new Account(1000); // Constructs a BankAccount
  print("balance: ${acct.balance}");
}

There are generics, but the type parameters aren't taken very seriously.

main() {
  List<String> names = new List<String>();
  names.add("Fred");   
  List<Object> objects = names; // This would not work in Java or Scala
  objects.add(new Date.now()); 
  print(names[1]); // Now names has something that's not a string
  print(names[1].length()); // A runtime error 
}

Technically, all type parameters are covariant. Scala programmers would wince—they except the static type system to catch errors such as this one. Of course, there is a price to pay—variance annotations,  wildcards, type bounds.

There is a tiny library, but you can't get at the library source from the documentation. This isn't Scala or Ruby. Get the source from here.

Who needs that clunker? The stated goal was to have an alternative to JavaScript, with a more perfomant VM. Apparently, there are currently roadblocks in efficiently compiling JavaScript. (Dart can also be compiled into JavaScript, but that seems more of an interim solution, until that happy time when every browser has a Dart VM.)

Will web programmers give up years of experience with JavaScript for another language, just because it compiles better or scales to larger projects? Probably not anytime soon, and Google knows that.These peoplethink that Dart will be the new vehicle for GWT. I suppose GWT is important, but is it that important?

That's where the poison dart conspiracy comes in. Where could a shiny new language and VM be required? There is that other Google toolkit that doesn't run on the web but on devices that are connected to the web. Right now we program them in Java—familiar old Java, but with a different UI toolkit and a different VM. That may not always be the case.

When I first heard this, I wasn't so sure, but now that I had a glimpse at the language, I agree that Dart would make a perfectly good language for Android. Maybe it will be used for web and mobile programming. Google would like that. For us Java developers, it would not be such a happy development—another nail in the coffin of mobile Java.

Another day, another keynote. A fellow from IBM talked about cloud stuff. I sat through a lot of nebulous cloud talks, but this guy was good. He had a sensible slide on architecural alternatives, explained why we should all go out and buy a device for a ”data grid”—a memory device for sharing data among VMs—and he gave a demo of some software for configuring an app to run on their cloud server. Clear and to the point, like a tech talk should be. It had nothing to do with the “community” theme of the keynote, but you can't have everything.

Sharat Chander made the obligatory comment how the Java language was not all that important, but that the most important element is the community. I used to think that was just talk, but today, it made me think of a programmer who was ticked off for having received condescending answers on the mailing list. He wrote on Reddit “I tried to use Scala, and found it has one major disadvantage going for it, the community.” I can see his point. The Scala community can sometimes feel like a faculty commons room where everyone wants to prove that they are the smartest one. Martin Odersky, the creator of Scala, posted a plea on the mailing list to be kinder to newcomers, and it started a long discussion, some civil and some condescending. Apparently building a language is easier than building a community.

I had never quite realized to how much effort it must be for Sun and now Oracle to build that community. They do put a lot of thought into it. There is community involvment at multiple levels (JCP, JUGs, champions, education, etc. etc.). Managing that costs time and money, but I think the results are quite spectacular. When I work with other technologies, it is normal to see vendor support for fanboys or “valuable partners”. It is rare to have support for a vocal bunch of people who forever complain—because they love what they have but want it to be even better.

John Duimovich from Eclipse was on the stage and said that maximum effectiveness requires transparency. But it's hard to do. It's a culture change. It requires reinforcement from management and a sustained push from the community. Sharat asked ”How patient should we be?” His response: “You should be very impatient.”

That's how I feel about open-sourcing and standardizing JavaFX. Very impatient. I don't quite see why I should have to wait until the end of 2012 to run it on my favorite development platform. After the keynote, Peter Pilgrim (a fellow Java Champion and early JavaFX user) reminded me that JavaFX used to be in an open-source repository, but Sun closed it up.

JavaOne content will be available on parleys.com. Make that somecontents. 40% of presentations will be released, starting with 20 talks and today 3 talks a week throughout the year. Parleys is hosting the content for free, but Oracle has to do the video production, which is not cheap. Stefan Janssen from Parleys suggested that the audience should put pressure on Oracle to have all talks available :-)

A fellow from Rockwell came to say how his company loves embedded Java. Then he left.

Come on guys—with embedded Java, you can show stuff. Robots, machinery, dials and gauges, whatever. Bring it on the show floor or, if it's too big, show us a movie. James Gosling used to have a toy show at the closing keynote. Bring it back!

The Sodbeansenvironment got a Duke's choice award. It allows visually impaired people to work in a modern programming environment. They have an “omniscient” debugger that can step backwards in time (and, of course, also forward like the usual debuggers). It talks, informing the programmer how the program state changes. They are also working on a programming language that is especially suited for screen readers, which sounds like a very interesting design challenge. It will soon come to the Java VM.

Finally,  jHome is an open-source home automation system, built on GlassFish and Arduino. What is it good for? It can control lamps, locks, thermostats, and most importantly, in the home of a programmer, the coffee maker.  You can use CDI to inject a CoffeeMaker object into your JSF page, and use an EJB timer to turn on the coffee maker in the morning. “What does the j stand for?” asked the moderator. 

Being a sucker for talks with snazzy titles, I went to “HTLM5 and Java: The Facts and the Myths”. It turned out to be about Project Nashorn, the new and improved JavaScript runtime for the JVM. It is a myth that this has any useful connection with HTML5. There was a proof-of-concept demo of Webkit running Nashorn, but so what? What's the chance of IE, Chrome and Firefox ditching their JavaScript runtime for Nashorn?

I finished the afternoon hanging around the Mason Street Café, talking to various Oracle people who weren't supposed to talk to me on account of my bright orange press/blogger badge. Later it was suggested that Google's new programming language, Dart(which is described as a JavaScript replacement) might give Google a way of replacing Dalvik on Android with a JavaScript VM, giving them an out if the Oracle/Google lawsuit doesn't go their way. If so, it's even more unlikely that Chrome will want to switch to Nashorn.

Overall, the message that I got from this year's JavaOne is that Java SE and EE are alive and kicking. Finally, we have a good roadmap for Java SE 8 and 9. Java EE is doing great under an open process, and I am pretty confident that Java SE will get there (maybe not quite as quickly as I'd like). After four years of false starts, JavaFX has finally found a home as the presentation technology in Java SE. I just re-read my Java One blog from four years ago. At the time, my reaction to JavaFX was that I needed a new scripting language like I need a hole in my head, and I didn't want to write Flash in Java. I just wanted better client-side Java. It looks like that's what we'll finally be getting.

The conference location was ok, nowhere near as nice as Moscone but not terrible. The best part was the Mason Street Café, the block of Mason Street between the conference hotels. Attendance was up, and I ran into lots of very interesting people—that (and not my love for keynotes) is the real reason why I love going to Java One. I look forward to Java One 2012.

The Script Bowl is another JavaOne tradition. The candidates were JRuby, Groovy, Scala, and Clojure. The JRuby pitch was simple: Use Rails for your web apps, and you are on your way to untold riches. The Groovy pitch was, I kid you not, that you can write fluent interfaces without parentheses, like 

 

take 2 pills and call me in the morning

instead of

take(2.pills).and(call).me(in).the(morning)

Dick Wall showed off how to use the Scala REPL to take apart some XML. He also presented Kojo, a Scala environment for teaching math and programming to kids.

We all know that Scala is complex and scary, and Dick had to be a bit careful not to scare the audience with horribly complex Scala code such as

repeat (4) {
  forward(100)
  right()
}

When preparing their presentations, one of the other fellows accused Dick of cheating. “That's not Scala”. Umm, actually it is.

The Clojure demo didn't go so well—I am sure it was all great magic, but it was difficult to follow what was happening. The winner was chosen by acclamation. Clearly, the audience loved Scala the best, but the game was rigged. Scala and Groovy were declared the co-winners.

I went to a presentation on ”non-Scala languages for Java EE development”. The presenter started out with some Scala bashing, showing the obligatory block of incomprehensible Scala gobbledygook:

public static <T,U> T[] copyOf(U[] original, int newLength, Class<? extends T[]> newType) {
    T[] copy = ((Object)newType == (Object)Object[].class)
        ? (T[]) new Object[newLength]
        : (T[]) Array.newInstance(newType.getComponentType(), newLength);
    ...
}

Oops, I messed up, that was actually Java, straight fromjava.util.Arrays. But whatever—every language has its bizarre parts.

The presenter talked about Fantom and Gosu, showing off a lot of syntax and unfortunately very little semantics. In my advanced programming class, I do it the other way around. I carve out the minimum feature set that leads to an unusual and mindbending feature, such as Ruby metaprogramming, and then show off some amazing magic that one can't dream of doing in Java. My students complain that I skip over the first 95% of the user manual and only cover the last 5%. Umm, yes.

I was wondering where the JavaEE angle came in. There are several teensy web frameworks in Fantom. And the Fantom fans started working on an ORM. The speaker noted that it is a problem that one needs to replicate all the usual infrastructure when one comes out with a new language. Umm, yes.

During the scripting shootout, someone asked about web frameworks. Rails. Grails. Lift. Play. But nobody mentioned my favorite enterprise framework for Scala: good old Java EE. I program my managed beans, session beans, entity beans in Scala, and take advantage of shorter and more concise code. Call me lazy.

Talking of lazy, I went to a talk on the Java 7 file system improvements, one of the more underappreciated improvements in Java 7. Now there are one-liners for common tasks.

List<String> lines = Files.readAllLines(path, UTF-8)
Files.copy(source, target)

Thank you!

In the afternoon, I saw a presentation of OpenEJB, Apache's EJB server whose claim to fame is that you can start it up via public static void main. That's really useful for unit testing. I had looked at it three years ago when it wasn't quite ready for prime time, but now it looked pretty nice. Check it out for testing your session and entity beans.

I ran into Michael Kölling and Ian Utting, who are here to secure continued funding for their GreenFoot and  BlueJ projects, excellent programs for teaching Java programming to high school and college students. I use them in my own teaching, for visualizing objects and as stepping stones towards a professional IDE, and can highly recommend them for anyone who teaches Java.

Will Oracle fund them like Sun did? Yolande Poirier, the community outreach manager, was about to tell me, but then she spotted my bright orange press/blogger badge, blanched, and said “I was told that I can't talk to you”.

I very much hope Oracle continues the funding. Particularly on the high school level, computer science education needs all the help it can get, and then some.

Here I am, on my second day of Java One. I live in the residential part of San Francisco and get to the conference on a battered “express” bus that stops at every block, starting from the ocean until it reaches mine. Then it  goes straight downtown, but by the time that I get on, it is standing-room only. I make it to the keynote frazzled but just in time. Today, I realize that the empty chairs labeled “Oracle Press” are not for the publishing division of the Oracle corporation but for scribblers like me.

The conference organizers are on a roll with the “baffle the audience with a pointless intro” meme. This time, it was a fellow from Juniper Networks who admonished us earnestly that our apps need to talk to the Network, tell it what our needs and aspirations are, and reap untold benefits in return. I got his point, and would have gotten it in five minutes instead of thirty, and I'd be glad to translate it into action if he had given us the tools to do so, like (hint, hint) a Java API, the kind of stuff one might expect at a (cough, cough) Java conference. Next time, I'll just skip the first half hour. I can learn.

Afterwards, it was fine. Adam Messinger introduced the preview of JDK 7 for the Mac (applause) and lauded the fact that the JCP was back on track. He said that over a million people use NetBeans actively, and that Oracle loved it. I really think they do.

JDK 8 is projected for  a 2013 release, 2 years after JDK 7. After that, they envision a 2 year cycle for JDK releases, just like it was in the olden days. That makes sense.

We now  have a good idea what is going to be in JDK 8: closures (AKA lambda), modules, date/time, Coin 2, and the usual miscellaneous library changes. It's ambitious but doable.

And then there is Java FX. Numerous people told me (despite being told not to say anything to anyone with a press/blogger badge) that Swing is being put out to pasture, that nothing will happen to it except critical bug fixes, and that any client-side Java development should transition over to Java FX.

I am all for that. I perfectly believe that Swing was at the end of its evolutionary path. Everything that I see about FX points in reasonable directions. Decent components. A Java API that looks even better in Scala or Groovy. An XML markup language with CSS and JavaScript. Media support. Cross platform.  Eventually. (A Linux version isn't expected until the end of 2012, even though it was previewed today. What's with that? )

Oracle wants to open-source JavaFX, and they want to standardize it through the JCP. I think that is excellent. It is to their credit to have stuck with the good parts of JavaFX throughout a rather rocky history.

What is not so excellent is that they want to do the standardization after they ship it, “co-bundled with JDK 8”. It would be very difficult to change a product after it has been shipped to millions.

We have learned a great deal in recent years about standards, and how they function. Rubberstamping doesn't work too well (OOXML). Standardizing in a vacuum doesn't work too well (JSF 1). It's much better to take an existing product and extract the best parts (Hibernate -> JPA). JavaFX is at the part where it is ripe for being harvested for the best ideas, by a group consisting of the stakeholders who need to live with it for the next 20 years or so. The enterprise users who want to deploy it on something else than consumer laptops. The folks who want to use it on embedded devices. The ScalaFX and GroovyFX library providers. The time to start the JSR is now, not in 2013.

Maybe I am barking up the wrong tree? Maybe desktop applications are going the way of the dodo bird? With Windows 8 and Metro, Microsoft seems to say that the traditional desktop is dead, and we need a skinnable, lightweight, touch-oriented UI instead of WIMP (windows, icons, menus, and a pointing device). Like iOS and Android on cell phones and tablets. Or maybe it's all going to be in the browser, with HTML5? That's the idea behind the ChromeBook which gives us just enough OS to launch Chrome. In all those scenarios, client-side Java as we know it doesn't have a chance (except perhaps in vertical markets), and it doesn't much matter what happens with JavaFX. At least with the module system, it will be easy enough to suppress.

But my feeling is that there is a continued need for the desktop. Information consumers won't care, but information producers do. Someone needs to write code, write books, do art layout, run complex calculations. The desktop has been pretty well optimized for that. Java and JavaFX have the chance to dominate that market while everyone else chases consumer tablets. So, I hope that Oracle builds a community that shapes the design of JavaFX. Letting go and opening up is tough at first, but as the EE space has shown, the rewards are great for those who remain patient.

That's been a long article. The big news is that Java SE is back on track with a good plan behind it. I have more tidbits in my notes, but they are fairly minor in comparison.

At the JCP party, a bunch of us talked about the good old days of 2000 page reference books like Core Java or Graphic Java. Those days seem to be gone for good. Everyone said that nowadays one looks differently for information. Solve a problem and move on. Google. Safari. Blogs. E-books. Last year I was on sabbatical in Vietnam, and I didn't bring any paper books. I thought I'd miss them, and I did at first, but now, I'll take a PDF any time. It's easier to search.

That's why I am writing “Scala for the Impatient” differently. No long-running examples. Each page needs to stand on its own. Is that good or bad? It's certainly different. What do you think? Do you long for a complete reference on Scala, HTML5, JavaFX, whatever? Or do you want recipes and tips?

On a final note, when we returned from Vietnam a couple of months ago, we brought with us the three young cats that lived on the roof adjoining our house. We had been feeding them and brought them here since it didn't look like they'd be making it on their own. Well, actually, make that seven cats. One of them was pregnant and gave birth to four adorable kittens. Lots of pix here. Oriental shorthair. Charming and low maintenance. If you live in the Bay Area and are interested in one, please contact me or Wonder Cat Rescue.

Today, JavaOne started officially. With the traditional keynote. Except, traditionally, the keynote is in a huge room that has space for everyone. Today, people were shunted into overflow rooms where they could watch on monitors. In the age of the screencast, that seems pointless—why is that better than watching on your laptop?

I figured I'd just muscle my way through to the press area, thanks to my press pass. Except there was no such area, so I boldly sat with the Oracle executives. Nobody kicked me out, probably because they were all advised by Legal not to talk to any press person.

Tradition dictates that the first keynote is filled with an exciting outlook of the future, perhaps with some boring parts at the end. Not today, though. They got right to the boring parts. A fellow from Intel and a fellow from Oracle bantered about how Intel was helping Oracle and Oracle was helping Intel. Improving Java performance. On the Intel platform. Improve it they did. By a gabazillion percent. Several engineers joined the stage. And talked about how Intel assisted Oracle. And Oracle was forever grateful. For improved performance. By unbelievable percentages. It was painful. More painful for me than perhaps for the rest of the audience, because I was seated next to a high-ranking sales official from Oracle who chuckled at every one of the lame jokes told by the marketing people on the stage, in the way that only marketing people can tell them. Chuckle he did, in the way that only sales people can. Painful it was.

After half an hour, things got better, and Mark Reinhold gave a perfectly coherent presentation of Java 7 (watch the screencast if you've not heard about Project Coin, invokedynamic or the fork-join framework before). He gave a brief overview of what to expect in Java 8 (delayed to sometime in 2013). Closures (project Lambda), modules (project Jigsaw), date/time API. An ambitious release. He tossed about some ideas for Java 9. Self-tuning JVM. Improved native methods. Big data (> 4GB). Reification (i.e. no type erasure, no it vs. Int). Tail recursion optimization. A meta-object protocol. Multitenancy—multiple apps running in the same JVM. These are all tantalizing ideas, and I'll be glad if some of them make it into Java 9. After a long period of near inaction, things seem to be happening.

Next, Richard Baer showed off Java FX version 2. The most important aspect of it is that it is cross-platform (his very words). That' s why they released it today. Exclusively for Windows.

A developer preview for the Mac is on the works. Linux? Not yet. Does it work with Citrix? Remote X? Umm-—maybe not. It relies on accelerated video (which is good when it is there—Swing had a hard time with that). There may be a fallback to plain old unaccelerated video, but what about media? That will eventually be handled by falling back to the platform capabilitites. Just not yet. It will be cross-platform eventually, I am sure. Cross-platform is hard.

Linda DeMichiel gave a preview of Java EE7. Small but welcome enhancement in the core APIs, alignment of managed beans and CDI, and, most importantly, a standard cloud API.

I felt sorry for the last speaker, Hinkmond Wong, who got to speak after the time for the keynote had elapsed. He talked a good game about Java cards and embedded devices. But when it came to cell phones, the audience didn't buy it. Actually, yesterday Terrence Barr told me that the keynote would have some story about some fellow meeting his inlaws in an Indian train station, using a location-aware phone app.

But the actual story being told was about a train station inOakland, CA. This makes no sense. The Amtrak train from Sacramento to Oakland is often very late, probably much more so than a train in India, so the need for such an app is plausible. But it is absolutely unimaginable that the travelers andthe son-in-law would have managed to install a compatible Java app on their cell phones—likely from different carriers, both with punitive charges for installing or using apps on a feature phone—that let them exchange location information.

I left in disgust, but I left to late. By the time that I arrived at my next presentation, all seats had been given out. The good news is that this year, Java One attendance more than doubled (after having fallen by over 50% last year)—that's the most accurate information anyone at Oracle was willing to commit to, provided I hid my press badge. The bad news is that basic commodities such as snacks, paper towels and soap in the bathrooms, seats in presentation rooms, or IP addresses for the wireless network run out quickly.

Fortunately, all turned out well. I ran into the folks at Typesafe.com, the company behind Scala. Go there and click on the link that looks like this to get the first chapters of my upcoming Scala book.

Behind the booth I spotted Paul Phillips, my Scala hero who patiently answers thousands of questions on the Scala mailing list, fixes huge numbers of compiler bugs, and knows more about Scala than I can ever hope to. Except, he didn't answer my last set of questions. But he more than made up for that failing. He fixed the most serious issue on the spot, beating the compiler code into submission before my very eyes. Humbled, I promised to do the research on the other issues.

In the afternoon, Alex Buckley (who is still not authorized to speak to me and who incautiously let it be known that this is so because he had not received the proper training for talking to the fourth estate), talked about Project Lambda. It's hard to imagine for us hardcore closure fanatics, but less than 5 percent of the audience are actively following the Project Lambda mailing list. What they are doing instead with their little lives I cannot fathom :-)

So, for me, the big revelation was that it's skinny arrow->, not fat arrow =>, that is going to be used for anonymous functions such as (x, y) -> x.length() > y.length(). (A month ago, Brian Goetz described a highly scientific process  that led to choosing fat arrow. But that was then.) And that transforming collections doesn't yield the same collections (as it does in Scala). For example, if a is anArrayList<String>, then a.map(x -> x.length()) gives an Iterable<Integer>, not an ArrayList<Integer>. In Scala, you'd get another collection of the same type (or nearly the same type—for example, (1 to 100).map(_.toString)yields a Vector since it can't very well yield anotherRange.) It's the poor man's solution, as Alex admitted, but that's all that the Java type system can afford.

Being a sucker for talks with offbeat titles, I attended a talk on project Jigsaw (the upcoming module system) entitled “Find the corner pieces first”. It was a good, hands-on presentation, walking through the basics of making modules, specifying dependencies, and constructing applications. But then people started asking questions. What about applets that require modules from the cloud? Can they pollute the module repository with evil modules? How about apps  with the usual set of specific Apache Commons dependencies (what I call the Tragedy of the Commons)? What if people cluelessly bundle bad modules? Should they be signed? By whom?  It seems to me that there is a fair amount of work to be done. So, it's probably a good thing that Java 8 is pushed out a bit.

Tune in for more cutting insights tomorrow—that is, if I can get people to talk to me despite my bright orange press/blogger badge.

Once again, I got a blogging pass to JavaOne—my fifth year as the intrepid reporter at JavaOne, and my 15th JavaOne attendance. Sadly, that wasn't enough to get me the coveted Alumni badge—my email address wasn't in the right Oracle database, and showing my previous conference blogs didn't impress the conference staff. I complained to Sharat Chander, the marketing person at Oracle who is responsible for the tech tracks at JavaOne, and he told me he can't get an alumni badge either.

Oh well, I thought, at least I have a shiny press badge. But when I ran into Alex Buckley, the spec lead for the Java language at Oracle, he had one look at it and told me in no uncertain terms that he wasn't going to be able to tell me anything at all—the Oracle engineers had been explicitly warned not to talk to the press. That's going to make it pretty hard to be the intrepid reporter.

There was a Java champions event with more challenges—the dreaded non-disclosure agreement. I learned interesting stuff that I will only be able to divulge when everyone else already knows about it. Watch this space in the coming days.

I was delighted to run into Stephen Chin, a fellow Java Champion who is the leading force behind ScalaFX, a Scala DSL for JavaFX. (I can't yet tell you why you might care about JavaFX—watch this space.) I always thought that the now-abandoned JavaFX  Script was a step in the wrong direction, and that a DSL in Scala and/or Groovy was the way to go. Sadly, he said that his pleas to get some API weirdnesses fixed fell on deaf ears with the FX team, for laughable reasons of backwards compatibility. He fixed them anyway in the Scala DSL, so that's the place to turn for a sane API.

The GlassFish folks had a presentation of upcoming features, followed by an “unconference”. It  is pretty amazing how far GlassFish has come over the years. A series of speakers extolled its virtues of great performance, ease of configuration, scalability, and support of the EE standards.  An engineer for ESPN described how they started using GlassFish as a better Tomcat, and then they just used the EE features because they are already there, instead of fussing with Spring. That's exactly how I feel about it. GlassFish gives you one-stop shopping, so why use Spring to laboriously assemble the pieces? And if Oracle stops improving GlassFish (of which there are no signs—they are doing a great job with it), there is always JBoss. What's not to like? The presenters were unanimous. (1) The command line interface and the REST interface are great, but the bugs in the admin web interface haven't been fixed in years, and (2) the logs are still filled with the Stack Trace from Hell.

Johan Vos griped about the fact that every Java EE project has to rewrite a good chunk of boring routine code, such as user management (signing up, password reset emails, logging in through Facebook or Google, etc. etc.) It's not something that is likely to get standardized through a JSR, but perhaps there could be GlassFish Extras, just like there have been Swing or JavaFX Extras. It would be great if that idea would take off.

There was a JCP presentation, showing off the latest process changes that hopefully will bring much-needed transparency to future JSRs. Some JSRs have always been great about operating in the open, but others have a mixed record, collecting input through public channels but making critical decisions in smoke-filled rooms, away from the public eye. It's a thankless task to develop procedures for standards committees, and I am glad Patrick Curran and his crew keep at it.

In the evening, the GlassFish party at the Thirsty Bear provided much-needed relief. James Gosling showed up, talking about his new career. Tomorrow, the conference will start in earnest. Watch this space for details!