Monday Mar 20, 2006

Grid @ JavaOne

It's that time of year again. Everyone involved in Java™ at Sun is scrambling to get their JavaOne labs and presentations in order. I am fortunate enough to be in that category again this year. I think.

This year I will once more be making the Grid-enabled Applications lab available. The lab is essentially a DRMAA tuturial, but this year there will be some new twists. (For a copy of last year's lab, look here.) This year I will be putting all of the exercises in a Sun Grid context. (BTW, Sun Grid goes live today!) I will also be including a section on using Project Passau. That, of course, means that I'm busily trying to get Project Passau into a usable state in my spare time. The jury is still out as to whether the lab will be an instructor-led lab (meaning that I will be there live on stage to talk you through it), or if it will just be available on a CD for you to play with at home. A good chunk of the decision will be based on demand, so if you're really interested in having a "grid playground" at JavaOne where you can get some hands-on grid time, drop me an email and I'll use it as proof of demand.

There is also a chance that I will get to take part in a group presentation from the N1 Grid Engine team, the Sun Grid team, and the Jini team about grid, SOA, and the Java platform. I'll know for sure in the next couple of weeks, but just in case, I'm busy working on a presentation.

Also, I hear tell that Tim Bray will have a session comparing the various grid technologies, including DRMAA. I can't wait to see that!

Wednesday Feb 22, 2006

Does Java Even Exist?

Last night I went to an AJAX talk at the Standford School of Business VLAB. The main speaker was Scott Dietzen, President and CTO of Zimbra. There was also a panel discussion with him and some other folks. It was a very interesting presentation and discussion, but I also found it extremely frustrating.

The panel members talked about how AJAX was going to finally deliver on the "write once, run in any browser" promise. In order to help the process along, a lot of work is being to flesh out the JavaScript object model, in hopes that it will become a fuller, more stable, more complete language. They also talked about how the next step for AJAX is a "disconnected" mode, eventually leading to the ability to run AJAX from the desktop.

Never once did they mention the Java™ platform. They spent the whole evening essentially explaining how they were going to try to turn JavaScript into Java, without ever acknowledging that Java exists and already offers everything that they were describing. I was floored.

One of the developers with whom I spoke while I was there told me about how excited he had been when Java first appeared, and how he'd hoped that Swing would bring about an applet renaissance, but that because Swing had not been a core part of 1.2, Java was clearly not up to the task of client-side web development, and so he abandoned the platform completely. That story shows just how important that first technology impression can be. I have to wonder how many potential developers we lost because of the pre-1.3 days.

What I find ridiculous, however, is that the Java platform was/is clearly too immature for real applications, but AJAX is God's gift to web development. Huh? Doing AJAX development is a pretty close approximation of my idea of hell. I've been doing JavaScript for about a decade. With all of the cross-browser, cross-platform hoops through which one has to jump, I'm amazed anything ever gets done or is even vaguely maintainable. By the time you're done with a real AJAX app, you might well have code that writes code that writes code that writes HTML. I get chills just thinking about it.

This whole discussion ties back into a previous post. The Java platform has simply stopped being cool. Developers on the bleeding edge aren't able to amputate anything with Java anymore, so they are having to find new ways to cause themselves pain. The problem is that the rest of us and getting dragged down the bloody path with them. I grant fully that AJAX can address spaces that the Java platform cannot. However, disdending AJAX to attack a problem that the Java platform has already solved seems a little nutty to me. In the immortal words of Rodney King, "can't we all just get along?"

On a less (or perhaps more) inflamatory note, Scott made an amusing comment I thought I'd share. He was trying to describe the difficult path that Zimbra and N1 Grid Engine are trying to walk between offering enough of the product free and open source to build a community, but not offering so much that there's no reason to buy it. To explain his perspective, he made the following analogy. He said that walking that line is like giving the sex away for free, but charging for the bed, the sheets, the lingerie, etc. I think that was very aptly put.

Tuesday Jan 24, 2006

Why Are Stack Traces OK?!?

This morning I read a comment on a previous post that really hit a hot button for me, and I just have to vent...

<rant>When did stack traces become an acceptable means to display an error to the user? What egghead decided that users want to have to learn to program in the Java™ language just to use his products? Gah! Of all the incomprehensible, useless output to spit at a user! Not only are they meaningless to anyone but the developers, they take up tens or even hundreds of lines. If you're not a Java language programmer, the most you'll get out of a stack trace is that something very bad happened.

What's worse is that we, Sun, the guardians of the platform, have products full of stack traces. What kind of example are we setting? I used to wonder why sys admins were afraid of app servers. Now I know; it's all about the stack traces.

I suspect that in the early days of Java software development, it was common to get unexpected Exceptions which caused stack traces. Over time, we became jaded to them, and appear to have even embraced them. Shame on us! These days I see stack traces used to communicate even the most mundane errors, such as missing command-line parameters. Until and unless we discover that stack traces are the embodiment of all bad programming practices, we ask for our own destruction. Stack traces are not OK!!!</rant>

I feel better now.

Actually, no I don't. While trying to post this entry, I got the following web page from the server:


HTTP Status 500 -


type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException
   org.roller.presentation.weblog.actions.WeblogEntryFormAction.correctSpelling(WeblogEntryFormAction.java:730)
   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   java.lang.reflect.Method.invoke(Method.java:324)
   org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:276)
   org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:196)
   org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
   org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
   org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
   org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
   org.roller.presentation.filters.RequestFilter.doFilter(RequestFilter.java:79)
   org.roller.presentation.filters.BreadCrumbFilter.doFilter(BreadCrumbFilter.java:77)
   org.roller.presentation.filters.PersistenceSessionFilter.doFilter(PersistenceSessionFilter.java:53)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:292)
   net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:108)
   net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter.doFilter(SecurityEnforcementFilter.java:197)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:143)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestF...)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:168)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:154)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:324)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter...)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:173)
   net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:120)
   org.roller.presentation.filters.CharEncodingFilter.doFilter(CharEncodingFilter.java:94)
   com.sun.wpe.tools.WPESslRequestWrapFilter.doFilter(WPESslRequestWrapFilter.java:42)

root cause

java.lang.NullPointerException
   org.roller.presentation.weblog.actions.WeblogEntryFormAction.correctSpelling(WeblogEntryFormAction.java:704)
   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   java.lang.reflect.Method.invoke(Method.java:324)
   org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:276)
   org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:196)
   org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
   org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
   org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
   org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
   javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
   org.roller.presentation.filters.RequestFilter.doFilter(RequestFilter.java:79)
   org.roller.presentation.filters.BreadCrumbFilter.doFilter(BreadCrumbFilter.java:77)
   org.roller.presentation.filters.PersistenceSessionFilter.doFilter(PersistenceSessionFilter.java:53)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:292)
   net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:108)
   net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter.doFilter(SecurityEnforcementFilter.java:197)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:143)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestF...)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:168)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:154)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:324)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter...)
   net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
   net.sf.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:173)
   net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:120)
   org.roller.presentation.filters.CharEncodingFilter.doFilter(CharEncodingFilter.java:94)
   com.sun.wpe.tools.WPESslRequestWrapFilter.doFilter(WPESslRequestWrapFilter.java:42)

note The full stack trace of the root cause is available in the Apache Tomcat/5.0.30 logs.


Apache Tomcat/5.0.30


Some good points have been made in the comments of this and the post that started this rant. As Jeff points out, there are times when stack traces are unavoidable. When something breaks that really shouldn't have and was completely unexpected, a stack trace may be the most useful tool you have for finding and fixing the problem. In that light, since the above error page happened because of an NPE, it is really an unfair example; it was mostly just ironic.

Martin defended the use of stack traces in his and Tom's improved versions of my examples by saying that since such short examples are unrealistic anyway, there's no need to apply UI design methodology. He also defended the use of stack traces in admin-style scripts. I admit that my examples were too minimal to really need error handling; even the error handling that I included was minimal and arguably useless. My point, however, was that we follow our habits. If you're trying to quit smoking, do you give yourself a break as long as the cigarette is small? For my own sake, and for the sake of the developers who may look to our examples for guidance, there is no such thing as code that's too simple to be well written.

An anonymous commenter brought up another interesting point. When I apply what I call good error handling to the Java example, it degenerates into 4+ lines of error handling for every line of code. I think that is the root of the problem. Particularly with the I/O and JDBC libraries, it's very difficult to do decent error handling without ending up with hideous code. The common solution to the problem seems to be not to do decent error handling. Therein lies the reason for the rant.

Thanks for the great comments! Now, how do we solve the problem? Nick suggested https://exitcode.dev.java.net/ as a solution. Maybe.

Sunday Jan 22, 2006

Is Java German?

Sorry for the long hiatus. Crunch time again. Anyway, this weekend I did an interesting experiment inspired by Tim Bray and my wife. Week before last, I saw a presentation from Tim about how Java™ compares to some other languages in terms of efficiency and productivity. The languages he talked about were Perl, Python, Ruby, and PHP. It was a very thought provoking talk, but one of the weakest points was the source code comparison. He showed the same very simple program written in Java, Perl, Python, and Ruby. The problem was that the program was too simple. Yes, Java took more lines of code, but if you forgive the OO trappings, it was the same number of statements and a hell of a lot more readable.

This weekend my wife was preparing for a second interview with a company who is interested in Python experience. Since my wife didn't have any, she spent the weekend learning Python by doing a simple project. At an early stage, we had a discussion about how the program would look in Perl. To aid in the discussion, I knocked out a Perl version of it. Then, just for kicks, I also wrote a Java version. The differences are very impressive!

So you can judge for yourself, here are the three programs. Keep in mind that neither I nor my wife could write a line of Python before this weekend, but as far as I can tell, what we produced looks like good code. The programs open a file called "test.txt" and read it line by line, printing each line to stdout. The programs are perhaps a little more complicated than strictly necessary, but I wanted them all to behave identically. (I should note that I haven't actually run (or compiled) them, so I reserve the right to have syntax errors.) Here they are:

Perl
open FILE "<test.txt" || die "Can't open file";

while (<FILE>) { chomp; print; }
die "Can't read file" if $!;

close FILE || die "Can't close file";
Python
import sys

try: f = open("test.txt", 'r')
except IOError: sys.exit ("Can't open file")

try:
  while line = f.readline():
    print line.strip()
except IOError: sys.exit ("Can't read file")

try: f.close()
except IOError: sys.exit ("Can't close file")
Java language
import java.io.\*;

public class FileReader {
  public static void main (String[] args) {
    File f = new File ("test.txt");
    BufferedReader br = null;

    try {
      br = new BufferedReader (new FileReader (f));
    }
    catch (IOException e) {
      System.err.println ("Can't open file");
      System.exit (1);
    }

    String line = null;

    try {
      while ((line = br.readLine ()) != null) {
        System.out.println (line.trim ());
        System.exit (1);
      }
    }
    catch (IOException e) {
      System.err.println ("Can't read file");
    }

    try {
      br.close ();
    }
    catch (IOException e) {
      System.err.println ("Can't close file");
      System.exit (1);
    }
  }
}

Interesting to note is that unlike in Tim's example, the Java program is considerably less readable than the Python. Perl always looks like gobbledigook. To come back to the title of this post, thinking about these three languages in lingual terms, Perl reminds me of American street slang: direct, to the point, and incomprehensible. Python reminds me of Italian, elegant and succinct. Java reminds me of German, lots of rules and formality, but nothing is left open to interpretation. Or in more manly terms, Perl is a chainsaw, Java is a Hillyer vertical machining center, and Python is a power compound mitre.

Thursday Jan 05, 2006

Neophytic Development

Last night I had an interesting opportunity. My wife asked me to help her write a GUI application on the Java™ platform. She hadn't messed with the Java language since the 1.0 days, and I avoid GUI's if at all possible and haven't built a real GUI since the days when AWT still walked the earth, so we approached the task as "informed neophytes." I tried to install the beta of NetBeans 5.0, but our ancient desktop couldn't even handle the install. Instead we used the NetBeans 4.0 I had installed back when 4.0 was new.

Since I knew my way around the tool, we managed pretty quickly to get to the point of looking at a blank GUI designer page. After that, though, things went downhill quickly. We tried the naïve approach first. My wife tried to drag a Swing text field onto the page. Nope. So she tried selecting it and clicking in the page. That worked, but the text field went into the middle of the page, and she wanted it in the upper left corner. She tried to move it. No dice. She tried to resize it. No dice. Then I remembered about windowing managers. We tried GridBagLayout and were quickly just as frustrated. We eventually settled on the AbsoluteLayout. The problem with AbsoluteLayout, though, is that we couldn't get it to respect our designed frame size. My wife cleverly solved the issue by adding a blank label to the right side and bottom. (Can you tell she's a web developer?)

Things proceeded similarly throughout the rest of the development. We were constantly plagued by the palette and properties frames being too small to read. We were also annoyed that we couldn't operate on a group of components all at once. The real head-spinner was when we started wiring up the components. I remember just enough AWT to be dangerous, and with the help of NetBeans, we managed to trial-and-error our way through getting the events set up.

In the end, we spent about four hours building the GUI and half an hour writing the logic. When we stopped last night, it was working, but there were still several layout issues. Being a Java paltform "expert," I find it easy to forget just how difficult this stuff really is. This exercise was a good reminder. If I hadn't been there to explain how things were supposed to work, and if NetBeans hadn't been there to do the grunt work, my wife would not have even gotten started. (Without NetBeans, I would have been lost, too.)

Since I avoid GUI's, I've played with neither Matisse nor Creator, but for the sake of GUI developers around the world, I really hope they're light-years beyond what we witnessed last night.

Tuesday Aug 16, 2005

I Know Kung Fu

After having seen The Matrix, every geek on the planet wishes he or she could translate his or her wicked development skills into a martial arts black belt. Looks like some guys from Belgium have provided the next best thing. You can earn a belt for your programming skills!

Before you rush over to the site to prove your manhood (or womanhood), be warned that it's still under development. They have the first two belt tests available in a beta form, but they're still pretty rough. The test for the yellow belt is 10 questions, and I took issue with at least four of them. The good thing is, though, that during the test beta, you can leave comments on the questions to help the author improve them. The even better thing is that you can add your own questions!

JavaBlackBelt.com is something that's been long overdue: a community certification. The community determines what knowledge is required to pass a test. The community decides what technologies are important. The community determines what tests are needed. I will be very interested to see how this site works out. I'm a little afraid that a community certification will be like the Senate voting themselves raises. Instead of raising the bar, they might just lower it. However, if we all contribute, this site could become a very good thing.

Wednesday Jul 13, 2005

What I Learned At JavaOne 2005

I've been going to JavaOne since 1999. One of the most important quality metrics for me is what useful things did I learn while I was there. According to that metric, this year was the best year we've had in a while. As I blogged before, the sessions I attended were very technical and of high quality, with few exceptions.

There are two categories of learning at JavaOne. One is concepts, and the other is tips and tricks. Concepts are a little hard to share, but tips and tricks make for a very tidy blog entry. What follows are the tips and tricks I learned at JavaOne. Since I'm a Java geek, I already knew a great deal about the platform. The tips and tricks below are the little things I had missed.

  • Annotations - annotations are a very flexible tool for providing meta-information about your code. The use of annotations comes in two flavors: compile time and run time. At compile time, the APT (Annotation Processing Tool) can be used to generate new files from annotations in your Java code. The APT is iterative, so it will process the generated files, potentially generating more files, etc, until there are no more annotations left to process. The APT cannot, however, alter exiting files.

    Two important built-in annotations are @SuppressWarnings and @Override. @SuppressWarnings tells the compiler not to complain about a particular compile time warning class, such as unchecked casts or deprecated method calls. @Override indicates that a method should override a method of a parent class, and if it doesn't, a compile time error is generated. These annotations are allowed by any J2SE 5.0 compiler, but are ignored in any version prior to update 4.

    The other flavor is runtime use of annotations. I kept going to sessions in hopes of learning when to use runtime annotations instead of interfaces and abstract classes. Unfortunately, no one talked at any depth about runtime use of annotations.

  • Type-safe Enumerations - This is one of the nicest features of J2SE 5.0. What I learned at JavaOne is that there are two new classes, EnumSet and EnumMap, which are optimized for use with enums.

  • Covariant Returns - I have wanted this feature for years. This is just cool. Covariant returns allow classes to override/implement a method from an parent/interface with a return type that is a subclass of the parent's/interface's return type. For example:

    public abstract interface Person {
       public abstract Food getFavoriteFood ();
    }
    
    public abstract class Food extends Object {
       ...
    }
    
    // Beer is abstract because there are so many varieties!
    public abstract class Beer extends Food {
       ...
    }
    
    public class German extends Object implements Person {
       public Beer getFavoriteFood () {
          ...
       }
    }
    
    German andreas = new German ();
    Person johndoe = andreas;
    
    Food favorite = johndoe.getFavoriteFood ();
    Beer beer = andreas.getFavoriteFood ();

    If I call the getFavoriteFood() method on a class of type Person, I get a type Food back. If, however, I call the getFavoriteFood() method on a class of type German, I get a type Beer back. This feature alleviates the need to cast the return value to a more specific type at runtime. Instead, all the type handling is done at compile time.

  • Generics - I learned two things about generics. First, you can add the angle brackets to the beginning of function calls, like:

    List<Integer> list = Collections.<Integer>emptyList ();

    I also learned that the Comparable interface is now genericized, so you don't have to handle the case of comparing to an object that isn't of the same type.

  • Tools - there are a bunch of new tools included with J2SE 5.0. The one that caught my eye was jps. It shows you a list of J2SE 5.0 VMs running on your machine, and with the -v switch, it also tells you the full list of VM args, the class being run, and the program args.

  • Web Services - My big take-away from the Web Services discussions was that there still isn't a way to cleanly handle long-lived blocking calls. You essentially have to either make the client a server so it can offer a callback, or you have to poll. An interesting idea was to use RSS as the notification mechanism. It still requires the client to be a server, but it leverages an existing (simple) standard.

That's the highlights. Obviously, I learned more than what you just read, but those were the things that I found immediately useful. Hopefully you found them useful too.

Sunday Jul 03, 2005

Use Small Words

This has probably already been posted by everyone who was at JavaOne, while I was still hanging somewhere over the Atlantic, but on the off chance that you missed it the first hundred or so times, here's an outstanding essay by Guy Steele, Sun Fellow, father of Fortress.

The essay is interesting less because of what it says, and more because of what it is. It puts the reader in the shoes of a language architect, and does so in a very clever way. Read it to see what I mean. And don't worry if it sounds like nonsense at first. Around page 4, Guy finally explains why he's written the essay the way he has. Intrigued? Good.

Wednesday Jun 29, 2005

Hardware Headlines JavaOne

I've been spending a lot of time talking to the conference attendees this year. Much to my surprise, universally the favorite announcement has been the $29.95 per month SDN subscription which comes with a free Ultra 20 workstation. As a Sun employee, I groaned when Jonathan put that slide on the screen; JavaOne is the wrong place to talk about hardware. Apparently I was wrong.

One of the comments I've heard was that this workstation offer may be the key to breaking this customer's IBM shop out of the IBM stack and getting them onto NetBeans, Solaris, and Java Enterprise System. Another attendee told me that this deal is going to change the world, because developers, who need the software anyway, are going to be able to bring home this box, bootstrapping his or her family into the participation age. An important caveat to that comment was that the box must include StarOffice. I would tend to agree.

I must say, the Ultra 20 is an attractive box. The common consensus among the Sun employees with whom I've spoken is that factoring in our employee discount, there is no better hardware deal in the market, PC or otherwise.

Quality Is Job #1

I have been very impressed with the quality of the sessions at JavaOne this year. I have yet to go to a session that I thought was useless. Most of the sessions I have attended have had excellent technical content, and several left me feeling like I learned something useful.

(This may seem like something obvious, but in previous years the chaff content was very high. I had reached the point where I wrote off all non-Sun presentations as useless product pitches, and most of the Sun presentations as too high-level. This year, the best sessions I've attended were from companies other than Sun, and all of them have dived straight into useful technical content. I'm totally stoked!)

I'm also stoked about the eval forms. For two years, the JavaOne folks have been promising to start weeding out repeat speakers based on feedback. Last year there was apparently a system for evaluating sessions online. I never managed to find it, though, so I doubt it was very well utilised. This year every attendee gets handed an evaluation form when he or she walks into a session. The form asks some good questions about the speaker, the slides, the overall quality, etc. Hopefully folks are filling the forms out and returning them.

Perhaps the most exciting thing at JavaOne this year is that every other hour the JavaOne staff is holding a brainstorming session to discuss what they can do better for next year. That is huge! We're actually listening to what the attendees are saying! This is something we should have been doing from the beginning, but better late than never.

JavaOne Demographics

I've noticed that the demographics of the conference attendees is a bit different this year from previous years. There seem to be a lot more techies and a lot fewer business people. This change is obviously a direct result of the recent focus on deeply technical presentations. As a veteran JavaOne speaker, I can tell you that the speaking requirements have become much more stringent in the last two years.

I think the increase in the geek percentage of the population is also attributable to the recent history of JavaOne. Five years ago, the conference hit its peak, with an unofficial attendance of 30k people. Back in the those days, the speaker requirements were much looser, and in my opinion, the session were much less useful. After the .Bomb exploded, the conference attendance dropped well below 10k and stayed there. This year is the first year since the crash that has had a solid attendance, and it's happening concurrent to JavaOne's new technical focus. The net effect is that we burned off the wannabes with the crash, and now we're rebuilding with a high geek factor. Long live technical content!

This year I've also noticed that there are a lot more women here than in previous years. Based on just looking around, I would say that in previous years the attendee population was around 2%-4% female. This year, it looks more like 6%-8%. Again, that's just my opinion, formed from doing a rough head count every time I'm in a crowd, but that's 2-3x increase. Now, the interesting question to me is 'why?' I could speculate, but I haven't yet come up with a defensible explanation. (By the way, I'm not the only one who has noticed the increase in the female JavaOne population.)

Something else I've noticed is an increase in the European population here. I could easily believe that since I now live in Europe I'm just more tuned in to the European community, but it could just be that there really are more Europeans here than in previous years.

During the first keynote, John Gage did his old demographics demonstration where he asks everyone to stand up and then has people sit down based on the number of years they've attended JavaOne. There were a lot of first-time attendees. Not surprisingly, though, most of the people who had been to JavaOne before, had been coming since 2000. We didn't pick up a lot of new community members during the layoff years.

Based on the 2003, 2004, and 2005 attendance, and the recent changes to JavaOne, I feel really good about what JavaOne 2006 will be. I think we're on the road to (re)building a very strong Java community around JavaOne.

Tuesday Jun 28, 2005

Tuesday

Welcome to the second day of sessions at JavaOne. The keynote this morning was much better than yesterday. McNeally took the stage and worked his usual magic. I'm not sure that he actually said anything, but it was really fun, and he got lots of laughs and applause. The highlight was a brief video documentary honoring James Gosling. It was very well put together, and clearly showed the family side of Sun. Very touching stuff. Sniff, sniff...

Yesterday, I only managed to go to one presentation, but it was an outstanding presentation. Experiences With the 1.5 Language Features: Tips and Techniques, by Jess Garms and Tim Hanson from BEA, was a tour through the new features of J2SE 5.0, along with best and worst practices. I've been doing J2SE 5.0 development for a while now, but I learned quite a few new things in their presentation. In fact, I took notes so I can share the stuff with the guys back home. This presentation is a definite must-download when you sign up for JavaOne online.

BoF Bliss

I am very pleased to report that my grid computing BoF last night went very well. We had standing room only with ample audience participation. I couldn't have asked for more. The BoF was originally submitted as a Technical Session, but due to the limited number of slots, it got bumped down to a BoF. So, what started as a formal panel discussion quickly evolved into an ask-the-experts session. But, that was fine. In fact, it was great!

One of my pet peeves is BoFs that don't involve the audience. BoFs should be about engaging the community and fostering discussion. All too often, BoFs end up just being bad slide shows with no interactivity.

A pitfall of an ask-the-experts-style session is that the audience may leave you hanging. In order to mitigate that risk, I had two pages of prepared questions. Much to my shock and (pleasant) surprise, though, the audience produced an endless stream of questions. In fact, in order to ask the prepared questions I did ask, I had to put audience questions on hold!

I would like to personally thank Dan Hushon (Sun), Richard Nicholson (Paremus), Mark Little (Arjuna), and Greg Pavlik (Oracle) for being on the panel and doing an outstanding job. I got lots of comments from folks afterwards saying that they learned a lot during the BoF. Thanks guys!

Saturday Jun 25, 2005

Word On The Street

I'm sitting here beside a very interesting gentleman. He works for an IT group in an IBM shop. He's been filling my ears with stories from the trenches, particularly about Eclipse. I'm going to try to capture as much of it as I can here before I forget it.

First off, he says that NetBeans has the best tools for web development that he's seen. Even though he's an Eclipse user, he fires up NetBeans whenever he needs to debug a JSP or do any serious web development. He also says that Eclipse is a memory pig. He says that on a system with a large number of plugins the IDE becomes quickly unusable. He said that for projects that are very large, that have a lot of classes, NetBeans consumes dramatically less memory than Eclipse.

On IBM in general, he says that the lack of quality is plainly evident. In an IBM mobile portal install, a team of IBM people took two weeks just to get a sample app working. They still haven't managed to get the production environment working. He said that his IT team is afraid to deploy Java EETM apps without a developer standing by, because the deployment tools very often break leaving a partial or broken deployment.

About the keynote this morning, he said that the most interesting part was the SDN subscription with an Ultra 20 for $29.95 a month. The reason is that they currently do their development on Eclipse on Windows and then deploy on WebSphere on Solaris 9. With the Ultra 20, NetBeans, and Sun Java Enterprise System Application Server, he can do the development on the same architecture as the production environment, making it possible to discover certain bugs before deployment that he cannot now.

Last thing he said is that in order to maintain adherence to the Java EE spec, he uses JBoss and Sun Java Enterprise System Application Server, Platform Edition to test deploy his apps. That way, if the developers use something WebSphere-specific, he finds it immediately. He says it also helps detect bugs he wouldn't otherwise find until production.

Very interesting. If his story is typical, our stock is very undervalued.

Thursday Jun 23, 2005

Checking In From JavaOne

Greetings from JavaOne 2005! Wow! This look like it's going to be a great conference! It's Monday afternoon, and my head is already spinning.

I got in last Wednesday, hit the ground, and crashed. Nine timezones and a 12-hour flight is enough to wipe me out completely, especially since I didn't sleep at all the night before the flight. (I didn't even go to bed; too much to do!) Thursday, Friday, and Saturday was the Software & JavaTM Ambassadors Conference, an internal Sun conference to share our product direction with a select group of engineers from the field. This year we had a very high density of information. I can't give you any details, but suffice it to say that we've got some great stuff coming up in the next year. We're announcing (and have announced) some of the stuff here at JavaOne, but a lot of it is still coming in FY06 or later.

I spent all day Sunday in the hands-on lab making sure that my Building Grid-enabled Applications lab works in the lab environment. There were quite a lot of minor tweaks and changes that had to be done, including updating all of the screen shots for NetBeans 4.1. After I got everything cleaned up and ready to go, I made the mistake of calling my co-presenter for the Building J2EETM Grid-enabled Applications Technical session (Thursday at 2:30!). We are have a demo that we are using for the session, and it was down. I spent two hours hanging from a pay phone while trying to talk Eric through finding and fixing what was wrong. (By the way, we failed.)

Today, I got to the Moscone center a little after 7:30. When I got there, there was already a line for the general session. It was only about 20 people, though, so I went on about my business, which was doing some speaker and lab preparation and getting some coffee. I was rather impressed to see the line in front of the breakfast room. It was rather long. By the time I got my coffee and got back upstairs, the line for the general session had reached around the corner. And kept going! I finally found the end of the line at the next street corner, in front of the Metreon theater. That was about 8:15. By 8:30, the line had reached around almost all the way to the next steet corner! I haven't seen a line at JavaOne like that in years! I felt like Chistopher Eccleston as Doctor Who, looking at the exceedingly long line that I was going to have to stand it, smiling broadly, and quietly muttering, "Awesome."

The general session was OK. Because of the SJA Conference, the announcements had already been spoiled for me. The level of enthusiasm was overall a little low. Last year was great because everyone was stoked about the new features of Tiger. This year, Jonathon and JonnyL didn't really have much exciting to say. (See the next paragraph.) Even the t-shirt hurling contest entry was a bit of a dud. The highlight of the session was when McNeally jumped up on stage and heralded the entry of Duke followed by a jazz band and a birthday cake. Even cooler, Gosling brought up on stage the original members of the Green development team. That was the only rousing sound of applause in the entire session.

Among the things announced was Project GlassFish, the open-sourcing of the platform edition of our app server. I thought GlassFish was huge, but the audience reaction was non-existent. No applause. Nothing. I talked to another conference attendee about it over lunch, and he said that with JBoss out there, it just wasn't an exciting announcement. It's nice to now have a choice, but he didn't see it as particularly thrilling. Interesting. The gentleman sitting beside me right now has a very interesting perspective. He says that from a product perspective, the announcement doesn't make any difference; companies don't want free software running in production. He says, however, what is going to fundamentally change the app server landscape is that Sun has just declared that they're willing to listen to the community about what a "good" app server really is. Interesting.

I'm off now to the Sun bloggers meeting. This will be my first year to make it. I'm very curious to see how many people show up.

Before I go, though, let me plug my BoF. I have a BoF panel on grid computing tonight at 9:30pm in the Golden Gate A3 room at the Marriott. I have some CTO's (and one CEO) there to talk about what grid computing means to the future of Java computing and computing in general. Come on over!

About

templedf

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today