Jim Driscoll's Blog

JavaOne Archives

JavaOne meetings starting up

It's that time again... JavaOne time. What? Barely over the parties from last year? That's ok - it's in May. But meetings are starting to determine the content for May, and I thought I'd write a quick blog to ask - what do *you* want to see at JavaOne in May? I'm working on web track (again), so web related suggestions are especially appreciated.

My current thought - we're going to have lots of stuff related to modern web practices (i.e., Web 2.0, I don't care for the term). But like last year, it's going to be a balancing act - we can't have every session be "Introduction to AJAX Programming". Besides, we try not to cover things two years in a row.

What do you want to see? Please leave me comments below.

JavaOne Tech Sessions are Up

JavaOne: What worked and what didn't

One thing we'll do is have a Lessons Learned meeting, and I want to be ready - so I thought I'd throw out my ideas for what worked and what didn't, and ask for a little help in working on my list. Here's your chance to kvetch with me!

First, what worked: I thought the talks pretty much rocked. Now, prehaps I'm a little biased, but really, I didn't hit any clunkers. This is the one thing I DON'T need to worry about for the meeting, since we'll have *very* accurate data on attendance and evaluations. But I'm pretty pleased with this, since the talks *are* mostly why you came to JavaOne, right? Also, I thought that the keynotes were mostly OK, and there were some neat demos.

The food at lunch wasn't bad - for cafeteria food, anyway (ok, it's a low bar). And the lines for lunch moved more quickly than I would have thought possible, given just how many people were filing through there.

I'm going to go out on a limb, but I'm going to say that by the last day, the reserved seating thing was working well. Over and over again, I went to full talks, confident that I'd get in. The lines moved much faster, crowd control was better, and they had more card readers and docents.

Then, there's what didn't work: The stage crew was noticably incompetant. I watched a speaker beg for his slides to be shown for about 4 minutes - and this was the third time that that had happened to him that talk. And it happened to him in a previous talk that day. And he wasn't alone. Demo screens only on the left side of the room? Excuse me? There were lots of problems with audio in 307. And ask any keynote demo person about the sysadmins... and you'll get an earful. The WiFi was up and down like a yoyo. But at least the cardreaders worked better than last year - in fact, I think those worked well.

A loud audible alarm went off at the end of a speaker's talk - several commented that they would have liked a more subtle 1 minute warning, though other speakers seemed to have no trouble - by watching the clock up on stage.

I think that covers it - did I miss anything? Tell me below. Both bad and good (so we don't forget to do it next time :-)

See you next year!

Schedulebuilder Tryout - Day 1

In a previous post, I talked about how the people who run the conference were planning on having a new way to schedule and attend talks at JavaOne this year.

Well, first day is mostly done, and I think we've gotten a pretty good idea of how it's working.

My evaluation is "could be better". I've yet to see the first 3 slides of ANY talk that I've attended - and I was registered for all of them. On the other hand - I actually got in to all the talks that I wanted to see - because I was registered (and 2 of them were totally full).

So - what's the problem? Crowd control is an issue - the lines are longer, and take longer to traverse, than in previous years. Which means that crowd control is more of an issue, and was probably not planned for well enough.

Also, if you're going to stuff 1200 people into a room in 15 minutes, how many stations for reading cards would you have? Hint: More than 4.

And lastly, if you've got a real problem with getting people in quickly, doesn't it make sense to open the rooms up as soon as you can? So far, they haven't - rooms were closed until 15 minutes before the sessions started, even if the rooms were free.

So, what can be done about this? Well, it seems clear that in order for this to be successful, we're going to have to put more people on crowd control, and get more badge readers.

I know that the organizers are looking hard at this, and I suspect that we'll see improvements tomorrow. What's your experience? Please comment below.

New way to attend JavaOne talks

One nice thing about being around this stuff forever: You end up on all the interesting committees. I'm on the JavaOne Program Committee, which helps decide the content at JavaOne.

Every year at JavaOne, we have the same problems - some talks are in big rooms, and you can hear the crickets chirp. Others are in medium (600 capacity) rooms, and there are people sitting on the floor - or worse, turned away at the door. We do the best we can at guessing, but it's impossible to get it right 100% of the time. And hastily thrown together overflow rooms are only a patch on the problem.

So, JavaOne is going to be run a bit differently this year. Instead of queueing up outside the talk you wish to attend (or camping in the room prior to the previous talk ending), there's going to be reserved seating.

No, really... reserved seating. You'll be required to register ahead of time for the talks you wish to attend, and everyone who's registered will get to go in first. Only after all the registered people go in will the unregistered people be allowed to go into the room. This also means that the rooms will be cleared after each talk.

I have to say, when I first heard this, I was a little skeptical - the Esplanade, in particular, tends to get really crowded with human traffic at every talk change. Visions of mobs of unhappy people milling about in that narrow corridor quickly sprang to mind. I wasn't the only one who was skeptical, either. But the conference organizers assured us that they'd done the same thing for other conferences as well (many as big as JavaOne), and they had answers for every objection that we threw at them. In the end, we were convinced - moving around 10k+ people is a difficult job, but it's what they do for a living, and they're pretty good at it.

Doing things this way has some obvious benefits - for one thing, it'll allow us to change our plans for how we'll be giving talks BEFORE everyone shows up at the door. It also has some interesting benefits that may not be readily apparent at first glance - such as allowing us to really plan a better JavaOne next year, since we'll finally have a truely accurate attendance number for each talk.

So, I'm optimistic about the process. But it will only work if everyone goes out and registers for the talks they want to attend. So, if you've already registered for JavaOne, please don't skip this step.

As always, I'd love to hear what you think of this idea. Let me know below.

Planning JavaOne

In addition to working on Project GlassFish, as a manager at Sun I get assigned all kinds of fun projects. For the first time ever this year, I was involved in planning the Web and XML track at JavaOne.

Wow, that was fun - we had so many good submissions this year, it was hard to choose, but fun too.

One part wasn't fun - scheduling. Not the part you're probably thinking of - the timing of the talks - that part wasn't so bad: We just tried to only overlap a few talks. No, the hard part was playing "guess the attendance". Should a talk on Shale get a room with 450, 600, 900, 1200 seats? How about a talk on AJAX? How about a web security talk?

What would you pick? Remember, we made these choices 2 months ago.

For Shale, we picked 900. Same for AJAX. Security got 600.

The result? We came close on these, so I'm pretty proud.

Shale had a mostly full room (at lunch). AJAX blew out the room, and filled up the overflow, so we should have gone with 1200. The security talk was SRO (Standing Room Only), and probably would have filled a 900 room too.

I said close, not perfect :-)

Where else did we get it wrong? I'll see statistics in a few months, but I'm dying to know now. Any talks in rooms that looked empty? Any talks with people sitting all over the floor? Let me know, I'm dying to find out...

Also, I'd love to hear about what you didn't see that you wanted to see. Remember, I only did the Web and XML stuff, so you'll have to take your Java ME requests to someone else...

Grizzly Performance ( for the GlassFish Web Tier)

I'm in the Grizzly Tech session, and at the end, they're showing some performance numbers.

For a dynamic content, servlet oriented, non-trivial task, the numbers that they've found show that an all Java NIO implementation will beat out a mixed Java-C implementation. (They tested two.) Mixed implementations are the kind found today in things like mod_jk and Sun's Web Server (though they wouldn't say which they tested). Grizzly's the first NIO type implementation that we know of out there, but if these numbers hold up (and we've beaten on 'em), it won't be the last.

Why is NIO better? Crossing the JNI boundary is more expensive than the small amount that you'd give up choosing NIO over C.

Interesting, eh? (Well, it is to me.)

Oh, and of course both mixed-C and NIO totally blew away a traditional implementation, since you're thread bound and limited by the OS. But that part shouldn't suprise anybody.

Got benchmarks that say different? I'd like to hear about them...

BOF Discussion of GlassFish

1. We're cutting edge stuff. Our Java EE (formerly J2EE) engineers work directly with the people leading the specs. In some cases, they are the people leading the specs. We've always been first out the door with the new stuff, and we're going to keep that up. In many cases, we're beating the other guys out the door by over a year. Also, on a side note, please note that Tomcat isn't on the list I linked above. That's because they're not Java EE. Some people are confused about that. (Are you one? Let me know, and I'll put out a blog about what I mean when I say that...)
2. We've been doing this a long time. In fact, some of our engineers (and me) have been doing this longer than anyone else on the planet. That's because we were part of the team that came up with the very idea of Java EE. Now, that's a mature team, and a mature codebase. We're pre-beta right now, but even given that, I think you'll be pleasantly suprised by how we're doing with our code stability.
3. We're very proud of Grizzly. Other folks will eventually do their HTTP stuff this way, too, but for now, we're first. Come check it out. If you haven't heard about Grizzly, and you're at JavaOne, come to the talk today that goes over the tech behind it at 2:45 today, in Hall E 134.
4. We're also proud of how easy we are to use... Come by and download, and see what I mean.

What is this CDDL thing, anyway?

Reannouncing Project GlassFish

Reannouncing Project GlassFish

This work is licensed under a Creative Commons License.