Wednesday Aug 02, 2006

Safer Assert

I'm currently working on a project using the J2SE™ 5.0 platform. This is the first large project I've done since 1.3. One of the new(ish) features that I use often is assertions. In particular, I find myself using assert false quite a lot, as an indication that even reaching the given point in the code is a problem. In testing, though, I've noticed that if assertions are disabled, which is the default state, bad things happen because of my reliance on assert false. Because the assertions are ignored, the VM doesn't break out at my assert false points, and it goes on to do bad and often confusing things.

I began to wonder if I wasn't perhaps misusing the assertion facility. After a quick search, I found Programming With Assertions. In that document, the author validates my use of assert false, but suggests a safer alternative. Instead of assert false : "message";, the author recommends throw new AssertionError("message");. The effect is the same, except for two caveats. First, even when assertions are disabled, the later will still cause an error to be thrown. Second, in cases where a return statement is expected in the branch, the former is a syntax error while the later is valid.

Armed with this new bit of knowledge, I will be replacing the occurances of assert false in the project source base as I run across them.

Thursday Jul 27, 2006

The Latest Numbers

An internal email just came from the Java™ platform marketing group with the latest statistics on Java platform adoption. They're pretty impressive:

  • 5 million+ Java developers
  • 180+ Java carrier deployments
  • 1.2+ billion Java Powered phones (source: Ovum; as of end of June 2006)
  • 1.65+ billion Java Cards
  • 800 million PCs
  • 1106 Java Community Process (JCP) members
  • 304 Java Specification Requests (JSRs)
  • 302+ million JRE downloads from java.com
  • 6 million settop boxes

Looks like we're half way to the 10 million developer goal set at the JavaOne™ Developer Conference a couple of years ago.

Friday Jun 16, 2006

New NetBeans i18n Module

I just downloaded a cool new module from the NetBeans Update Center Beta. It's an internationalization wizard that lets you select a source file and a resource bundle and determine if there are keys used in the source file which are not in the bundle. Just last week, someone on my team was considering writing a script to do just that. Sweet!

Rewards of Good Design

Having been in software for a while now, I have a developed a sense for good design practices. It's not that I consult the GoF patterns book for everything I write, but I can just generally tell when an approach is good or bad, even if there isn't a lot of logical support.

A perfect example of good design paying dividends happened to me yesterday. In my current project, we have distributed components. So that the components can identify each other, they all have ids. In the very first draft of our design, the ids were just Strings. I was certain that there would never be a need for an id that was more complex. Nonetheless, we chose to create a class for the ids that would just be a wrapper around a String. We made that decision because deep down we knew it was the right thing to do, even though at the time, it seemed less like correctness and more like obsessiveness.

Yesterday I had to change the component id from being a String to being a compound element composed of a URL and a JMX identifier. NetBeans told me the component id was used in 172 places! There were, however, only about 5 places where ids were created. Everywhere else, the actual contents of the id were irrelevant. If we had just used String ids, I'd have had to change the type of the component ids in all 172 places, and it would have taken me all day. Instead, I was able to make all the changes, including writing a unit test for the new id class, in about an hour.

Friday May 19, 2006

JavaOne 11: Friday

The keynote this morning was great. McNealy did a 20-minute routine, and he was really on his game. He gave his top 10 list of advantages to not being CEO. After that James Gosling did the "new & cool" keynote. At the end, he held the final heat of the Java™-driven slotcar competition. The second-place winners were a team of German high school students! Very nice.

In the session on scripting in the JVM this morning, I got a good update on what's coming in Mustang. The short summary is that from a Java application you will be able to eval JavaScript code, and from JavaScript code, you'll be able to call into the Java platform API.

Since I had nothing else planned, I went to the repeat of Josh Bloch's Effective Java Reloaded presentation. Josh very effectively reminded me that there is a lot of depth to generics. They may be simple once you get your head around them, but there are a lot of subtleties involved. Go see the slides for details. The only tidbits I'll share here is that Josh is now pushing the ideas that 1) you should make everything final that you can, and 2) you should use @Override on all methods that override parent methods.

Again, since I had nothing better to do, I dropped in on an architecture talk: To Know the Dependencies is to Know the Architecture. Honestly, I expected to walk out 10 minutes into the talk. Much to my surprise, it was a very useful talk about a new way to model dependencies in complex systems. The idea is that dependecies among modules can be graphed in a dependency matrix. From the matrix it's then possible to optimize system to reduce complexity and increase maintainability. The talk was ultimately a product pitch for Lattix, but it was nonetheless interesting. Using the Lattix tool, the speaker analyzed the architectural creep that happened between Ant 1.4.1 and 1.6.1. A really cool demo.

My last session of this JavaOne was the presentation from the NetBeans team on how to design API's that last. The presentation essentially boiled down to a recap of Josh Bloch's Effective Java book with a healthy dose of lessons learned the hard way. The 60 second summary is that you should always make sure to separate your API's from your SPI's, because clients like it when you extend your API, but service providers get testy about extending your SPI. Also, plan for evolution, because you won't get the API right on the first try.

That does it for JavaOne '06. Wow, what a conference! Every year it gets better, and this year was no exception. I can't wait until next year!

JavaOne 11: Thursday PM

You may be wondering where Thursday AM went. So am I. As I said in the last post, I drove home Wednesday evening. A big part of the reason was that I had a customer meeting in Menlo Park on Thursday afternoon. I decided that instead of getting hung up at JavaOne and being late to the meeting, I'd drive down early. Well, turns out the meeting got quietly cancelled. Net is that I didn't get back to JavaOne until the afternoon. And that's why I don't have my homework.

The only session I caught on Thursday was the Twelve Security Traps talk. Definitely worth the time to check out. The presenter went through 12 common and subtle programming mistakes that lead to security problems. It was a very practical and useful session.

After that, I had my Building Grid-Enabled Applications hands-on lab. I'm still not sure exactly what went wrong, but the grid had some issues. I think part of the problem was the creative participants, but with a grid of 102 machines and 100k jobs, I don't see how the grid could have been knocked over so easily. I'll be spending next week doing a post-mortem. Nonetheless, it sounds like folks still learned something. It's not every day that you get to play with a 100-node grid, so it was an interesting opportunity. Thank you to everyone who attended. I'll be back again next year!

JavaOne 11: Wednesday PM

Sorry for the big deal on this post. JavaOne is such a fire hose, it's really hard to keep up.

Something else I should mention. In my JavaOne posts, I've been just referring to interesting sessions without explaining what was in them. That's not just to tease and frustrate you. The session slides are available online, and the audio will soon be available on the Sun Developer Network site, for free.

So, Wednesday PM. Gilad Bracha's talk about the new super packages JSR was very, um, succinct. It lasted about 20 minutes and then went into a long Q&A session. The basic idea is that with Dolphin, we're considering adding support for packages of packages that can change member visibility. For all classes in packages contained in a super package, the public classes, methods, and fields are only visible to classes in packages also contained in the same super package. In addition, the super package can selectively export contained packages and classes, making their public members available outside of the super package. The important part is that all this happens without changing the packages and classes that are being contained. The JSR is only just getting started, but when it's done, it will represent a big step forward for Java™ platform usability.

I sat in on Mark Reinhold's talk about embedding XML literals into the Java language. Mark made a good case for why we need XML literals added along side of String literals. He also offered up a couple of possible syntaxes. I'm not yet convinced, though. XML is great, but is it so great that it merits making the language even more complex? Check out the slides and decide for yourself.

The Java Persistence API session was a good introduction to the API, where it came from, what it does, and why. The important thing to know is that the API was written as the successor to EJB CMP, but ended up being targeted for Java EE and Java SE.

Bill Pugh's and Jeremy Manson's synchronization talk was chock full of handy tidbits. Interesting points:

  • Volatile can be a good alternative to synchronization
    • Volatile longs and doubles are written atomically
    • Volatile reads and writes cannot be reordered by the VM
    • In many cases, it's required to write correct code
  • Use immutable objects whenever possible
    • Prevents a lot of need for synchronization
    • Makes it possible to make fields final
    • Compiler advantage
  • Final fields also save on synchronization and allow compiler optimizations
  • In Java SE 5.0, you can use Field.setAccessible(true) to make final fields modifiable.
  • Use java.util.concurrent wherever possible
  • Synchronization is not that expensive -- if you want to worry about it, go after useless synchronizations, like Vector and Hashtable and I/O ops
  • All points of interaction among threads need attention, if not synchronization
  • Documentation is the key, but even documenting this stuff ain't easy
  • Worry about correctness before performance
  • Try not to share mutable objects among threads

I would like to say that I spent all night at the BoF's, but I wimped out. Even worse, I actually drove back home Wednesday night. There's a reason for it, though, and I'll explain in my next post.

Wednesday May 17, 2006

JavaOne 11: Wednesday AM

I forgot to mention in my posts about Tuesday, that we've tried to bring order to the chaos that is JavaOne this year in a new way. This year, attendees must register for the sessions they want to attend. If someone shows up to a session for which he or she didn't register, he or she must wait until all the registered attendees have entered and hope that there will still be seats available. I'll be very curious to hear what the general opinion of this new process is. Personally, I like it.

So, on to today. The keynote this morning was Oracle talking about what they're doing with Java EE. Java EE 5 is an amazing advance over J2SE 1.4, but I'm not in the EE space, so I can't claim the keynote was riveting.

Thanks to the new registration process, I finally got to attend one of the Java puzzler sessions from Josh Bloch and Neal Gafter. It was very entertaining. I learned several new things, for example: Arrays.toString(). Go look it up.

I also dropped in on Gilad Bracha's talk on super packages (JSR 294). Very short, but nice to know hear what big thoughts are floating around.

So far, the coffee supply is holding out. Viva la caffeine!

JavaOne 11: Tuesday PM

Tuesday afternoon I hit a great session on the new concurrency utilities. There are a lot of great things in there that I can apply directly in the project I'm on right now. I hadn't seen the ConcurrentHashMap or BlockingQueue before. Shame on me.

I also caught a session on what's going on in Sun Grid and the ComputeServer project. Very interesting stuff. The Jini team has essentially written a compute task distribution mechanism that uses Jini network technology and JavaSpaces technology under the covers. The net result is that, on the Sun Grid utility, you can submit a pile of concurrent tasks and gather the results without being a distributed computing guru.

My first BoF of the conference was on testing methodologies, put on by the NetBeans team. Definitely worthwhile. The NetBeans team appears to have taken testing to the next level. Not only do they test correctness, but they also test memory consumption, deadlocks and race conditions, all from JUnit. The most clever idea was to use a custom log handler to insert a delay in a method without changing the method itself, in order to induce a race condition or deadlock.

I rounded out the evening with the Sun Grid futures BoF, at which I was a presenter. I gotta give Dan Hushon props for putting together a BoF that was really a BoF. He had about three slides, and they we switched into audience conversation. I think everyone there, attendees and presenters, got something out of it.

I didn't get back from the Sun Grid BoF until 1:00am, so I'm already on the caffeine drip. The double latte this morning didn't even make a dent, so it looks like I'll be hitting the oh-so-delicious free conference coffee. Yum!

Tuesday May 16, 2006

JavaOne 11: Tuesday AM

Welcome to JavaOne, day one. First impression: nice backpacks! Second impression: there's a lot of people here! Someone told me that the attendance this year is around 20k! Also of note is that the geek factor is way up. Our efforts to make JavaOne a serious conference with real content appear to be effective.

The keynote this morning was interesting. It was like getting the band back together, with Schwarz, Green, and Zander all on stage. The big take-away from this morning is that, "it's not if we will open source Java™, but how." A close second was the fact that Motorola alone ships more devices in a year than the PC's shipped by all the PC vendors combined. The Java ME space is going to be hot!

The first session I attended today was about implementing ATOM and APP. Very interesting. Using Rome, it looks like one could build a blog server in an afternoon. Anyone care to join me in a project to make Grid Engine qstat information available via RSS?

The technical keynote this afternoon was nifty. Graham and Bill went through the new features in Java SE 6 and Java EE 5. Java EE 5 is such a radical improvement over J2EE 1.4 that it's hard to believe it's the same platform.

As I write this, I'm sitting in a session on the new features of Mustang and Dolphin. Mark Reinhold's list of interesting Mustang's features:

  1. Java-WS can do RESTful web services
  2. javax.swing.GroupLayout
  3. Password prompting
  4. Free disk space API
  5. Classpath wildcards
  6. Annotation processing done by javac -- no need to use the APT
  7. Solaris Dynamic Tracing (DTRACE) support
  8. jhat OQL -- SQL-style heap dump analysis
  9. JConsole plugin API
  10. Attach-on-demand monitoring for JMX

Look for Mustang in October, at least before the end of October, but hopefully earlier. Another cool feature is that Derby will be included in the Sun JDK (not the JRE).

SGE team, this is for you. In Mark's presentation, he talks about the effects of releasing weekly snapshots of the JDK. Looking at a graph of the number of external bug reports for a JDK release without snapshots (Tiger), the bug spikes correspond directly with beta releases. On a graph of Mustang (with weekly snapshots), they got more bug reports and got them earlier. In fact, they've gotten twice as many external bug reports with Mustang as they did with Tiger. The net result is that the JDK team has been able to de-emphasize their beta releases. Betas have just become a "branded" weekly build with little additional testing.

Things to look for in Dolphin:

  • Support for getter/setter pattern
  • Method references
  • Block closures -- may be a readability problem.
  • Native XML support
  • More scripting support
  • Improved JAR facilities
  • Superpackages -- the evolution of friend
  • Desktop frameworks improvements, especially around EoD

When I look at my agenda for the rest of the conference, I see a lot of coffee in my future. More to come later.

Friday May 12, 2006

Shameless-Plug Time of Year

It's that time of year again. It's time for me to shamelessly plug my hands-on lab at JavaOne. Here's the info:

    Session Id: LAB-7135
    Session Title: Building Grid-Enabled Applications
    Track: COOL STUFF
    Room: Hall E 130/131 - Hands On Labs
    Date: 18-MAY-06
    Start Time: 16:00

I'm also very excited to say that the pre-registration for the lab is full. I'm sure, though, some seats will open up at the last minute, so if you're interested, come by anyway. I look forward to seeing you all there!

Friday May 05, 2006

CVS Like It Should Be

I love the CVS support in NetBeans 5.0! It took a couple of weeks to adjust, but once I really started using it, I became hooked.

Here's my favorite new idiom. In our product team, we keep a change log, where every committer puts an entry for every check-in. Using NetBeans 5.0, to see what someone else changed before I do an update, I:

  1. CVS > Update on the change log
  2. CVS > Search History on the change log
  3. Find the commit in which I'm interested
  4. Click the Find Commit in: "<project>" link

And, voilà! I get a list of all the files that were changed in that check-in. Better yet, I can click the Diff button and see the changes that were made to those files during that check-in. Try doing that from the command line!

Tuesday Apr 25, 2006

Happy Birthday, JXTA!

Five years ago today, Project JXTA got started at SunLabs. If you've never taken a look at the JXTA™ technology, now's a good time. The technology has matured immensely since it first hit the Internet.

In a nutshell, the theme of the JXTA technology is to facilitate distributed computing, much like Jini™ network technology. The essential difference is that with Jini network technology, the platform is fixed so that the protocol can be abstracted, whereas with JXTA technology, the protocols are fixed so that the platform can be abstracted. In other words, with Jini network technology, you assume everything runs on the Java™ platform and don't care what protocols are used to communicate. With the JXTA technology, you assume that the protocols are the JXTA protocols and don't care on what platform things run.

Another way to look at the JXTA technology is that it provides a network virtualization layer. Instead of being bounded by the actual network topology, the JXTA technology allows you to work on a virtual network layer, where you decide how to carve things up, regardless of the actual, physical environment. That's a very powerful concept, and it provides some interesting benefits for grid computing. (Actually, so does the Jini network technology, but I'll save that for another birthday...)

Wednesday Apr 19, 2006

That is Cool!

So, I was just playing with NetBeans 5.0, and I accidentally found what might just be my new favorite feature. If you hold down the Control key while you have a source file open, referencable items show up as hyperlinks when you mouse over them. By "referencable items," I mean anything that you could click on and hit Alt+G to jump to the source. As you'd expect, clicking on the link has the same effect as Alt+G; it just looks slicker.

Perhaps I'm so wowed because I found the feature by accident, but let me tell you, if NetBeans could do that in C, especially with #include files, I would be hooked for life! (While I'm wishing, I also want to be able to share CVS diffs via the collab tool.)

Next time I'm in Prague, I'll have to stop by and give the whole team a big hug.

Wednesday Mar 29, 2006

ILove jps!

At Sun, instead of desktops, we have SunRays. Because we're all really working on a central server, we all see each other's processes. When something goes wonky, it can be a pain to track down its PID to kill it, especially if it was spawned from a source process which then went away, which is the way most graphical tools seem to work these days. The situation gets doubly complicated when the process is a JVM, because then I have to figure out which JVM is running the class that represents the tool I want to kill. Matters are further complicated by the fact that the command line for most Java™ processes is so long these days that ps doesn't show enough of it to be tell what it's running.

All that goes away with the J2SE 5.0 platform and the new, experimental monitoring commands, like jps. With the J2SE 5.0 platform, I just run jps -l, and it shows me the running JVM's and what they are running. I'm probably late to the party and preaching to the choir, but if you've been living under a rock and haven't tried the J2SE 5.0 platform, run, don't walk, to the download center nearest you. You'll be glad you did.

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