REST -- Want to communicate with web services? You'd better learn something about REST APIs. I can't give a full tutorial here. I hardly know enough myself. But I can give you some info.

1. Give everything an id. That id will become part of a URI. Think of your application in terms of resources and URIs that access them.
2. Use the standard HTTP vocabulary to act on those resources: GET, POST, PUT, DELETE, and a few others. There's nothing complicated here. GET /customer/1 retrieves infor about customer 1 in the app. POST /customer sends customer information for a new customer. A new id gets generated. PUT /customer/1 updates some information about customer 1. And DELETE /customer/1 removes that object. Simple vocabulary. Use it.
3. Provide multiple representations of resources. You can use content negotiation or different URIs to retrieve multiple representations of the same data.
4. Use stateless communication. Avoid sessions whenever possible. Put whatever you need to process a request in the URI.
5. Finally, use some decent patterns. The container-item pattern is useful. GET /container provides a list of items. POST /container creates a new item in the container.

Some of the benefits of a RESTful architecture on the server side: scaleability, cacheable resources, reduced coupling. On the client side: resources are bookmarkable, you can easily test from a standard browser, you get broad programming language support for REST through standard HTTP, and you can get access to multiple formats for the data depending on your client capabilities and content negotiation.

Ruby -- Lots of sessions talked about Ruby or JRuby. You couldn't escape Ruby. Ruby running on Java, Java from Ruby, Ruby from Java...it's a mixed up, crazy, beautiful combination. And you know the part I really liked. Apparently, once you create your application using Ruby (and Rails of course), you don't have to sound the alarms with your IT department by introducing another server to them. Supposedly, and I haven't tried this yet, you can deploy JRuby on Rails applications as WAR files on a standard Java application server. That's impressive.

NetBeans 6.1 -- I know that you have many IDEs to choose from. And you may have already selected. But just do me a favor, do yourself a favor...take a new look at NetBeans. Version 6.1 has all-new support for JavaScript, excellent Ruby integration and editing, and access to databases and several application servers in a single download. I've been dabbling with Eclipse. I'm working with a team that's considering Eclipse as their new IDE after working with IntelliJ. I can't let them do it. I have to get back to them next week and stop them while they still have time. NetBeans, it's the only tool we're going to need to do our JavaScript and HTML front ends, business logic on the Java EE middle-tier, and even modify, edit, and maintain our MySQL database on the backside. Check out the latest NetBeans and see what you think. For more information about NetBeans 6.1, including my own more detailed review, check out NetBeans 6.1: Worth a Try.

The OpenOffice API is called UNO, and after accessing the OpenOffice APIs from NetBeans or Eclipse or any other development environment, you'll package those plug-ins and extensions as .oxt files. You or your end users will install them by using the OpenOffice extension manager or by just clicking on the extension file.

You might be the one to create the next great OpenOffice extension by integrating your application into one of the most popular open source office suites available. Learn about about OpenOffice and the UNO API by visiting the following resources:

• The OpenOffice website to get the office suite.
• Learn about the extension API.

So I attended the "Developing Java ME Applications for BlackBerry" session yesterday. They have an SDK plugin for Eclipse...and they said that some have even installed the SDK under NetBeans. Great. I can develop Java applications for the BlackBerry using my favorite IDE. Perfect.

What? The Eclipse plugin only works on Windows XP...maybe Vista. Why's that? The BlackBerry session speaker says that the BlackBerry emulator was designed for XP. Won't run on the other platforms that Eclipse and NetBeans run on -- Solaris, Linux, Mac OS X. Sure, you can develop applications using Eclipse running on any OS, but you won't be able to use the emulator. Now why is that? Really, why? So, why use Eclipse as the development tool? Might as well be a Visual Studio plugin.

There's another device with an SDK that works from an Eclipse extension. Those Sentilla devices, the ones on sale here at JavaOne. Excellent. Again, I can develop a Java application for a very small device with temperature sensors, an accelerometer, and even a radio. Very cool. I can write those Java applications using Eclipse...on Windows XP only because, well hell if I know, but that's what the booth worker says.

By the way, have you noticed the preferred operating system for most of the presentations around JavaOne? It's Windows XP by far. That's my observation anyway. Your mileage may vary.

Why is that? Why is XP the preferred OS? I have an idea, but you won't like it. Linux and Solaris are just too difficult to install and maintain for the typical consumer and even the typical developer. If you know how to tweak a kernel, or compile your own driver, maybe you'll get the mouse pad to work correctly. Maybe you'll get that bluetooth headset or bluetooth mouse to work if you find and edit the right config file.

Before coming to JavaOne, I decided to replace XP on my laptop. I put Ubuntu on it. Seemed like a good idea at the time. The application package installer was easy to use. Installing Java SE 6 and then NetBeans was easy. Ubuntu found my wireless card too. No problem. No problem until yesterday. For some reason, Ubuntu refused to display my desktop taskbar and application menu at the top of the window after I logged in. Strange for sure. Since I'm new to Ubuntu, I didn't know how to debug that. I couldn't recover.

After getting my Open Solaris disk at Community One, I figured I could install Solaris. I did. It's installed. Looks a lot like Ubuntu's desktop by default, very similar. Installing the JDK wasn't as easy. I had to install the JDK from a .sh script. There wasn't any clean, easy graphical installer. I felt a little pathetic at having grown so dependent on the easy installers we have on Windows. Although Open Solaris found my wireless card, I don't think the network tools are as easy to use as on Ubuntu. And the power manager doesn't seem to work. The os sucks the battery down way too fast. And I can't get my bluetooth mouse to work either. If I were a Linux or Unix guru, maybe I'd know the right place to find the correct settings or drivers.

After I return home, I'll definitely replace XP on this laptop. Even if I could get used to the new tools, simple installers, and the idea of compiling my own applications on Linux or Solaris, I can't use the applications I really want right now. After all, I'd really like to use that Eclipse SDK for developing BlackBerry applications. I might also want to try my hand at writing an application for some other cool Java device. Too bad the tools only run on XP.

In short, the goals are these:

1. promote a module concept for development
2. improve the Java platform by modularizing it
3. deliver us all from Jar hell
4. support the entire spectrum of Java programs from large enterprise apps, to applets, to desktop apps, to even "penlets" (maybe a reference to the Livescribe pen that's on sale during the conference)

Today, Java development is dominated by packages. Although package names are hierarchical, package membership is not. You can't easily share types and members across packages unless the interfaces or class members are public. That's a drag because it's clear that some classes are designed to work together even though they may be in different packages. Putting a public access modifier on members isn't always what you want in that situation, but it's all we currently have.

Modules in the JSR 277 definition would allow developers to associate classes and resources in different packages so that those classes can access each other more easily. Modules would logically gather those classes -- even if they exist in different packages -- into a common bag or module, providing the ability for those classes to work more directly with each other. In effect, you get yet another access modifier, something like module public or module private that would apply to class members across packages.

What's the impact of modules on the Java language and VM?

1. First, the word "module" would become a restricted keyword.
2. The JVM would enforce module-private accessibility
3. The class file definition would get another attribute that declares module membership.

How about developers? What's this module concept really mean for them? How do developers use it? Not much really changes in how you'll compile or run your applications:

1. Compile your package source just like you've always done: javac does the trick.
2. You'll package up or gather those classes and packages a bit differently. You'll use the "jam" tool to create JAM files. JAM files are JAva module files that resemble jar files. Think of them as an improved jar format.
3. Run your applications using java -jam SomeApp.jam. The only difference is a command line option. Oh, and the .jam extension instead of .jar.

Developers will be able to annotate classes (and modules) to describe modules versions, membership, dependencies, and other attributes. For example, you might use any of the following:

@Version
@MainClass
@Attribute
@ImportModules
@ImportModule
@ImportPolicyClass
@ModuleInitializerClass
@PlatformBinding
@ExportResources

Of course, you'll have to check out some of the technical docs and specs for more detailed descriptions of these and other annotations. But the info is out there. See the end of this blog for more information about resources you can use to learn more.

JAM files and modules should help deliver you from so-called "JAR hell." JAR hell basically refers to the confusion that developers and applications struggle with when deciding which versions of jar files to use. Yes, jar files can have version numbers, and they usually do. But jar dependencies are difficult to specify, determine, and enforce. And without classloader tricks, you can't use two versions of a JAR file...maybe a new version in one part of your application and an older version in another. Think that's an unreasonable expectation? It's not. Consider the situation you're in with XML parsers, for example. Your app might need one version. But maybe that same app uses a third party library that uses an older version of that same XML parser. Resolving this can be frustrating.

The new spec resolves some of this. Different classloaders handle each JAM. The modules system makes sure that:

1. JAM definitions and modules resolve properly against other JAM modules with similar names and APIs
2. JAM instances have their own class loader

The JAM specification is still in draft status. The co-spec leads say that the final spec will be available "soon," and I assume that means that implementations are not far behind.

To learn more:

• Attend the upcoming BOF-5032 on Wed night at 8:30 pm
• Take a look at the JSR 277 specification site.
• Check out Stanley Ho's blog, where he writes about Java modules frequently
• OSGi involvment

The latest NetBeans 6.1 has improved in these areas:

• JavaScript support
• Performance boosts
• MySQL support
• CRUD support for quick creation of database applications
• Spring framework support
• Ruby and JRuby support
• Mercurial support

You can find out more about this latest release by checking out my online review: NetBeans 6.1: Worth a Try. ]]> 2008-05-06T06:07:46Z 2008-05-06T06:05:23Z tag:weblogs.java.net,2008:/blog/joconner/146.9692 2008-05-06T06:05:23Z

My list is below, numbered but in not in any particular preference order:

1. Desktop Track Overview & New Features in the upcoming Java 6u10 Platform, Session TS-6649

   Java 6u10 will have features that make deploying Java apps even easier. You'll learn about the modular kernel for smaller JRE downloads, the deployment toolkit, "Patch in Place" technology for faster and smaller JRE updates, the "QuickStart Service" that improves JRE startup time, improved graphics performance (for Windows only...sigh), and the new Nimbus pluggable look-and-feel.

2. Using JavaFX Script To Build Swing Applications, TS-6609

   In my opinion, JavaFX Script was announced a little too early last year at JavaOne 2007. But the technology has matured, at least a bit more, and I think there's great potential value in this alternate tool for creating Swing applications. This presentation shows examples of how to use the language to declaratively create your UI, create custom components, animate your UI, and bind visual components to their models.

3. Deep Inside JSR 296, the Swing Application Framework, TS-6605

   After learning about the Swing Application Framework, you'll probably change the way you create Swing apps. The session teaches you about views, tasks, resource injection, and actions. Plenty of examples demonstrate how to put an app together using the framework.

4. Extending Swing: Creating Your Own Components, TS-4982

   The set of existing Swing components are great, but what do you do when you want to create really rich clients? You'll have to create custom Swing components. It's really not so hard. Attend this session to find out how.

5. Nimbus: The New Face of Swing, Session ID TS-6096

   Nimbus is the next cross-platform look-and-feel for the Java desktop apps. The look and feel is also skinnable to allow your own twist on how things should look. This session shows you how to use Nimbus to create in your Swing applications and then shows you how to extend Nimbus to create your own custom look-and-feel.

6. Extreme GUI Makeover: In the Real World, TS-6656

   In this session, you'll see the presenters transform a plain-looking application into a "stunning beauty." You'll also learn more about JavaFX Script and the new scene graph project.

7. Distributed Client-Server Persistence with the Java Persistence API, TS-5969

   Sometimes you might think that those EE guys get all the best new APIs and technologies. Not true! Desktop apps can use and benefit from the Java Persistence API (JPA) too. This session shows you how to use the JPA in Swing applications. Hey, didn't I already write that article? But I didn't cover everything you should know. In this session, you'll learn about storing data locally and remotely, syncing with remote applications, and enabling "offline" modes that synchronize data on reconnects to the network. This is great technology that you'll want to adopt into your desktop apps.

8. Designing Graphical Model-Driven Applications: Lego MindStorm, TS-6298

   Although this definitely also fits into the "Cool Stuff" category, I think there's something interesting and maybe even substantially different here for desktop application design. No doubt, there's some fun here too. Lego MindStorms! Come on, what's more fun than that? This session introduces model-driven design (MDD) as a programming paradigm for creating, drawing, and interacting with scene graphs for your graphical apps.

9. The NetBeans Platform Compared to the Eclipse Rich Client Platform, TS-4895

   This isn't a session about the NetBeans or Eclipse IDEs. This is a session about how you can use their rich client platform APIs to create your own apps, saving you lots of time. Learn about component models, UI toolkits, actions, commands, help facilities, and dynamic updates for your own rich client desktop applications. Why create all that functionality yourself when you can get it for free?

10. Beans Binding: Good for the Heart, TS-6657

    OK, someone got a little carried away with the session title, but let's look beyond that. I've looked at this API, and I think desktop developers should take notice. The "Beans Binding API" is the friendlier name for JSR 295, which simplifies how you bind beans or tie them together so that their data is synchronized. This session updates you on the project, which has been surprisingly quiet lately, and demonstrates how to use the API.

That's it! Join me for a few of these sessions this year. JavaOne is May 6-9 @ the Moscone Center, San Francisco, CA. And if you haven't registered yet, you'd better hurry.

The escape function "encodes" a string by replacing non-ASCII letters and some other punctuation symbols with escape sequences of the form %XX, where X is a hex digit. Unicode characters from \u0080 through \u00FF are converted to the %XX form as well. Unicode characters in higher ranges take the form %uXXXX. So, as an example, the name José will take the form Jos%E9. Go ahead, give it a try below:

The problem with this is that the escape mechanism is broken if you want to use UTF-8 as your document encoding. If you were dynamically composing URL strings with parameters, those parameters will definitely not be escaped correctly. Instead of Jos%E9 that URI component should really be Jos%C3%A9.

Fortunately, JavaScript has resolved the problem, but the solution means you'll have to use another function. The escape function is deprecated in ECMAScript v 3. Instead, you should use the function encodeURI or encodeURIComponent. These functions convert their argument to the UTF-8 encoding and then %XX encode all the non-ASCII characters. Two forms of the function exist so that you have greater control over whether characters like "?" and "&" are encoded. You'll need to check your documentation for details. You can experiment with the encodeURIComponent function here:

What's this mean for you? Maybe nothing if you're hopelessly attached to ISO-8859-1. However, if you're trying to reach a global market with your product, chances are very good that you've decided to use UTF-8 for your character set encoding. That's an excellent choice, but you'll have to manage the conversion points. In a nutshell, that simply means that you'll need to use UTF-8 from front to back consistently.

Part of managing those conversion points is consistently providing well-formed URIs to your application server. If you use JavaScript to manipulate data or to create dynamic URIs in your application, make sure you toss aside that deprecated escape function. Take a look at encodeURI and encodeURIComponent instead.

Here's an example: a simple web application that stores names and addresses in a database. Chances are, if you haven't done anything explicit to change this, the web page itself will have no charset encoding associated with it. And neither will your application server. And neither will your database. And without explicit settings, many applications use Latin-1 as the default character set. So, you'll be able to enter, store, retrieve, and display common Western European names, but you won't be able to handle Russian or Japanese or Chinese or, well, you get the idea.

So let's imagine you decide to convert from Latin-1 to UTF-8 so that you open up your application to the rest of the world's languages and scripts. What does that mean? What must you do? How do you start?

Here are some of the charset conversion points you'll need to resolve as you migrate through this problem:

1. database tables
2. database connections
3. application and/or web server frameworks
4. web page
5. form encodings
6. JavaScript or other browser scripts

To help you get started, I've discussed the first 4 conversion points in the article Character Conversions from Browser to Database. Go ahead, take a look. But come back here to let me know what you think. Old article, yes, for certain. However, I just ran head on into this very problem just this week. The same problems never go away, and this article had the content my team needed to resolve it in our environment.

I'll talk about some of the JavaScript issues in an upcoming blog.

Also posted to joconner.com.

You are familiar with \u notation for non-ascii characters in property files? I think the same encoding can work for non-ascii characters in any Java source file. I'm not suggesting that should be the preferred representation. I think the \u notation is only tolerable, something to be avoided whenever possible. However, in this situation -- saving files that were once in UTF-8 -- this might be the only option for storing the files without data loss.

Here's how it would work. First, NetBeans 6.1 uses UTF-8 for a project's default source code and configuration file encoding, an excellent choice by the way. So, now imagine that your source code has the Euro currency symbol in it. That's Unicode code point U+20AC. And the character itself is this: €. If you can't see the actual character (maybe you don't have a capable font?), here's the image instead:

Now, let's imagine that you need to change your project encoding for some reason. So, maybe you choose ISO-8859-1, which doesn't contain the Euro symbol. You can still represent the Euro character, but you'll have to encode it with the \u. Wouldn't it be nice if NetBeans did this for you, creating \u20AC in your file instead of converting the character to a meaningless ? question mark. I think that would be better. And it's entirely possible. It doesn't prevent NetBeans from converting the file to the target encoding as requested by the user, and it allows NetBeans to prevent data loss by using the \u encoding for characters that are not in the target charset.

So, what do you think? Maybe the NetBeans team can get this into the 6.1 product before final release?

Have you seen NetBeans 6.1? Give it a try, and blog about it. Who knows, you might win $500!

Also posted to joconner.com.

The "call for participation" is an invitation for Unicode gurus, clients, and vendors to submit papers for this upcoming conference. Learn more at the Unicode Conference web site.

Also posted to my software internationalization blog at joconner.com

• the data charset can represent all modern, useful -- and many not-so-useful -- scripts
• charset consistency helps prevent data loss across application boundaries, including those among application, business tiers, application servers, and databases
• a single, multilingual charset simplifies the localization process

I was pleased to see that NetBeans 6.0 and the 6.1 beta uses the UTF-8 encoding (a Unicode encoding) as its default for project configuration and source files. The following figure shows the default setting in the project's property sheet:

This makes it much easier to edit non-ASCII, non-English source and property files. You can type text in any supported Unicode script right into Java source code. A legitimate usage would be comments or even localizable text in ListResourceBundle files. You can do that because NetBeans will save your files using the UTF-8 encoding by default...and NetBeans even puts this setting into the project's Ant file settings so that it compiles the file properly using the correct javac arguments. For example, NetBeans would use the following for a UTF-8 source file:

javac -encoding UTF-8 YourSource.java

Despite the potential benefits of this, NetBeans 6.1 still doesn't support this correctly in my humble opinion. Why not? Well, the biggest reason is simple: file corruption and permanent data loss. Ouch!

Let's take a simple "Hello, world!" example in Japanese. This is simple for NetBeans because of the UTF-8 encoding. The NetBeans editor even displays it correctly as shown here:

Unfortunately, the joy of this discovery was short lived when I discovered how easy it is to corrupt this data. Feel like experimenting with the charset encoding? Surely someone will. I suspected what would happen, so I didn't do this with any substantial code base...but someone will. I sure hope they use version control software.

Reopen that project property sheet, select another encoding, say ISO-8859-1 or windows-1252 since so many American and Western-European programmers use that by default. What happens? It appears as if nothing has happened. In this NB 6.1 beta, I see the same editor screen as before. NetBeans apparently hasn't yet reloaded the file from disk, so I'll force the issue by closing and reloading this file. The result is here:

Some of you, the super careful, nit-picky ones will now argue with me, "But John, you haven't really lost anything yet. 8859-1 and CP 1252 don't have those characters, but the original byte values are still entact. You can get them back in this example." OK, I concede the point. But now I'll show you some serious data loss, no messing around this time. Instead of ISO-8859-1, pick US-ASCII as the target charset. Add a comment or another line of code to the file. Save. And there you have it as shown here:

Now that's just not good. Did NetBeans save the file correctly? Sure. However, NetBeans can do better than this. I would argue that if NetBeans knows that the target encoding does not support the source encoding, it should at least warn the user that the resulting file will contain garbage characters and that parts of the file will be lost--permanantly in many cases.

So, just in case anyone over there in the NetBeans developer group can hear me...you have to fix this. Yes, I know it's a silly mistake for someone to do this, but NetBeans can help them avoid the problem. Just provide a warning dialog, "Saving this file in the target encoding will cause data loss because the target encoding does not support all characters in this file or project." Keep the encoding feature, just perfect it by helping some users avoid this costly mistake. The fact is that most software developers still don't understand character sets and encodings, and this is just an accident waiting to happen.

On a personal note: I really love NetBeans. And I hope this blog qualifies me for the NetBeans 6.1 blogging contest! I could probably file this under the "suggestions on how to enhance NetBeans 6.1" category.

Although I was there last year -- writing, blogging, communicating to the community -- I don't have a pass to JavaOne 2008 yet. Unfortunately, I have no concrete plans. No corporate or community sponsor has agreed to help yet either. It's a sad, sad thing. Indeed, these are trying, desperate times.

I want to go to JavaOne...and I'm willing to take drastic action. Sure, I could just put up the money myself. The $1595 price tag for a 4-day pass is expensive but not entirely out of my budget. Still, there's no fun in that, especially if I can do something more interesting than just sending in the registration cash. So, I'm going to do something a little different in order to participate this year. I'm hiring myself out!

Yes, that's right. The first sponsor to offer a full 4-day Conference Pass and room will receive my professional consulting/writing/blogging/programming/go-fer services for the duration of the event!

Here's what you'll get:

• One full week of blogging for your products of choice at the JavaOne conference.
• Booth duty...you know you need a break from the pavilion booth at some point. Let me help.
• A feature article...or two...from me if you're the editor of a Java-related journal.
• Any other reasonable task that you might need.

Yes, it's a bit unusual. But the JavaOne conference is unusual too. I think this is going to work out just great.

You know how to reach me: john at joconner dot com.

I recently wrote a brief introduction to Beans Binding called Synchronizing Properties with Beans Binding. I was enthusiastic about Beans Binding, and then a coworker threw a wet towel on me. The conversation went something like this:

John: I just finished an article on java.net. This API might be useful in this project.

Coworker: Yeah, what's that?

John: Beans Binding. It's an API that will help us bind beans together, synchronizing properties.

Coworker: What do you mean?

John: You know...say you want to update a table with new data anytime a result set changes, or maybe you want a price field to display the current total of all purchased items in a shopping cart. You can use beans binding to synchronize the properties without having to write all the plumbing and event handling yourself.

Coworker: Hmm. Java hasn't always had that?

John: Well, yes. Java has always allowed you to synchronize properties, but we've never had an API to make it this easy.

Coworker: Really? We've had this in Flash and Flex forever.

John: You've had binding?

Coworker: Binding, or Beans Binding...whatever you call it. We can bind a variable or property to another variable or property so the updates trickle throughout the application. It's a great feature, a must-have, and I couldn't do without it. I use [Bindable] among other things.

John: Yes, it's great. I agree. So take a look at that article. Beans Binding, it's pretty cool.

Coworker: You're just getting binding in the Java language? Hmm... really? I just assumed Java would have had that all along.

John: Um, it's not exactly part of the language. It's a new API. Making changes to the language is difficult and usually takes a long time...

Coworker: Oh, I misunderstood. It's not part of the language? Just a separate API? Got it. Hmm...ok. Well, uh, gotta run.

John: Hey, wait. But Java FX Script has a bind keyword that is part of the language. Remember? I told you about Java FX Script earlier.

Coworker: Right. Java FX Script. It's about time Java got got a bind operator or keyword, something.

John: No, not Java. Java FX Script. That's the new language for rich client app development. Java FX Script has the bind operator. Java has the Beans Binding API.

Coworker: OK, right...well...hey...I have to get back to work on this Flex app. But I agree, binding is great, couldn't do without it, use it all the time.

First, I like to hit java.sun.com first thing in the day from my workplace. That's been a cubicle environment recently. I can quietly read a text article, even print it and read it later during a lunch break. Unfortunately, I can't do the same with the videos. They're fun, sure, but unwatchable because video and audio are distracting to others in the office. Bandwidth issues aside...people just don't like to hear this from another cube. I understand that, so I don't intrude on their peace and quiet. Unfortunately, the video is inaccessible to me. And when I get home, well, there's a better than even chance that I won't watch a tech video then either.

Second, the videos are inaccessible to those with hearing or sight impairments. Seems obvious, right? Can't hear...the audio isn't usable. Can't see...can't watch the video either. I suppose you could listen to the video -- but not in my cube. So, the videos are inaccessible to others too. Granted, those who can't benefit from the videos are a small minority. Still, wouldn't it be nice to include them as far as possible?

I think a solution is possible. Video is a great idea for java.sun.com, and clearly the medium is popular. Just witness the popularity of YouTube, etc. I think the videos could be improved though with something very simple. Transcripts.

Providing a transcript with the video would allow cubicle dwellers access to the content. The same transcript makes the content accessible to hearing and site impaired developers too. Can't hear -- you can read the transcript content. Can't see? Text readers exist for that case. Either way, the videos become more accessible to a larger group of people.

Is this a complaint? No way. I enjoy practically all of the content provided by java.sun.com. This is just a friendly suggestion, hoping that it will bring the content to an even wider audience.

It has been a long, long time since I last worked in a cubical environment. I find the experience undesirable but tolerable. It makes me curious though...just how many of us work in a cube environment? Might be a great polling opportunity for the java.net editors...