Building the IDEA Groovy Plugin

It took me a little effort to get Idea's Groovy Plugin built, so I thought I'd share my experiences for those who don't want to fall in the same traps.

I started from some instructions on the forums, but still had trouble. Some filenames were wrong, and working on the mac changed some of the details. Here are my revised instructions:

• Update to a new EAP of IDEA. The plugin wasn't built for IDEA 6
  
• Checkout the project from http://svn.jetbrains.org/idea/Trunk/groovy/
• When you first open the project, you may be asked to make a variable association. I pointed the templates variable to ${project}/resources/fileTemplates
• I had to create a new Intellij IDEA SDK pointing it to my IDEA installation
• Add tools.jar (on windows) or classes.jar (on the mac) from your JDK installation to the SDK classpath
  
• Add idea.jar from your idea installation (on the mac, the file is /Applications/Selena-6951.app/lib/idea.jar) to your SDK classpath
  
• There are already two ant scripts in the ant window. Run the one called generate lexer from groovy
• Run the build>make command from IDEA's menu
• Run the build>Prepare Plugin Module 'groovy' for deployment command from IDEA's menu
• A zip file will be generated to the project directory. Copy it to IDEA's plugin directory and unzip it.
• Restart IDEA
  

I've attached the file for those daring enough to install software from some stranger's blog: groovy.zip

JavaFX in Perspective

The large number of discussion about JavaFX over the last few days seems be very polarized. So far I have only read two opinions repeated over and over:

1. JavaFX is the competitor to Flash and SilverLight that we've all been waiting for.
2. JavaFX is a weak attempt to cash in on the recent SilverLight announcements and has no chance for success.
   

What most people don't seem to get, is that JavaFX isn't even in the same market as Flash and SilverLight. It's much more appropriate to compare JavaFX with XAML or Flex (just the markup language, not the action script, runtime environment, multimedia support or animation).

Both Adobe's product line and Microsofts are made up of several packages:

• A runtime environment - The Flash VM and the .Net Runtime
• A declarative UI language including widgets - Flex and a light version of XAML
• A declarative animation language - Flash and XAML
  
• A scripting language for procedural logic - Action Script and JavaScript
• A development environment for each of these three languages
• Multimedia components - video and audio playback is supported well as first class components in both frameworks
  

Of course JavaFX runs on the Java runtime environment, and it defines a very nice language for declarative UI building and a decent language for animation... but that's all it tries to do.

Sun has yet to show any interest in completing the rest of the picture.

• It could be argued that some work would need to be done to the JRE before it could be light enough to compete with Flash or Silverlight as a runtime environment (at least ease of installation could use some work).
• JavaFX has no equivalent to JavaScript. Although one could theoretically use Java, Groovy, Javascript or some other language for procedural code, the binding isn't nearly as nice as the integration the other two frameworks have with their scripting languages.
• Netbeans provides some syntax highlighting and code completion for the language, but it's barely better than notepad when compared to the authoring tools being offered by Adobe. To take on the competition, Netbeans will need timeline driven animation and Matise-like component layout from day one. On day two, we need vector drawing tools to compete with Illustrator and Expression (tie-in with existing tools might be a nice stop gap).
• Multimedia support has always been a weakness in Java. JavaFX is the neon sign pointing out one of Sun's often ignored weakesses.
  

With all that said, JavaFX compares very nicely to Flex and XAML when ignoring their sister technologies. Feature for feature it compares nicely. Without the rest of the package, of course, it's all pretty academic. Assuming Sun is really serious about taking on Adobe and Microsoft, they still have a lot of work ahead of them.

WPF & Flex

I went to a .Net User's Group meeting about WPF tonight. The speaker was Walt Ritscher. The presentation was a pretty decent intro. I was expecting it to be quite a bit more in depth. I guess I figured .Net developers would already be up to speed on WPF and an intro presentation would be beyond them at this point. I seem to make a habit of setting my expectations a little too high for most user group presentations.

I recently signed up for a membership at lynda.com, which provides instructional videos on many technical topics. The subject matter tends to lean towards creative tools (Photoshop). I've been watching the Flex training videos and I can't help notice the similarities to what Microsoft is doing with WPF. Macromedia really seemed to have missed the boat by brining application development to Flash so late in the game, but they seem to be catching up well now that Microsoft has put some fear into them. Since Adobe took over, they've kept going strong.

Of course both Flex and WPF/E are both proprietary technologies that have fairly useless free SDKs and $600 development environments for the serious user. I haven't seen any free alternatives with anything close to the capabilities. Both SVG and F3 have similar capabilities, but F3 isn't open and lacks the development tools and SVG lacks good browser support.

Oh well... guess we'll have to put up with Ajax for a few more years.

Swing and Vendor Lock-in

10 years ago Sun introduced Swing, and with it, JavaBeans. JavaBeans were supposed to allow UI widgets to be defined as components. It would allow Swing developers to take advance of graphical layout editors without vendor lock-in. It failed.

Those who tried to develop Swing apps with their IDE's drag and drop editor forced their way through limitations and learned how to hand-code fixes that wouldn't break their IDE's code parsing. Then support would dry up for their favorite tool and they would be left with no alternative, but to hand-code their Swing apps. Others recognized the graphical tools as Microsoft-style lock-in and avoided it early on. For almost a decade, hand-coded Swing apps have been the norm.

10 years later, Sun is trying again. They seemed to have missed the point of their initial failure. They seem to be under the impression that had the first tools been of higher quality, people would have never resorted to hand-coding their Swing apps. In reality, it was the proprietary nature of the IDE-generated code that caused the failure. No matter how well the tools would have worked, Java developers have been conditioned to demand vendor neutrality.

Vendor neutrality is not something developers get from Netbeans and Mattise. As nice as the platform is, the code it generates is not parseable by any other platform. Because it doesn't generate code to a standard, such ad-hock compatibility wouldn't be enough anyway.

This problem has already been solved, of course. Ironically, one of the latest solutions is from Microsoft. Although XAML is a closed standard, it is a standard. It's well defined and parsable by multiple editors. A Swing solution wouldn't have to be as feature heavy as XAML. There are many open source solutions that fill the need. Of course they would need to be adoped by Sun (presumably via a JSR) and the IDE vendors to be a useful vendor-neutral solution. Until this happens, Mattise is just another way to lock your application to your IDE.

Saving Files

I'm not sure when it happened, but at some point since I started using IDEA I lost the concept of saving my source code. Since version 2* IDEA has automatically saved changes when focus to the window was lost. I don't really know how long it took, but over time I stopped paying attention to file saving. From time to time, I would edit a text file in notepad or use someone else's IDE and bang my head against the wall as I tried to run without committing my changes. Apparently it was a common mistake. Eclipse eventually added a warning dialog: "You have unsaved changes. Would you like to save them before you run your program?". What the hell kind of question is that?!? Why would I have changed my code, and run my program if I didn't want to see those changes reflected in my application?!?

I guess having a warning is better than what notepad does... but then again, is that really the mark of a great IDE: "at least we're better than notepad!"

*version 1 of IDEA was a JBuilder plugin, so it might have been a little silly to do it then

Plain Old Java COMPONENTS

I've been reading about the various proposals for adding properties and events to the Java language. In the process, I stumbled across an interesting blog entry by Richard Bair which he starts by describing why JavaBeans don't break encapsulation. For a long time, I've believed Javabeans were an abomination. Despite the intentions of the creators a technology is eventually defined by how it is used. With the exception of a couple dozen Swing components, the JavaBeans patterns is used by most developers as a loophole allowing programmers to break encapsulation.

When Richard describes the original purpose of JavaBeans, he's describing a framework that was needed very badly for allowing tools to interact with components. If properties and events are added to the language, it would go a long way towards cleaning up the interface between components and their tools.

What I don't see it helping with, however is the programmer's understanding of what they are doing when they make a component. When someone implements the JavaBean pattern, they are agreeing to an existing contract. I know very few programmers who understand that contract. None of them seem to understand that they are building a component. They have been told by the good people at Hibernate or the people who made their databinding framework that they were making plain-old-java-OBJECTS.

Plain Old Java Objects. Like every other Java object out there. But Hibernate doesn't work with just any Java object, does it? It only works with Java objects that strictly meet the contract set by the JavaBeans pattern.

Of course the market has picked the term POJO to emphasize the difference between today's tools and those requiring implementation of multiple interfaces and the addition of specific behaviors to your objects. As horrible as those frameworks were, they were object-oriented. Of course, since the buzz of the term object-oriented hasn't died down, we don't want to tell people that we've transitioned them to component-oriented programming already.

Cruise Control Montior

When moving my blog to from Movable Type, I noticed a handful of posts that were still unpublished. One was a reference to a tool I put together about a year ago. It's a status screen for Cruise Control build results. If you're monitoring more than just one project, lava lamps are a bit of a pain.

IDEA 7 Milestone 1 Roadmap

Intellij has made their roadmap for version 7 available. I don't see anything real exciting at this point, but I'm usually more impressed by their implementation than their feature list.

At least its commented...

I'm going through some old java code ('96ish) that has collected some odd band-aids over the years. Most make me scratch my head. I just ran into one that was at least documented. As strange as it was, I guess at least I know what the devloper was thinking:

The data members of this class must be alphabetized so that connections can be processed by VisualAge for
Java, and some were renamed using rather peculiar names in order to allow the alphabetization of
the fields.

Presentations & Reading Material

Over the past few months, I've run across quite a few good sources for Java programming information. I thought I'd share a few here:

Ben Galbraith's Professional Swing: Creating Polished Apps was originally presented in the No Fluff, Just Stuff Symposium. The first section is basic entry level stuff, but the second part (Professional Swing: Threading) hits some topics that many Swing developers overlook. If your still making database calls from your event listeners, please take a look at this presentation... your making us all look bad, and we need you to stop!

If you're having trouble keeping up with all the latest changes in the Java world, and have more than a few minutes of drive time in the morning, try downloading The Java Posse. I was really surprised how much interesting information they have to talk about. They go through a very good mix of topics each episode (not like many web based news sources such as digg, slashdot, the servers side, etc).

JavaPolis has been offering a DVD of all they presentations at the event. I got mine a few months ago for around $50 (give or take after the exchange rates). There's a lot of good material on the disc. All of the presentations are in the same flashed based format as the Swing presentations above. Many are the same presentations presented at Java One. Sun has also posted the presentations from Java One on their site, but I haven't gotten to take a look at them yet.

Ignorance is Bliss

If you believe that ignorance is bliss, then you want to avoid 'Java Concurrency in Practice' by Brian Goetz. In fact you may want to try to avoid talking to anyone who has read it. I've only made it halfway through, and I feel like the little kid in 'The Sixth Sense' -- I see bugs everywhere. When I close my eyes, I see code I wrote six months ago - BUGS! When I open them I see them in the projects I'm working on, and the ones I maintain.

These aren't big, bugs that cause everything to stop working every time. Nope. These are those little strange ones. When you upgrade your server, and that app you haven't changed in 2 years suddenly starts spitting out an incorrect value every couple days.

And these aren't race conditions or deadlocks. Most programmer I've worked with have at least a basic understanding of how race conditions can occur (at least I like to think they do). The bugs I'm talking about are visibility bugs. Values hiding on the processors cache, that don't get flushed back to main memory (yes, it's java, but it still runs on a computer).

Java Concurrency in Practice does a very good job of explaining these kinds of issues and how to deal with them. I think it does a much better job than Doug Lea's book, which I'm sure is packed with knowledge, but isn't very accessible. In comparison, Java Concurrency in Practice is much more conversational. It's also (of course) much more up to date.

On a side note, I bought this book at the prompting of my IDE. IDEA kept highlighting threading issues in my code. Its explanations seemed very strict, and I wanted a better explanation of why it thought I should change my code. I thought for sure it was making assumptions and making an issue out of nothing. But since IDEA had always given me good advice in the past, I thought I'd look into it. Any decent IDE will teach you the language's syntax or api (via error highlighting and auto completion), but it takes a pretty damn good IDE to teach thread safty!

Good Audio Content

For those who are looking for good technical discussions to listen to on the way to work in the morning, Bruce Eckel has a very interesting series of interviews available. I've listened to about half of them now, and some are very interesting. I epecially enjoyed the interviews with Tim Lister and Ron Jeffries.

On the downside, my reading list (which was already a bit unrealistic) has grown by a couple books as a result of listening to these interviews.

new SQL keyword: might-be

Have you ever known someone who still confuses relational databases with flat file structures? Someone that would rather have the application define data relationships than constrain them in the database? I would like to propose a compromise with those people by introducing a new sql keyword. Take a look at the new might-be constraint:

alter table SCHEMA.MY_TABLE add might-be constraint MY_TABLES_FK foreign key (ASSIGN_ID) might reference SCHEMA.OTHER_TABLE(ID);

Why IDEA Rocks - Reason #715

It's hard to explain why you can like a product like IDEA. One whose feature matrix wouldn't even hold up to a 4 year old copy of JBuilder. But it isn't that container managed enteity bean wizard that saves you from pulling out your hair. Its these thoughtful little features that never make it to the feature matrix on the side of the box:

Why IDEA Rocks - Reason #714

I've been using IDEA since version 2.5, but still a couple times a week, I stop what I'm doing to laugh a little at some small but brilliant feature that helped save me. The one I found today was even more trivial than usual, but it still made me smile.

When I see the red squigglies I now instinctively mash the keyboard: ALT-ENTER. Before I even read the message; before my brain has even interpreted the line of code my cursor sits on, I mash the keyboard. This time, here's what I saw:

I was looking at this thinking about how the system knew I should call getPredefinedCursor(). I still can't come up with a generic rule that might have been triggered by this situation. Somewhere in IDEA's code, there's a rule waiting for me to pass an integer into a method as a Cursor, so it can popup this intention. Not that is attention to detail!

UPDATE: In a comment (not transfered from MovableType), Keith Lea points out: "The general rule is that for a call to M(X x) passing value of type Y, IDEA suggests any static method in class X which returns X and takes only Y as a parameter."

Design Driven Testing

I imagine by now, everyone has seen the Waterfall 2006 Conference. In the spirit of their Refuctoring presentation, I would like to present an interesting topic: "Design Driven Testing"

In Design Driven Testing, your painstakingly crafted, flexible code
determines the types of unit tests you write. Because these tests will need
to exercise your code without requiring changes to the design, they
may need additional complexity. But as everyone knows, it's easier to test one big method than several small ones!

Some implementation suggestions:

• Generate test data - since your methods under test are now large and complicated flexible, your test data needs to be a bit more complex. With a few well placed unix scripts, you can generate the java code necessary to test your java code.


• Use smoke tests - There's no need to test every possible combination of inputs. With a large flexible method, that wouldn't be very pragmatic. Instead, try a happy-path test. If you can run the logic through a couple common scenarios, it probably won't break when boundary conditions arise. Feel confident in your programming skills!

Swing should take a hint from Avalon

I�ve been reading a book on the Windows Presentation Foundation (Avalon). When I got to the chapter on panels, I was pleasantly surprised. Panels control their own layout (rather than having multiple layout managers, WPF has multiple panels that have different layout behaviors). The panels available in WPF seem to mirror those in Swing, with many subtle, but powerful advancements. Many of these advancements are glaringly obvious to anyone who�s used Swing more than twice: Why can�t you stack more than one thing in the north location of a BorderLayout? Why can�t you specify that the sides get control of the corners in BorderLayout rather than the top and bottom? Why does GridLayout always have to stretch my components? There are many of these simple little annoyances that drive developers directly to using GridBag for everything (or adopting a third party library).

Sun believes they are just setting the groundwork with Swing, and leave it to the third party developers to make further advances. I find this to be a cop out. Why can�t Sun spend a couple weeks of man hours to clean up the existing layout managers. They already have things 80% there (they were good enough for Microsoft to copy from). But for years we�ve seen no improvements from Sun (Spring doesn�t count as an advance - a step backwards, maybe). If Sun wants us to believe that Swing isn�t dead, maybe they should stop treating it like it already is.

Programming Philosophy

I like to analyze my co-workers � to understand how they think. Understanding my co-workers helps me work better with them, and gives me a little perspective on my own future direction. One of the early indicators of how well I would get along with a co-worker was how much they liked technology. I found myself much more interested in working with others who had the same passion for programming that I�ve had. After a while I found that not everyone who loves programming is especially good with it. I�ve found that a lot of it has to do with early programming experiences and what philosophies of programming they consider important.

For example: Which of the three basic principles of object oriented programming do you find more important: polymorphisim, encapsulation or inheritance?

Those who say inheritance value the ability to change an objects behavior. They aren�t as interested in this for the sake of masquerading one object as another (or they would have said polymorphisim). Instead they find it important to repeat as little code as possible. People who find inheritance very important have a tendency to inherit from unrelated objects simply to pick up behavior. They tend to believe in deep hierarchies and flexibility in object models, even if it risks complexity.

Those who prefer polymorphisim also love design patterns. Some like polymorphisim because it makes for elegant code. Most like it because � let�s face it � polymorphisim is cool. It makes you seem really smart. I don�t mean to make fun of these people. Polymorphisim does help you write some very elegant code sometimes. I just don�t think it�s an especially important tool in writing good software.

I put myself in the category of programmer who believes encapsulation is the more important characteristic. With encapsulation you separate responsibilities cleanly and provide easy to understand code. Someone who looks at well-encapsulated code has much less to understand before being able to make changes. If there is a downside to leaning this direction, I haven�t found it yet.

Another question that may explain a lot about your programming personality: What is more important to you in application code: reusability, flexibility, maintainability?

(Side note: I debated about putting Performance in the list above, because I�ve known many programmers who would place Performance above all three other choices on the list regardless of the purpose of the application. I didn�t include it because I believe this is a decision based on ignorance rather than preference or philosophy. I don�t consider ignorance to be a personality trait.)

Those who favor reusability fall into one of two camps: Those who subscribe to the DRY principle and don�t want logic repeated in multiple places; and those who think the idea is to minimize the number of line of code in a program (as if it makes the code more maintainable to share code between unrelated pieces of logic simply because they look similar when you do a text compare against them). The former group has a very strong argument, and while I don�t disagree with the philosophy, I simply don�t rate it as high as others. The later group should be shot. Fired, then shot.

Those who think that flexibility is more important than reusability or maintainability are very hard for me to deal with. They believe that if they can write the code, then anyone with an education should be able to read it. Therefore, maintainability is not an issue and they should instead dedicate their time to making the code do more. These people usually don�t have the social skills to deal with the domain experts, and write flexible code to substitute for communication. Since agile methodologies have become more popular, this programmer has had less and less ground to stand on.

Personally, I find maintainability to be the most important thing to keep in mind while writing code. Code is in maintenance far longer than in development. There are also far more remedial programmers than advanced programmers. Much more cost goes into maintaining code than developing it, and the ultimate goal of any commercial software is to make or save money. I find maintainability to be more important than reusability because maintainability is the driving purpose behind reusability. Why DRY? So you can make the change in a single spot. So you can read the code easier. Why is encapsulation so important? To make it easier to maintain the code. I find maintainability to be at the root of all good software decisions, and I think it is ignored way too often.

So what do you value, and why?

The IBM Solution

Once upon a time, in a land far, far away, a large manufacturing company spent many months and an untold fortune on a system to print RFID tags for their product labeling. IBM was entrusted to make the technical recommendations. Here�s what they had to work with:

The company as a whole is an International mega-corporation, whose primary source of technology is Microsoft. The engineering division contains a small group of Java programmers who write mostly Swing applications. They have a couple servlet apps, and recently introduced their first JSP app (although only two programmers have any JSP knowledge). They have never used J2EE (in fact I doubt anyone would be able to accurately describe J2EE). They deploy only to Windows (even their servers run on windows).

So based on that, what do you suppose IBM�s recommendation would have been?

A J2EE app running on Linux using a front end based on Portlets? Sure! Why not? When all you sell is hammers�

Conversing with Technology

Most middle managers seem to have a large knowledge gap when it comes to web apps. Very few seem to understand that HTML is a markup language meant to format text. Any other use of it is the result of a series of clever hacks. Because those hacks have been so successful, many don�t differentiate between web applications and any other application. The lines between possible and impossible, and cheap and costly seem arbitrary to them.

After years of fielding some seeming ridiculous questions, I decided we should cut out the middle man. Management should skip the developer and ask the programming components themselves to do the job. What would happen if technology could talk, and we removed the developer from the equation?

PHB (Pointy-Haired Boss): My web reports need more advanced printing. I�d like to allow the user to check off all the reports they need to print and press a single button. Then all the reports should print at once. How long would it take you to implement that?

HTML: Why are you asking me? I just format text.

PHB: Format text? My web applications are written in HTML. Surly you do more than that?

HTML: Actually I don�t even really format text. I just mark it so CSS can format it. I used to format text, but someone decided that would be too much responsibility for one technology, you see, I also link to things. You should talk to the web browser. He knows how to print.

PHB: I need to print a bunch of reports from a web page. Can you do that?

Internet Explorer: Sure. I can print web pages. Just load one up, press the print button and repeat.

PHB: No. I want to press a button in the web page to cause many pages to print.

Internet Explorer: If you want to press a button within the web page to print, you need to talk to Javascript. But I'll only print one page at a time, no matter what he says.

PHB: Ok. Javascript, how do I initiate printing from within a web page?

Javascript: If you issue this command, I can pop up the print dialog for quite a few browsers: window.print(); � I can�t promise anything though. Ultimately, its up to the browser.

PHB: Can you print more than one page at a time?

Javascript: I can only pop up the print dialog for the current page. But I can also open as many windows as you want and pop open the print dialog on each of those? Then you would have a bunch of windows, and a bunch of popup dialogs. Or I could open a single window, popup a print dialog, open a new report in the same window, and popup the dialog for it�

PHB: Can we just have one print dialog?

Javascript: All I can do is open the print dialog for a single web page. Maybe you could talk to the app server about getting everything on one page for me. For as much as you paid for him, he should be able to do anything!

PHB: Good idea. App server, can you help me with something?

ISphereLogic: I�m a massively scaling, on demand, multi transactional, threaded, secure enterprise application environment. I can do anything.

PHB: Can you merge multiple pages together so they print all at once?

IsphereLogic: Well� I have minions who can. Try Servlet, JSP, Struts or XSLT. They should be able to help. If they don�t you could talk to any of the CGI solutions, ASP or one of my more proprietary cousins.

PHB: I know my developers were using Struts before. I read about it in InfoWorld and had them switch everything over to Struts because it got 4 stars in the CIO Report. I�ll ask him. Struts� can you help me?

Struts: I am only a controller. I do not handle any trivial matters such as view or data. You should talk to JSP.

PHB: Ok, I�ll�

Struts: But first, you must subclass Action and add entries to web.xml, struts.config and tiles.config before I allow you to talk to him.

PHB: err� kind of controlling, aren�t you?

Struts: It�s what I do.

[15 minutes pass]

PHB: JSP? Can you put these reports on a single page?

JSP: Sure, as long as the data needed is here and the application server lets me. It will probably work.

PHB: I think I have it working, but this sure seems like an unstable house of cards. I hope nothing goes wrong. It sure would be nice if there were someone between me and these technologies to blame if it did.

PHB: Hmmmmm?

Conversing with Technology

Most middle managers seem to have a large knowledge gap when it comes to web apps. Very few seem to understand that HTML is a markup language meant to format text. Any other use of it is the result of a series of clever hacks. Because those hacks have been so successful, many don�t differentiate between web applications and any other application. The lines between possible and impossible, and cheap and costly seem arbitrary to them.

After years of fielding some seeming ridiculous questions, I decided we should cut out the middle man. Management should skip the developer and ask the programming components themselves to do the job. What would happen if technology could talk, and we removed the developer from the equation?

PHB (Pointy-Haired Boss): My web reports need more advanced printing. I�d like to allow the user to check off all the reports they need to print and press a single button. Then all the reports should print at once. How long would it take you to implement that?

HTML: Why are you asking me? I just format text.

PHB: Format text? My web applications are written in HTML. Surly you do more than that?

HTML: Actually I don�t even really format text. I just mark it so CSS can format it. I used to format text, but someone decided that would be too much responsibility for one technology, you see, I also link to things. You should talk to the web browser. He knows how to print.

PHB: I need to print a bunch of reports from a web page. Can you do that?

Internet Explorer: Sure. I can print web pages. Just load one up, press the print button and repeat.

PHB: No. I want to press a button in the web page to cause many pages to print.

Internet Explorer: If you want to press a button within the web page to print, you need to talk to Javascript. But I'll only print one page at a time, no matter what he says.

PHB: Ok. Javascript, how do I initiate printing from within a web page?

Javascript: If you issue this command, I can pop up the print dialog for quite a few browsers: window.print(); � I can�t promise anything though. Ultimately, its up to the browser.

PHB: Can you print more than one page at a time?

Javascript: I can only pop up the print dialog for the current page. But I can also open as many windows as you want and pop open the print dialog on each of those? Then you would have a bunch of windows, and a bunch of popup dialogs. Or I could open a single window, popup a print dialog, open a new report in the same window, and popup the dialog for it�

PHB: Can we just have one print dialog?

Javascript: All I can do is open the print dialog for a single web page. Maybe you could talk to the app server about getting everything on one page for me. For as much as you paid for him, he should be able to do anything!

PHB: Good idea. App server, can you help me with something?

ISphereLogic: I�m a massively scaling, on demand, multi transactional, threaded, secure enterprise application environment. I can do anything.

PHB: Can you merge multiple pages together so they print all at once?

IsphereLogic: Well� I have minions who can. Try Servlet, JSP, Struts or XSLT. They should be able to help. If they don�t you could talk to any of the CGI solutions, ASP or one of my more proprietary cousins.

PHB: I know my developers were using Struts before. I read about it in InfoWorld and had them switch everything over to Struts because it got 4 stars in the CIO Report. I�ll ask him. Struts� can you help me?

Struts: I am only a controller. I do not handle any trivial matters such as view or data. You should talk to JSP.

PHB: Ok, I�ll�

Struts: But first, you must subclass Action and add entries to web.xml, struts.config and tiles.config before I allow you to talk to him.

PHB: err� kind of controlling, aren�t you?

Struts: It�s what I do.

[15 minutes pass]

PHB: JSP? Can you put these reports on a single page?

JSP: Sure, as long as the data needed is here and the application server lets me. It will probably work.

PHB: I think I have it working, but this sure seems like an unstable house of cards. I hope nothing goes wrong. It sure would be nice if there were someone between me and these technologies to blame if it did.

PHB: Hmmmmm?

Language Oriented Programming (Pt 2)

In a comment to my last post, Rob Harwood (from JetBrains) pointed out a great article by JetBrains Co-founder and CEO Sergey Dmitriev on Language Oriented Programming. In it he goes in to a good deal of detail about their latest product/experiment: The Meta Programming System (MPS).

The article is very interesting. It provides a high level breakdown of each part of MPS and promises many more details in the future. I think the article is a bit more complicated than it needed to be. As an example, Dmitriev shows us how to construct MPS using MPS (not exactly �Hello World�). Overall, I think he gets his points across well. Those parts requiring more detail usually promise future articles on the subject (which I am definitely looking forward to).

There were quite a few concepts that I wasn�t really expecting. The first was that the languages created in MPS will be able to easily take advantage of advanced editor features such as refactoring, code completion and syntax highlighting. This could be really powerful. A language specific to my area of business may have IDE features more powerful than many well-established languages.

I also liked that the languages can generate code for any number of general-purpose languages (Java, C#, C++, etc.), or they could generate code into another MPS language. Because of that, languages can build upon each other. My accounting language might compile down into the MPS base language (which defines common language constructs, like jstl�s core library does for JSPs). The base language knows how to compile down to a dozen general-purpose languages. In effect, my accounting language supports a dozen programming platforms for free.

I also like that these are languages rather than libraries. It allows them to offer all the features that C++ promised (model the language after your domain) without all the mess, and hopefully requiring much less discipline.

I still have questions about Domain Languages in general. One thing I wonder about, is how this will effect separation of duties if it were to take off. Assuming companies write their own languages, would some programmers write domain languages, while others use them? Could languages be reused effectively, or will every company end up with their own?

I�m still not entirely convinced that creating a domain language can be easy (I don�t know if I�ll be a believer until I try it myself). I am looking forward to reading more about it.

Language Oriented Programming

Jetbrains (maker of IntelliJ IDEA) is working on a new project internally referred to as MPS (Meta Programming System), which looks very interesting. It�s based on a concept called Language Oriented Programming. Essentially, they want to make it easy to create domain specific �languages� allowing programs to be written at a higher level. In this case a language could be visual (like UML) or textual. It might be structural or declarative. Its only important that the language suits the domain. Each language would be closely tied to an editor used to manipulate the language. This domain level language would eventually be used to generate a lower level language (like Java or C#). This allows the domain specific languages to interact via the lower level languages.

In college, I was always told the next evolution in programming languages would come from natural languages. One day I would just sit down and explain in plain English what I wanted the computer to do, and it would just do it. Of course even the teacher was smiling at this point. Most business problems are hard to explain to other people without first defining 20 terms, creating a lexicon of shapes and filling a white board at least a couple times. I couldn�t imagine trying to spell out the logic in English so a human could understand it, much less a computer.

Imagine, however if the language had already defined most of your terms. Imagine a language built specifically for authoring point of sale applications. It already knows a set number of terms. It has its own editor with pre-defined flowcharting widgets, and it generates code that would be compatible with your existing Java system.

Of course creating a new language just for my problem domain is currently out of the question. In the time it would take, to write the language, I could have created the system that I wanted it to generate. That�s where MPS comes in� a framework for writing domain specific languages. It seems like a lot to ask for. I wish them luck.

For more info, check out this interview at Code Generation Network.

Subclassing Swing Components

Have you ever looked under the hood of Swing? Most Swing programmers understand MVC, but I haven't talked to many who really understand how little logic really goes in a Swing component.

If you look inside JButton or AbstractButton, you find that Swing components are essentially Value Objects. The complexity of drawing a button is handled by the UI. Any model information is handled by a model (yes even for a button), and all that's left is getMargin() and setMargin().

Why is it then, that whenever someone wants to add functionality to a component, they immediately subclass it? I know the simple solution is often the best, but even on medium sized projects, this lack of flexibility quickly becomes a problem.

The largest problem with sub classing components: extendibility. Imagine creating two subclasses of JButton. Button A has feature 1. Button B has feature 2 and 3. Now you want a third button with features 1 and 3, but not feature 2.

Extreme programming dictates that we not deal with code sharing issues until the problem actually arises. This (to me) is one of the weaknesses of XP. By ignoring the problem, we just make it more difficult to deal with later. The XP solution of "the simplest thing that works" is (imho) a crutch for those who get locked in analysis paralysis. It's just the other extreme. And as they say: "all extremists should be shot".

Another major problem I find when people sublcass components is their lack of understanding of UI Delegates. Most Swing programmers know that drawing tasks are the responsibility of the UI, but few understand that most internal listeners (including many of those which communicate with the model) are the responsibility of the UI Delegate.

Many of the features added to component subclasses should be controlled by the UI. Many times the programmer will break compatibility with other look and feels because of this short-sightedness.

I believe these mistakes are often made because people are afraid of UI Delegates because of their complexity. Many behavior changes can be implemented by using a visitor pattern, or a compound UI Delegate. By applying changes to components without subclassing them, the look and feel is not broken and the logic can be separated from the component and applied based on any arbitrary set of rules.

For those who want to better understand UI delegates and the inner workings of Swing components, try reading "Hardcore JFC" by Mitch Goldstein (an unfortunate title, but a very good book).

The Rare Case for CSS Positioning

I�ve been working with HTML off and on since 1995. Most of my experience is weighted towards those early years of the web. Up until recently, I�ve believed that these experiences were holding me back from really appreciating the advancements that everyone else seems so impressed with. Specifically, I never really understood the community�s infatuation with CSS positioning, and after careful thought I�ve decided that the problem isn�t mine. I�m going to try to explain why I think CSS positioning is a tool that should be used sparingly and in very specific situations.

Note: I have no problem with using CSS to reuse style information. I also don�t mind using CSS positioning for very specific circumstances. I am only trying to argue that there is no need to blindly replace all table tags with CSS positioning.

First of all, I�d like to dispel the myth that CSS allows presentation information to be decoupled from the content. CSS doesn�t control a web site�s presentation logic. It simply augments the presentation information that already exists in the HTML. It was meant as a way to allow presentation logic to be easily replaceable. From a single place, you can change all your headings to 14pt red fonts. For this, CSS works great. It saves developer time and provides for some great demos for management.

Even if the CSS could contain all the presentation logic, and the HTML contained only content, the two would still not be cleanly decoupled. The HTML must know what styles are applied to it (so it can have the correct tags on the correct elements), and the CSS must have a pretty good idea of what the html looks like. It seems to me, that if HTML and CSS were truly decoupled, then the CSS would have absolute control over the presentation, and would regulate what content was displayed, and where. To remove the last pieces of presentation logic from the content, the presentation layer (CSS) would need to have complete control (and therefore be the starting point for the creation of the page). This would limit the content�s knowledge of the presentation layer, while the presentation layer would make assumptions about the content (omitting sections of the page when those assumptions proved incorrect). This is the same concept used in Word Templates, Page Layout software (Quark, PageMaker) and by Jakarta Tiles.

Some would say that CSS and HTML are decoupled, pointing out sites like the CSS Zen Garden. If you can replace the CSS to get a completely different layout, then CSS and HTML must be decoupled. To me, that�s like saying a human heart is a standard interchangeable part� after all, if I find one of the right size and blood type, a group of skilled surgeons can replace the human heart in only 12 hours.

CSS and HTML need to know immanent details about each other. This is fine, because CSS was only designed to extend HTML as a quick way to centralize presentation properties that may change often. CSS is simply used to create themes.

At some point, someone decided that all presentation logic should be expressed as CSS (rather than as a mix of CSS and HTML). Replacing HTML with CSS makes sense for presentation logic that may be replaced across a site at a later date, but what about presentation logic that won�t be repeated elsewhere in the web site? The consensus seems to dictate replacing all presentation based HTML tags with CSS alternatives (regardless of reuse) for the sake of consistency. This sounds like a great idea for presentation based tags such as the font tag. Both pieces of code are relatively simple, and provide the same benefits:

Error Message

and

Error Message

The CSS based code has the added benefit of being consistent with CSS syntax used in external style sheets (where the benefits of CSS really shine). The font tag just doesn�t have any advantages here.

The same logic should hold true for CSS positioning, right? That has been the rational so far. People have seen the trend: move all presentation logic from the HTML to the CSS. But at what benefit? What cost?

Moving simple visual properties to external style sheets has noticeable benefits. All pages can share the same properties. Changes made in a single spot can be reflected immediately through the entire site.

What about positioning data? The same rule still holds. Positioning information externalized and referenced throughout the site could be changed in a single place. But that doesn�t provide any amazing benefit to a dynamically generated site. Server generated pages can already be created from centralized templates. In most cases, that template is created visually and aren�t as tightly coupled as a CSS solution (tiles, for example is view driven � the solution I suggested above in the decoupling section).

What about features? While it�s true CSS positioning has a good deal of advanced features, most go unused. Most websites can still be created using simple nested tables. HTML Tables have an advantage over CSS in that they are much simpler to use.

This leads me to believe that CSS positioning is only advantageous in two situations:

• The site is static, and a consistent layout (which may change) is required throughout the site, or
• The layout is complicated enough that it can�t be done without CSS positioning.

Because traditional layout using HTML Tables is so much simpler than CSS positioning, the two cannot be considered equivalent. Each has their place. For that reason, I don�t think one can be safely eliminated for the sake of consistency (as can be done with the font tag).

The rush to replace table layout with CSS positioning is based on:

1. The incorrect assumption that CSS was designed to decouple presentation logic from content
2. The �dirty� feeling people seem to get when they create layout using html tags originally intended for tabular data presentation.

Had the �table� tag been called �layout�, there might not be an issue.

In the short term, I don�t see any reason to use CSS positioning unless the site is static and has a consistent layout or the layout is too complex for embedded tables. In the long term, I believe CSS positioning will only be a viable solution when it has been extended to be at least as simple as HTML Table (perhaps by adding layout managers to the existing CSS spec).

UPDATE: I found an interesting article supporting my opinion.

JDesktop Integration Components

A friend pointed me to the JDesktop Integration Components (JDIC) project, which aims to provide Java hooks for accessing native OS features. It seems to follow the same philosophies as BrowserLauncher and SWT: essentially writing platform specific code for as many platforms as they can think of. The underlying code, isn�t necessarily elegant, but it�s a job that needs to be done.

"there is no way to emulate integration"

It seems to me that Sun should have taken this stance a long time ago. Everyone (including those within Sun) seems to understand that AWT died because of its philosophy of supporting only the least common denominator of components. Although it�s not often talked about, Swing has a similar problem. It emulates the look of a native application (with arguably decent success), but there is no way to emulate integration. A Swing app has no clean way to open the user�s email client, or minimize to the system tray. Even if Sun had gotten the native look and feels down perfectly and removed any and all performance issues, a Java GUI application would still fall short of its native counterparts. Java apps would always be limited to a subset of a native application�s possible features.

Not to pick on Swing too much, SWT has the same issue. Using native components doesn�t magically allow OS integration. While SWT applications look more native and run quicker than their Swing counterparts, they still run in a vacuum, cut off from the native environment.

I�m glad to see someone is tackling the problem. I hope they get the support of the community; and I especially hope the community learns the importance of this type of platform integration to the future of Java on the desktop.

Waiting for the Future of the Rich UI

Joel Spolsky was praising Firefox today (and with good reason), but towards the end of his entry he made a comment I�ve seen repeatedly over the last few months: �...there's a glimmer of hope that one day DHTML will actually improve to the point where web-based applications are just as good as Windows-based applications �.

I don�t believe DHTML, javascript or any of our current web technologies will ever evolve to the point that they can compete with native client applications. Not that you can�t do some really cool things in DHTML, but in order to be truly competitive with native client applications, the resulting product would need to be maintainable by future programmers and flexible enough to grow.

Even after browser standardization and the creation of feature rich open standards (both of which are still a dream), the code will be made up of many different syntaxes glued together as an afterthought. A simple rich web application might be made up of XHTML with CSS and embedded with SVG and ECMA-script. Some of the code may be dynamically generated on the server-side. Some validation may be repeated on the client side. The server side code could contain any number of technologies (Java, J2EE, Struts, XSLT, Tiles, JSP, perl, python, etc.).

While its interesting from an academic perspective that a simple markup language was able to be extended to support such a wide variety of features, it doesn�t provide a very practical solution for our problem. For almost 20 years, we�ve known how to create a rich interface between the user and the computer. The only thing we were missing was a safe and easy way to distribute these applications. Rather than solve the original problem, we found an existing technology that didn�t have deployment issues (html) and tried to retrofit it to act like a rich client.

I believe a better solution is to take a rich client technology and find a better way to distribute it. This has been tried before:

• Java Applets � failed because of lack of support by Microsoft, and because AWT wasn�t useful
• ActiveX � failed because it was insecure and only supported by Microsoft
• Java Webstart � failed because it only runs Java apps, and Java never took off on the desktop
• Avalon � not released yet, but this will also only be supported by Microsoft

(For those of you who are easily excited, the term failed is a relative term. I simply mean that these technologies didn�t live up to their potential)

As I�ve written earlier, Avalon looks to be an exciting technology. But in the end, it�s a Microsoft technology. It�s bound to be an extremely successful tool within the Microsoft camp, but never touched outside it.

What I really look forward to is the rest of the community looking up from their servlets to see the bigger picture. When that happens I hope to see several independent solutions from the open source community (I�m guessing the first would be from the Mono team). Until then, back to my web app.

Mono and the Open Source Boom

In the next few years mono is going to cause a huge boom in open source development. I believe there are tens of thousands of highly skilled programmers eager to participate in the open source movement, but have been reluctant because of inadequate tools. The potential for success of the open source community has been hurt by the high barriers to entry. Although open source projects come in all shapes and sizes, a vast majority of them require knowledge of the C programming language and a dedication to learn a relatively obscure set of libraries (GTK, QT, Apache�s plugin API).

Having adopted Java�s concept of a single inclusive API set, and it�s directing attitude (memory management, exceptions, single inheritance, etc), .net gives programmers a better tool. Having ported that tool to a variety of platforms without sacrificing access to native features mono has improved upon both java and .net. The result is a very usable software development platform that has the cross platform capabilities desired by open source developers and the ease of use desired by those programmers once left out of the community.

New developers no longer need to learn a new language to develop linux and mac applications. They can continue programming in VB or C#. No longer do they need to learn a huge set of complex APIs to create linux and mac applications (just the GTK or Cocoa bindings, if they choose to use the native features). No longer do they need to resolve piles of endless dependencies while compiling the source code before they write their first line of code (.net assemblies are cross platform at the binary level, and can be distributed in this form without performance issues). The barriers are coming down.

Microsoft�s Ace

Many in the open source community seem to be firmly against the adoption of mono. Some even consider the creators to be traders to the community. They seem to think that mono is evil because of .nets origins at Microsoft. Others think that supporting mono will give more leverage to Microsoft (presuming that Microsoft controls this standard any more than they control other open standards such as ECMA-script, HTML or SOAP). In short, people seem to think that mono might be too good to be true. There must be a catch.

"Avalon will ensure that the .net UI bindings for Windows are better than the .net UI APIs for any other operating system"

There are two catches (Neither should prevent the adoption of mono). The first catch: mono will encourage developers of all backgrounds to learn Microsoft-compatible technologies (note, I didn�t say Microsoft-controlled technologies). A large number of C# and VB programmers benefits Microsoft even if they never buy a Microsoft product. Microsoft�s customers will have a large pool of skilled workers to pull from. Another catch: although they released a very large portion of .net to open standards (enough to keep mono safe from Microsoft control), they kept the best for themselves: Avalon.

Avalon is Microsoft�s ace in the hole. The rest of .net is just a re-implementation of Java with a focus change toward multiple languages and native windows support. While Avalon is also based on existing technology, it�s never been put together in quite the same way. Avalon will ensure that the .net UI bindings for Windows are better than the .net UI APIs for any other operating system (and probably will be better for years to come). Miguel de Icaza hinted that an open source competitive library may be built in the future, but it�s not even on a white board yet.

Why is Avalon so nice?

Some of its features include XAML, which separates layout from UI code by embedding the layout in an XML file. This technique is similar to the .frm files generated by Visual Basic in 1993 (and somehow forgotten by the creators of Swing and SWT). Cocoa uses this practice (.nib files) as well as IntelliJ IDEA�s Swing layout extensions and JGoodies tools. It works well to separate design-time component properties and component layout from event handling and business logic.

Avalon and XAML also model themselves after SVG. In addition to primitive vector based components like those in SVG, XAML also provides vector-based components. In a few lines of XML, you can create a combobox, position it on the screen and apply graphic transforms on it to rotate or skew it. Vector based interfaces are the next logical step. Apple took an intermediate step by creating Quartz Extreme, which renders raster images on a vector. This allows �vector looking� animations without the performance hit of using real vectors. Microsoft is counting on Moore's law to provide the processing power needed by Avalon's vector based interface (although longhorn is said to have a 'light' mode which uses XP-style components when required).

"Asking the open source community to beat Microsoft to the next big technology at this point is like asking Iraq to make a better car than the Germans"

Another big (and for some, scary) addition to Longhorn will be Avalon�s deployment model. Avalon based programs will deploy in several ways. An Avalon program can work like an applet and run directly from a web page. If it needs greater set of permissions, it can load like a Java WebStart program. And of course, an Avalon program can still be installed as a normal application. These technologies didn�t work for Sun for reasons that don�t apply to Microsoft: Sun needed (and didn�t get) cooperation from leading OS and browser vendors to provide a good user experience; and WebStart and Applets are used to display applications written in AWT and Swing (which all by themselves negate any chance of a good user experience).

Avalon will be able to apply its distribution model to all PC running Longhorn or newer operating systems. The resulting application will have access to the same Avalon UI that Longhorn uses. These will be real native Windows applications, only limited by Java-esque sandbox restrictions (which can be bypassed by certificate or by directly installing the application on the PC).

Even though there are no dramatic technology advances in Avalon, it is still a huge win for Microsoft. It allows them to open up .net without loosing their competitive advantage. It will encourage industry leaders to write software for Windows. It will encourage users to continue buying Windows PCs (and maybe feel a little less jealous of Mac users). And lastly (and this is my largest concern), it puts Microsoft�s user experience way out in front of the open source community.

Nothing New in Avalon

Interestingly enough, I was able to describe Avalon by comparing its components to existing software frameworks, yet none of those frameworks lives up to the expectation of Avalon.

SVG should allow many of the features in XAML, but it doesn�t support components. Even if it was extendable, and the community agreed on a set of standard components, there are very few open source SVG implementations that live up to the spec (Batik is the only I know of that supports animation). XUL should be a good cross-platform alternative for creating thick clients, but it�s based on Javascript. While Javascript is very powerful and widely excepted as a scripting language, mainstream applications written in Javascript will always be the exception and never the rule.

There are even fewer alternatives to Avalon�s deployment model. Because of Microsoft�s support, Avalon�s deployment will be much more successful than their distant cousins (Java Applets and Java WebStart). I don�t expect to see an open source alternative gain much more support than Sun did with WebStart (what advantage would an open source project have have over Sun in this arena?). As far as creating an compatable open source port of Avalon�s deployment model, I seriously doubt Microsoft would allow that. They had good cause to open up .net, but no reason at all to open up their new deployment model (although I would love to be surprised).

Catching Up

Many criticize mono saying the open source community should be innovating more and copying less. I believe we are too far behind the curve to be considering innovation. Asking the open source community to beat Microsoft to the next big technology at this point is like asking Iraq to make a better car than the Germans. First we need to catch up, and then we can work on surpassing. Mono is a good first step in catching up. The next step may have to be Avalon. Currently this looks like a huge uphill battle. I don�t expect to see a practical open source competitor to Avalon within the next 7 years, although I look forward to helping the effort where I can. Until then, Mono is a good step forward for the entire software community.

Unique like Everyone Else

Everywhere I go I hear the same phrase, over and over: �we do things different than other companies because our product is different than anything else out there�. People treat each situation as if no other company in the world has ever had to deal with the situation before. Our [product|business|company|whatever] is so different that we need our own procedures for [version control|build process|conventions|source organization|whatever]. I wonder sometimes if this is some sort of disconnect from the rest of the world (most companies in my area have a lot of 10-20 year �lifers� who haven�t worked anywhere else and have never been exposed to the internal workings of other companies) or, even worse, some sort of superior thinking (maybe they really do believe they are just that unique).

"Always Remember That You Are Unique. Just Like Everybody Else."

Either way, I regularly find myself in a conversation about stupid, no-brainer decisions that I thought the industry made for us years ago. Most languages for example now come with their own coding conventions (Java, C#, VB.net). Why would you deviate from them? You don�t like where the brackets go? Get used to it! It takes a lot less effort to adapt to the convention than to try to enforce a new one (especially when you need to deal with third party source code). Is your build process a pain to use? Nothing a few more batch files can�t fix! Why not find out what the rest of the world is doing?

Why? Because the people in charge are the ones who have been with the company the longest. They are rewarded for their loyalty (which make sense in a Ross-Perot-pie-chart kind of way). In return, technical groups are run by those who are the least connected to the rest of the world. The most connected people in the company have the least seniority and the least say in procedure changes.

What can you do? I�ve tried changing the world. Damn thing won�t move. Currently I�m trying the �Thank you sir � may I have another� approach. My sanity has improved dramatically. I can�t be sure it will work in the long run. As far as I know that�s how all these lifers got here. I may just be adding to the problem.

UPDATE:

Weiqi Gao writes:
�It won't be long before you will become one of the old timers, managing a bunch young people who think they know the solution to every problem. And the cycle repeats itself. :)�

Weiqi can smell my fear. A year ago, the idea of completing this cycle really bothered me, but I'm beginning to think this stereotype is beatable.

This reminds me of a conversation I had with my wife over the weekend. We were talking about the difference between knowledge and wisdom. I decided that knowledge can be gained in any number of ways, but wisdom had to be obtained by experience (usually because when verbalized, real wisdom can't be distinguished from a silly clich� through outside analysis alone).

There was a time when knowledge and wisdom went hand and hand. Because lives weren't front loaded with education, people learned equally throughout their lives. The older they were the more knowledge they had. Wisdom of course always has worked this way, and always will. A couple hundred years ago, when formal education replaced apprenticeship, things changed. Now people gain most of their factual knowledge at a young age and do their best to keep that knowledge current as they get older (which of course is much more difficult in our industry than in others). They of course still gain wisdom as they gain experience.

This leads me back to my original post. In our industry we have a good deal of young knowledgeable people with, perhaps little real wisdom; and a good deal of wise people who could use a bit more knowledge. Not understanding the difference between the two, our society falls back on tradition and delegates power to the experienced.

The problem isn't in how the responsibility is being delegated (although that is what I inferred in my original post). The real problem is with the employees themselves. The young should recognize the value of wisdom (which is a bit of a paradox, as it requires a bit of wisdom to appreciate it in others). The experienced should realize that they cannot rely only on wisdom. The world is moving too fast to rely completely on past experience.

This seems a much more optimistic view. If we challenge our selves to gain good experiences (and pay attention to the results), we will over time gain wisdom. If we continue to learn and not become complacent, we can have both knowledge and wisdom, thereby breaking the cycle.

Two Finger Salute

General purpose computers fail. They fail at such an astounding rate, that it has become part of the user experience. Everyone knows how to get windows out of an inconsistent state. The first solution in tech support is �restart the computer�. Even my mom knows about Ctrl-Alt-Delete. As computers venture further out into the world of appliances, we find ourselves dealing with these failures everywhere. It�s somehow acceptable to �reset� your answering machine, your Tivo or even your microwave. The reason I mention this? My iPod just locked up on me. I had to reset it by holding down �play� and �menu� for a few seconds. Just when you start to regard these little computers as appliances, they remind you of their roots. It make me wonder� as computing becomes ubiquitous, will we make computers more stable, or will we simply learn to live in a fragile world?

Review of the Gateway Java Symposium '04

I spent this past weekend at the Gateway Java Symposium. This was my second time at the conference and overall I had a good time. After the show last year, I posted a review. This year I thought I�d do the same.

Since my review of the show last year, I�ve kept up with each of the presenters, reading their blogs regularly as well as a few of their books. Over the course of the year my opinion of some of these authors changed. Two of the speakers I looked forward to seeing again this year (James Davidson, and Ted Neward) didn�t speak at the conference this year.

Last year I spent the bulk of my review talking about the quality of the speakers (which was pretty high). This year I don�t have anything especially interesting to say about the speakers (they were all pretty good). Instead I would rather talk about the content a bit.

Last year there were a few topics that popped up in almost every discussion (dynamic languages were discussed a lot). Two major topics that seemed to pop up at every turn this year were AOP and the Spring framework. I had heard at least three presentations on AOP before the Symposium (we have two local JUGs here, so there is often overlap), so the buzz over AOP wasn�t new to me. I don�t expect to get to use AOP in a work environment for quite some time, so I�m trying not to get too excited about it.

Spring, however was completely new to me. It was presented as a lightweight replacement for J2EE. There wasn�t enough time to get a good handle on the Spring Framework�s implementation, but the concept is great. Although it wasn�t brought up at the show, the Spring Framework reminded me a bit of Microsoft�s solution with .Net (only the Spring is a bit more centralized still). As you need each new enterprise feature, you plug that feature in. There isn�t a single monolithic application server providing all services from a single place (you aren�t required to configure services you won�t ever use). Since I�m not working on a J2EE-scale project right now, I�m not in a huge rush to learn about alternatives (it would have been useful two years ago, however). I�ll probably just wait until June and read more about it from Bruce Tate�s new book.

There were some interesting sessions on testing web applications, using JSF (which IMHO, seems to barely leapfrog Struts, not even coming close to WebForms), CVS, Swing, SWT (the session was waaay too basic), coding practices (decoupling, TDD, etc), and at least 5 sessions just about persistence.

My biggest complaint about the session topics (and I may very well be alone here), is the lack of �fun� sessions. Last year my favorite sessions were on �Using Java on the Mac�, Objective-C, Ruby and Java vs. .Net. Quite a few of the speakers at the show took the time to stress diversity in learning, but for some reason the show�s topics were anything but diverse. I might be the odd man out here (I pay my own way to the show, and attend more for fun, than professional development), but I would have really liked a break from all the persistence sessions. A session on the Java Speech API, Batik, or JFreeChart between �Persistance with Hibernate� and �Hibernate vs. JDO� would have been nice. And although it would have been off topic, a session on Mozilla development or Mono would have been even better.

Overall I was happy with the Symposium. It was worth the price of admission (and worth my time). I do think it was a small step down from last year, and I�m on the fence about attending next year, but overall I recommend the experience. If you haven�t been to the �No Fluff, Just Stuff� show, then you really should give it a try.

Type Safety and IDEs

The speaker at a local Java User Group meeting, mentioned his dislike for strong type safety, giving the usual reasons: high overhead in type safe languages, quick turn around with loosely typed languages, and the relatively small amount of errors caught by compile time checking. In a seemingly unrelated discussion, he mentioned his preference of code editors: Emacs. It occurred to me that I�ve never met someone who likes strongly typed languages AND uses a modern IDE. I believe the two preferences are closely related.

Those who use a text editor to write their code, have to compile their code AFTER they write it; only getting the benefit of compile time checking in small iterative batches. Even those who use inferior IDEs have to save their work and wait for the source to be parsed to see any compile time errors. Those using modern IDEs (such as IntelliJ IDEA) get to see their compile time errors as they type (it even offers to fix them for you with a keystroke).

Even with that aside, I believe compile time checking is only a minor benefit of strong typing. The greatest benefit is the added level of self-documentation provided by type checking. An object has only so many methods, and depending on its reference only a portion of those may be visible. With a good IDE, you have complete access to all the possible method calls for an object. You can quickly scan the list for method names that make sense, and even consult the method�s documentation without leaving your code. With only basic knowledge of an API, a programmer can immediately become productive.

I don�t believe anyone who uses Emacs could fully appreciate how much more productive these hints can make the average programmer. If you use VI to edit Java code, then you have to use an html browser to read the documentation, and type everything on your own. Since type safe languages have more ritual, the VI user gets all the downside of the type safe language and none of the advantage. Of course, from that point of view, switching to a loosely typed language is going to feel MUCH more productive.

I don�t have anything against loosely typed languages, or using VI as an editor. I happen to be learning Ruby and am enjoying it a lot (although I miss my IDE). I just don�t like hearing otherwise respectable people preaching about the huge productivity gap between strongly and loosely typed languages. I think it�s all in the tool.

UPDATE:

This last post was a bit sloppy, and a few people called me on it. I�d like to clarify some of it and take a couple things back.

First of all, I used the phrases �strongly typed� and �staticly typed� interchangeably. This isn�t correct. You can read more about this here.

I would also like to clarify my point a bit. I don�t believe that any type of inline code generation (live templates in Idea) are a good substitute for simply ridding the language of the need for such code. Less is more. When I talk about programmers being more proficient with a strongly typed language, I was referring to �average� programmers. The learning curve with such languages is not as steep because the languages are somewhat self-documenting. Sure, once a programmer is proficient in all the APIs they use on a daily basis, productivity can be measured in keystrokes. But beginner and intermediate programmers spend much more time looking up API information than typing. And in my experience, intermediate programmers outnumber expert programmers by a very large margine.

Either way, after reading this entry in Martin Fowler�s blog, I�ve come to realize this is just a difference in point of view. I�ve spent the last few years of my life working with complete newbies to Java/OOP. Those experiences have pushed me whole-heartedly into what Martin Folwer refers to as the Directing Attitude of software design. I can understand where these features would be very helpful to someone who can handle them, but I�m just not optimistic that enough of these programmers exist. I just know too many people who rely on a strict interface to push them in the right direction.

SWT design question

I just started getting into SWT over the last few days. My exploration took me into the source code where I ran into a confusing pattern. Everyone knows that SWT uses native system calls to render components (when native components are available on the current system). The SWT application asks the SWT libraries for a button and SWT then delegates the work to the operating system.

Here�s the strange part: I figured that a factory would have generated either the button itself, or an internal helper class within the button. The button or the delegate would just need to implement an interface that defines the behavior of a button. That turns out not to be the case. The source code for the Button class has �Windows only� code in it. If you download the source for the Macintosh version of SWT, the same class exists, in the same package, but contains different code!

This is a very high profile project with a lot of good developers working on it, so I know this isn�t just an oversight. I can only assume that it�s a convention handed down from another project or an organization tactic that I�m just not getting. I looked around and haven�t found an explanation. If anyone knows why the eclipse team choose this design, I would love to hear about it.

SVG Promotes Reuse

I've been using SVG quite a bit lately, and after a little adjustment, I've found it to be very fun to work with. It may never replace flash, but it doesn't really need to replace flash to be successful. It will eventually sneak into places we would never expect to find it.

Over the last year, I've seen a number of discussions about adding SVG support to operating systems. Microsoft is apparently planning to use their variation of SVG to draw windows components. KDE also has some support for SVG icons. Many developers on Slashdot and the KDE lists seem to believe that there would be no advantage other than scaling pictures. I don�t think this is the case.

SVG allows for colors, line properties and many other formatting decisions to be externalized in the form of CSS. SVG files themselves can reference each other and reuse images from other SVG files. I can see this having a huge impact on the open source community (which has an abundance of hackers and a huge shortage of artistic talent).

Today, artists create themes for KDE, Mozilla, winamp and others as rasterized images. Although the work is released to the open source community, for the most part someone can only alter them if they have equal talent as the original artist. Depending on the modification, they may require the original Gimp or Photoshop files. Even with the originals, some modifications can�t be made without starting from scratch on an image.

Had the originals been SVG and CSS, just about anyone who can edit XML could change an image, alter it�s colors, add or remove detail or recompose elements of the work with very little artistic ability or even without much knowledge of SVG.

Entire themes for KDE or Gnome might reference a single CSS file. A savvy user would not only be able to change the colors of buttons and scrollbars, but of all the icons that came with the theme.

I�m not pretending that using SVG somehow doesn't require creativity or skill � it requires every bit the creative talent as any medium. What I�m suggesting is that SVG may bring a level of reuse and sharing to the Open Source community that we normally don�t associate with static images. I think once supported, it will allow for Open Sourced images to become much more useful.

Sun javadoc comments entertain again

I was just reading the javadoc for Timestamp (which is a subclass of date). It has a disclaimer that's kind of entertaining:

"The Timestamp.equals(Object) method never returns true when passed a value of type java.util.Date because the nanos component of a date is unknown. As a result, the Timestamp.equals(Object) method is not symmetric with respect to the java.util.Date.equals(Object) method. Also, the hashcode method uses the underlying java.util.Data implementation and therefore does not include nanos in its computation. Due to the differences between the Timestamp class and the java.util.Date class mentioned above, it is recommended that code not view Timestamp values generically as an instance of java.util.Date. The inheritance relationship between Timestamp and java.util.Date really denotes implementation inheritance, and not type inheritance."

Translation:

"We really shouldn't have inherited from date, but we did anyway because favoring inheritance over composition has always worked for us in the past (isn't Swing swell, after all). We decided this was a good thing because - hey - we already wrote the code, and it's working. Besides, it's not really a problem if we document it, right?"

Concepts!

Programmers I�ve known spend too much time learning �how� or �what� and not enough time learning why.

All programmers learn the three fundamental principles of object-oriented programming: inheritance, polymorphism and encapsulation. They learn rules about these concepts, such as �when possible, favor composition over inheritance�, the DRY principle: �don�t repeat yourself�, and �be sure to decouple view logic from business logic�. Programmers (being the intelligent math-educated people they are), memorize the rules and apply them whenever possible.

Here�s the problem. Most of these rules were not meant as absolutes. These are not like the rules of physics or geometry. These are more like the rules of grammar or art: �complementary colors provide contrast�; �photographers should use the rule of thirds when composing a shot� or �don�t wear white after labor day�.

You don�t become a better craftsman by knowing more rules than everyone else. You become better at your craft by understanding the rules, why they exist and what contexts they can be applied to.

A popular buzzword I�ve heard being abused lately is �decoupling�. Unlike with marketing buzzwords, the problem doesn�t seem to rest in a misunderstanding of the original definition. Programmers just don�t stop to consider why they are �decoupling� their code. It is true that in many cases programmers tend to write highly coupled code. Many programmers don�t appreciate encapsulation nearly as much as they should (at the class level or subsystem level). This has led to some great books such as �The Pragmatic Programmer� and �Effective Java� that re-teach the basic concepts of OOP. The authors repeat the rules we read every day and explain why they are important (again).

The average programmer will read an entire chapter on decoupling code and walk away with:
Decoupling = good
Coupling = bad
We see the results of this oversimplification every day: seven levels of indirection for a single Session Bean call? A property file that tells me how to find my property files directory? A programming language written in xml?

Lets get back to the concepts. Decoupling exists to improve encapsulation. Encapsulation exists to improve maintainability. Many times externalizing logic will improve maintainability. Many times you�re just making a big mess! Decoupling code for any reason other than maintainability is a waste of time.

I love The Pragmatic Programmer series by Hunt and Thomas and many other books that teach everyday concepts that everyone should understand. I wish some of these books would not only explain the benefits of their philosophies, but how to tell if you�re taking them too far. More importantly, however, I wish programmers would read these books, absorbing the concepts rather than just the rules.

EasyMock

EasyMock is a library to help create mock objects that aid in your unit testing. The framework uses dynamic proxies to implement a given interface and return the results you expect. It will also throw exceptions if an unexpected method is called (aiding in the creation of your mock objects) and count the number of times a method is called (which allows your unit test to test efficiency in a more measurable way than the usually pointless System.currentTimeMillis() method of testing).

The best advantage of using EasyMock, in my opinion, is to specify the results of your mock objects directly in your unit test. A simple test may call two or three methods on a class. EasyMock requires two lines to create the mock object:

MockControl control = MockControl.createControl(MyInterface.class);
MyInterface myMockObj = MockControl.getMock();

Each method you want to call needs to have its results defined:

myMockObj.getParm();
control.setReturnValue(�ABC�);

As you can see, setting up a simple method call requires only two lines of code. This allows you to create custom mock objects for different situations you may want to test without littering your source tree with mock objects (or filling your mock objects with logic that, itself, needs to be tested).

The limitation of EasyMock, of course is the dependency on interfaces. Although we should always be coding to interfaces, it rarely seems to work that way. Luckily, most need for Mock Objects will be limited to those classes that do (or should) have well defined interfaces (database access, file access, container classes such as doms, or classes with complicated logic).

PDF: Unfit for Human Consumption

There is an interesting article on Jakob Nielsen's Alertbox about just how unusable PDFs are on the web. I have never liked PDFs for many of the reasons Nielsen sites on the article.

Because Nielsen provides advice to creators of content, rather than those who invented the tools in the first place, he doesn't provide any useful solutions.. just workarounds. I don't expect to ever see a layout solution that works well for e-books, web browsing AND printing, but hopefully Adobe (or a competitor) is paying attention, and will make it much easier to design a document for multiple formats.

Yahoo2iPod

As I�ve mentioned earlier, this week I wrote a simple program to convert data from my Yahoo account so it can be accessible on my new iPod. It isn�t much, but it�s something I needed for myself. I decided to apply the ol' spit-and-polish for the sake of learning a bit about my Mac. I made a Swing GUI (screenshot) for the app using the Aqua look and feel and packaged it in an Mac application bundle. I had some issues that I�ll probably write about at a later date, but for now I�m just going to post the program itself.

Here is a mac deployment, an executable jar and source code. It should run on a PC as well, but hasn't been tested yet.

I�m new to the world of Mac development, so if someone has a suggestion for a site that may be interested in knowing about this tool, feel free to send me a message.

I'd also like to thank Dave and Florian for thier feedback on my last post. Your ideas worked great!

iPod help

I just bought my first mac a couple weeks ago, and an iPod last weekend. So far I love them both. One of the first things I did with my iPod is write a quick sync program to read information from my yahoo account (addresses, calendar info, etc) and format them for my ipod. I ran into one problem, however.. I can't figure out a generic way to reference my ipod. The mount point is named after the name of the ipod.

If I can't find anything, I'm going to prompt the user on first use ("What is your iPod's name?"). What I would really like is for the program to be smart enough to detect the attached ipod on it's own. I don't mind if the solution is mac-specific. If anyone has any ideas, or can point me in a good direction, please post a comment below, or write me.

The Speed of Eclipse

I just took a new contract a couple weeks ago that has forced me to deal with WSAD. Overall, I consider it a good thing. I had thought about learning it or Eclipse for a while (I�ve been using Idea exclusively for a few years now). I was looking forward to seeing what all the hype was about.

There have been a few good things about it. I love anything open source. I like being able to dig into the database without leaving my IDE. I like the Swing designer (for the most part). And then there�s the speed�

All I�ve been hearing from people about Eclipse for the past could years, is how fast SWT is. Well, I hate to break it to you all, but an API can�t make an application fast! If you still have all the typical IDE clutter; if you still have those frustrating modes (with no good indicators); if you have to go through a six step wizard to rename a variable; then it doesn�t really matter how fast you refresh the screen. Usability is not about speed, and Eclipse is not about usability.

Being an open source project (Eclipse�s greatest strength), handicaps it in that it will never be truly useable (being partly controlled by IBM, by the way is a deterrence to usability, not an advantage). Just as Linux will never be ready for the desktop, Eclipse may never be as easy to use as its competition (Idea).

I�ve been working on my optimism, however, so I�ll end this with a positive note: If you�re coming from JBuilder, NetBeans, Caf�, or Together, then you�re probably pretty happy with Eclipse.

Review of the Gateway Java Symposium

I just spent 3 days at a local Java show thrown by No Fluff, Just Stuff Java Symposiums. They sent a handful of authors and Java evangelists to St. Louis for three days to give a total of 50+ lectures in 5 hotel show rooms. It was possible for an attendee to see 11 of these lectures. Since this show will be appearing at a number of other cities, I thought I would share my experiences to help others who might be considering this symposium.

First of all, if you want more information about the classes or bios of the lecturers, then you may want to check out the symposium web site: nofluffjuststuff.com.

Overall I really enjoyed the symposium. Being from St. Louis, I don�t get to talk to many people who really know their stuff, so this was pretty refreshing to me. I also liked the small class sizes (the smallest was 8 people, the largest was around 35).

Despite the title of the Symposium, it did have quite a bit of fluff topics (if you don�t know Ant and XML, your probably not really a Java programmer). They seemed to consolidate the lighter weight classes at the beginning of the show, while the last day of the show was crammed full of interesting lectures with overlapping time slots. I don�t know if they were trying to gauge the audience, or get the beginner topics out of the way, but I didn�t think it was the best decision. If they had spread the beginner topics across the entire weekend, the beginners would have had something to do the entire show. It would have also given the rest of us a chance to see more of the good lectures that were doubled up on the last day.

Scheduling is a minor complaint, however. Many of the speakers were very good. Here is a quick breakdown of who to see, and who to miss:

James Davidson � After I went to his first presentation, I re-arranged my schedule to hear him speak again. His �Effective OO� class was essentially a re-hash of Josh Bloch�s �Effective Java�, but it was interesting to hear from a new perspective (again, this was one of the earlier classes, so the alternatives weren�t that great). His second lecture was about Objective-C. I expected a crummy old cryptic language, but was surprised by a language with all the RAD capabilities of Visual Basic wrapped in a package far more flexible than Java (due to dynamic typing). The editor included with Mac OSX was great. Being a complete Java nut, I was very surprised that my two favorite lectures were about Objective-C and Ruby.

Jason Hunter � I went to a lecture given by Jason Hunter on Java Assertions and JDK 1.4 logging because it would be the only chance for me to hear him speak. I probably should have just moved my schedule around. The topic was pretty basic, and there wasn�t much for him to say, other than explaining the API (both of which are pretty self explanatory). I did get to hear more from him at other lectures (he was part of the audience). He has some interesting points of view, but the topics he was speaking on weren�t especially thought provoking.

Dave Thomas � The keynote on Friday night was a presentation by Dave Thomas about many of the concepts in his book �The Pragmatic Programmer�. I read the first few chapters before going to the symposium and so far I love it. The lecture was equally as good. After that lecture, I changed my schedule for the next day to see two of his lectures: �Decoupling Patterns� and �Ruby for Java Programmers�. I have his Ruby book, but never made it past the first few chapters (it didn�t seem practical at the time to learn a language I wouldn�t be able to apply for years). The lecture, however, really got me interested in it again. He really preached the advantages of a dynamically typed language (a common theme throughout the conference). Thomas was a very interesting person to be around. Although it might be easy to confuse his confidence with arrogance, it turns out he is very approachable and is interested in two-way conversation as much as evangelizing his beliefs. If you go to one of these symposiums, sign up for one of his lectures early. After you hear him speak the first time, you will want to follow him to his next lecture.

Stuart Halloway � I attended two sessions presented by Stuart Halloway: �XML Schema� (a two part presentation) and �Class Loading�. Both sessions were extremely interesting. Halloway doesn�t have the engaging personality of the other speakers, but he was a very good teacher. He was well prepared, and kept the sessions moving nicely. I was especially surprised by the XML Schema presentation. I planned on blowing off the second half of the session in favor of a session by Robert Martin, but after the first session, decided not to. If your attending a show, I wouldn�t go out of my way to see one of Halloway�s sessions, but if your interested in the topic, you should know he will teach it well.

Bruce Tate � I had already heard Bruce Tate speak at a local Java User Group. He�s a good speaker. His presentation at the JUG was one of my reasons for attending the symposium. The presentation I watched (�JDO vs. EJB�) had a lot of review information from the JUG discussion on persistence frameworks. He presented the information well despite having problems with his voice. I would only recommend the session, however if you are still a big Entity Bean fan (are there any out there) and still need to be shown the errors of your ways.

Ted Neward � Ted Neward�s presentation was fun. He is very loud; very opinionated (�Swing Sucks! Get over it!�); and very funny (�� because consistency is the sign of a small mind�). I attended Neward�s presentation on �The JVM and the CLI�. The topic, which should have been inflammatory, was actually very analytical and very interesting. Neward also had so very interesting things to interject into Stuart Halloway�s class loader presentation.

I missed quite a few speakers including Bob Martin, but I think I got all I could out of the symposium, given the scheduling problems I described earlier. After early-bird and JUG discounts I only paid $550 for the weekend (less than the airfare alone to a show like JavaONE).

If you get the chance to go to one in your area, I would defiantly recommend it. I would specifically recommend finding sessions by Dave Thomas and James Davidson. Don�t go to sessions which just explain APIs you could look up in a book, instead take the chance to learn concepts while you have the chance to ask those who should know. If you get the chance, take a session about another language. Although the information might not directly apply to your daily work, and you may never switch, the new concepts will give you perspective that you wouldn�t be able to get reading a Java API guide.

After an intro class in �96, I learned Java on my own from books and online tutorials. It was very refreshing to sit and be taught again after all that time. I really need to do that more often.

What�s really wrong with Swing?

I ran across yet another set of posts on Slashdot where Swing is being bashed by people who obviously haven�t programmed in it for more than an afternoon. This got me thinking about many of the misconceptions of Swing and why they are made. First, here are a few issues I�ve seen MANY Swing programmers get hung up on:

• Swing components do not support multi-threading directly, so therefore many programmers believe all logic should be performed on the event thread
• Because it usually works to some degree, and it�s the easiest way to get the job done, many people believe they should always use the default models provided by Swing
• Everyone wants to subclass components to add functionality because they really don�t understand UI Delegates (or the limited role of a component in Swing).

There are many more of the concepts, but documenting them all would be an effort worthy of a book. I�ll stop with these three. I do believe (against apparent popular belief) that it�s programming mistakes like these that keep most Swing apps slow. I believe it�s only the large applications where memory usage comes into effect that the architecture itself causes significant performance problems.

I don�t want to spend any time proving these three concepts (if I get any requests to elaborate on any of them, I may in a future entry). For now, I want to talk about WHY Swing programmers don�t understand these concepts. It really comes down to prerequisites, documentation and the handicaps inherent of a component based system.

Basic Swing Books

Open most Swing books to the first chapter and you will find that the author expects only a basic understanding of the Java language. There is no assertion that the programmer understands threading of Java memory management. This is because the goal of most Swing books is to get the programmer up and running as soon as possible. The goal is NOT to create a competent Swing programmer, but to help the programmer to APPEAR competent as soon as possible.

Basic Swing books start by introducing each of the components (as a book on Visual Basic would do). It then shows how to use each component in the simplest of situations. Following this, the author will show how to change properties (usually through simple get and set methods) to change very simple physical of behavioral characteristics of the component. This will be repeated for each component for the remainder of the book. This is the basic format used to document any component based RAD tool. Swing, however is much more complex than the form designer�s of Visual Basic or PowerBuilder. That complexity deserves more attention.

Some of the better Swing books will also have a chapter at the end that shows the programmer how to change the look and feel. The chapter may also show a model explaining how the abstract factory pattern (employed by the Swing�s UI Delegates) works. Once again, this chapter will be more about making a programmer appear to be competent rather than teaching the philosophy of Swing. A programmer who knows how to change the look and feel, but not how (or more importantly when) to alter it, will look productive while only having to memorize three lines of code.

Advanced Swing Books

I have looked for suite a bit for a good advanced Swing book. Most of the books I�ve found so far seem to be nothing more than recipe books that explain parts of Swing that are readily available in the API (or in Sun�s documentation online). Some of the popular topics include:

• Building a Sortable or Filtered table
• Adding �advanced� editors to a table
• Creating a web browser from JEditorPane
• Drag and Drop
• Using JTree

What I would Like to See

I can understand wanting to get programmers up and running as soon as possible. Many programmers won�t buy a book unless they think it will allow them to see results almost immediately. What I don�t understand is why it isn�t communicated to the programmer that the simple solution isn't always the most correct.

Why isn�t there a follow up book that explains the other 30% of coding in Swing that all these intro books miss out on? The philosophy of Swing assumes that a competent Swing programmer understands threading, the limitations of the default models, how to implement new data models, and the responsibilities of Components and UI Delegates. There are also other philosophies such as the value of decoration over component inheritance and how listeners can cause memory leaks when misused. What I�m really looking for is a book like Joshua Bloch�s Effective Java that relates specifically to Swing programming� or better yet a book in the tradition of Thinking in Java, where the more advanced philosophies of Swing could be taught in conjunction with basic concepts.

Something that escaped the original complaints on Slashdot, is that Swing is complicated for a reason. When designing Swing, the authors had to choose between ease of use and flexibility. They choose the route of flexibility more often than not, which leave Swing much more complicated than GUI tools in other languages. If properly documented and understood by its programmers this can be a major advantage rather than the disappointment so many see it as today.

C# and Open Source

I've heard talk in private from quite a few Java professionals that .Net will one day replace Java. They point out that C# is a comparable language and most of the open source API�s are being ported to C# (and therefore to the rest of .Net). Microsoft obviously has more market pull than Sun (who rarely even gets respect from Java programmers). I can, in some ways, understand the fear.

Of course in reality, there isn�t anything to worry about. Java will not disappear. Porting open source projects to .Net will only help a handful of .Net programmers. C# will still fall behind Java in the area of cross platform support, vendor independence and effective use of the open source feedback loop.

Why doesn�t it help to port open source Java projects to .Net? Because Microsoft won�t directly support them, and lack of vendor support will make the projects useless. Very few companies will choose a development environment other than Visual Studio for their .Net development. Its very unlikely Visual Studio will have integrated Ant support. Microsoft will provide their own APIs for XML parsing, logging, preferences, etc. Most companies who choose .Net will ignore any open source project which improves on these APIs for the same reason they choose .Net in the first place: these companies want end to end tech support for their entire system; they want a single company to be responsible for the environment they use; these companies WANT a closed homogenous environment.

Why is Java safe? Because the companies that use Java today simply don�t have the same requirements as the Microsoft shops. Java and C# may be very similar languages, but they exist in completely different environments. Both environments have their pros and cons and both will flourish over the next 5-10 years.

Optimization vs. Readability

Coming from a CIS background, I've never had the same appreciation for low level optimization as co-workers with CS backgrounds. My philosophy has always been: readability is always more important than optimization, unless it's been proven that the specific situation is a bottleneck.

This opinion has never been popular, but it was dismissed almost completely in the early days of Java. Java was always sooo slow, that any optimization helped. Method calls were minimized; string manipulation was reserved for StringBuffers and character arrays; and anything that could be done in native code, was.

At the time, we did what we needed to do. Today, however, many programmers haven't accepted that those days are behind us. Not to say people should start writing slop; but more than ever before, we can trust the VM to do its job.

Consider this code:

StringBuffer buf = new StringBuffer();
buf.append("select table1.columnA, table2.columnB, table3.columnC from ")
 .append("someTable table1, someOtherTable table2, table3 where ")
 .append("table1.key = table2.key and table2.key = table3.key "
 .append("and table1.key=?");
con.prepareStatement(buf.toString);

It could look like this, without any performance penalty:

String sql =
 "select table1.columnA, table2.columnB, table3.columnC from " +
 "someTable table1, someOtherTable table2, table3 where "
 "table1.key = table2.key and table2.key = table3.key "
 "and table1.key=?";
con.prepareStatement(sql);

Not only is the direct use of strings easier to read, it's use is optimized in many IDEs (IDEA automatically places ["+"] in a string when you press enter in a string. Ctrl-J will concatenate strings from separate rows.).

Many programmers (especially those who suffered through the early version of the Java VM), still cache objects unnecessarily, rather than relying on garbage collection. Many implement all their Swing listeners in a single class and perform their own event delegation to save on class creation. My personal favorite is parsing Strings as character arrays, which of course renders the code completely unreadable while (according to an article in Oct 2002 Java Pro - "How Hot is HotSpot?") actually slows the code down in a modern VM. You read that right! In some cases, the code that was optimized for older VMs is now slower than more readable code.

One more thing to consider when optimizing that code: What costs your company more? people or machines? If your optimizing a problem that will improve the client's perception of the product, then go right ahead. If your making the code less readable because "it's theoretically faster this way", make sure the theory is true, and the change is worth it's time in readability.

99 Bottles of Beer

I read an article on Slashdot about a contest which would have programmers write an interesting program printing the lyrics to "99 bottles of beer on the wall". This inspired me to play with the Java Speech API. I wrote a quick program to recite the lyrics. It's really nothing more than a glorified Hello World program, but it let me play with the Speech API:

public class BottlesOfBeer {
  public static void main(String[] args) {
      Voice voice = null;
      Class voiceClass;
      try {
          voiceClass = Class.forName("com.sun.speech.freetts.en.us.CMUDiphoneVoice");
          voice = (Voice) voiceClass.newInstance();
      } catch (ClassNotFoundException e) {
          e.printStackTrace();
      } catch (InstantiationException e) {
          e.printStackTrace();
      } catch (IllegalAccessException e) {
          e.printStackTrace();
      }
      if (voice instanceof MbrolaVoice) {
          try {
              (new MbrolaVoiceValidator((MbrolaVoice) voice)).validate();
          } catch (ValidationException ve) {
              System.err.println(ve.getMessage());
              throw new IllegalStateException("Problem starting MBROLA voice");
          }
      }
      voice.setLexicon(new CMULexicon());
      voice.setAudioPlayer(new JavaClipAudioPlayer());
      voice.load();
      for (int i = 99; i > 0; i--) {
          String verse = i + getBottle(i) + " of beer on the wall. " +
                  i + getBottle(i) + " of beer. " +
                  "Take one down.  Pass it arround. " +
                  (i - 1) + getBottle(i - 1) + "of beer on the wall.";
          voice.speak(verse);
      }
      voice.speak("Thank you everyone.  You've been a great audience.  " +
              "I'll be here all week!");
  }
  public static String getBottle(int numberOfBottles) {
      return numberOfBottles != 1 ? " bottles" : " bottle";
  }
}

For those of you who don't know, the Java Speech API doesn't have a reference implementation. It only defines the api. I used an open source implementation called FreeTTS.

By sharing this code, I've disqualified my self from the contest, but since the code is judged on compactness, obfuscation and originality, I don't think I had much of a shot anyway.

By the way... when did obfuscation become a cherished trait in a programmer?

Issues programming on my Mac

I've been programming from my new mac recently, and ran into a few issues. I thought I would post them, not only to share with others, but in hopes that people may share their workarounds to some of these issues:

Creating an Application Bundle

Packaging my application was much easier than I originally thought. There really isn't an excuse not to provide an application bundle for a java application if you intend to support the Macintosh platform. I got really good use out of a book called Mac OS X for Java� Geeks. I'll probably post a detailed review when I finish it.

I initially used an application called MRJAppBuilder, (which looks very slick and easy to use), but it's output was missing two very important lines of code: the classpath and the main class. It's not that MRJAppBuilder didn't know what they were... it just failed to write the files out correctly. Very strange. Thankfully, the book had very detailed instructions for editing these files by hand.

I ended up copying all the resource bundle files into my source tree (for version control), and made an ant task to assemble them as an application bundle at deployment time.

Creating a Deployment File

I wanted deployment of my application bundle to be very Mac-like. I didn't want the user to see a hint of my Windows background in the download and installation process.

My first instinct was to create a disk image. As it turns out, creating a disk image from the command line (or ant) requires a bit more interaction than I would have liked. You must do a du on the source files to determine the sector count, then bump that up by a few percent for metadata, then create the image, format it, etc, etc. This would have required a hand full of support scripts and a lot of hair pulling. Someone should just put together an ant task for this mess.

My second attempt was to tar and gzip the files. It almost worked fine. Application bundles for Java contain a stub file (written in C) that executes your Java program for you. By default tar removes permissions from the files it archives (including the executable permissions). Ant's task has a option for specifying permissions, but I didn't have much luck getting it working.

I finally decided it wasn't worth the trouble. I used zip. It works great.

Refresh issues

For some reason, when I run the application bundle, I sometimes have issues with the toolbar not refreshing correctly. I haven't tried debugging it yet, but I suspect my property settings in the application bundle. Idea seems to have a similar problem in their message window (sometimes words don't redraw correctly).

Windows Keys in Swing

Java has always centered its identity around it cross platform support. Although they have never deviated from this focus, there has always been a wandering direction as to how to implement this cross platform support on such a wide variety of machines. AWT took the approach of the lowest common denominator. Swing choose to emulate a UI that would behave the same on all platforms. At first, Sun even refused to add support for the right mouse button; after all, if most Java programs require a two button mouse to work, is the language really cross platform?

I believe any language that is totally cross platform, would have to be distilled to the point of uselessness. As critics point out, not every aspect of Java is cross platform. Java programmers can write some very nice, cross-platform code; at the same time, they are not normally excluded from tapping into the platforms strengths:

• A J2EE project doesn't have the same set of constraints as a J2ME project.
• A Unix program can have a tree structure
• A Windows program can have right mouse button support

What about the windows keyboard?

For a Java program to be as usable as it's native counterparts, it should have the ability to respond to all the same key events. I understand that Sun has a delicate balance of functionality and compatibility to maintain. I didn't expect the Swing API to fire a right-mouse-click event on the currently focused component when the context menu button was pressed on my Microsoft keyboard (although that would have been really cool). I did expect, Sun to allow me to trap the key event on my own.

It turns out, that Sun (in some apparent fear of developers like myself), decided to strip out any key events it didn't recognize and replace them with a keycode of zero. I can't tell a windows key from a cash register key without dropping down to another language.

JDK 1.4.2 is due out in a couple months. Features for 1.5 are already being leaked. If you agree with me on this, vote for feature request 4352104 at Sun's Bug Parade so we can get the fix as soon as possible.

Programming in XML (cont.)

I thought I would clarify a couple things about my last entry. I apparently got so excited about the ramifications of an expandable syntax, that I didn't take the time to clearly define the programmer's view of this language.

All programming in an XML-based language would need to happen from within a IDE. That IDE would parse the XML and translate it to a more human readable format. Text like this:

Would be seen by the programmer as this:

public class MyClass {
  public String toString() {
      return "Hello World";
  }
}

For that matter, the same IDE might have multiple syntaxes for the same XML:

DEFINE CLASS: MyClass {
 FUNCTION: toString()
 END FUNCTION "Hello World"
}

Of course, the syntax would need to be within the same general family. You couldn't render a C based language as LISP or anything. Hell, I don't even know why you would want multiple syntaxes for the same language. My point is, the programmer wouldn't be reading XML.

I was also going to talk about an idea that involved wrapping a current language with an XML based language, but I realized that would only provide the component embedding features of an XML based language. You couldn't have an XML based meta-language if you were pre-compiling the XML into another language. Oh, well.

Programming in XML?

I read an interesting article in Dr. Dobbs today about embedding code in XML (XML-Based Programming Systems by Gregory V. Wilson, March 2003). The article predicts that one day soon we will be writing in languages based entirely on XML. This of course would have some drawbacks:

• The code would be completely unreadable by human beings
• We would be completely dependent on our IDE (take that, vi geeks!)

On the upside:

• Code and comments could be intermixed in the code and still be accessible programmatically (javadoc++)
• Code could be reverse engineered using all the features of XML (imagine Reflection with XPath support)
• And best of all (imho), third party plugins could add tags into your code without getting in your way.

Lets reflect on that last point a bit. Think about all those third party apps that leave droppings in your code: Together's UML javadoc tags; the generated code from JBuilder's GUI Designer (oh! the humanity!); xDoclet's code generation tags; the javadoc comments from that damned web guy!!!; the obscure javadoc tags that the company standards force you to add; and the list just goes on. By extending an XML based syntax, all of that information could be in the code, and your IDE would simply hide the features you don't need to see.

Just like IDEA will allow javadoc to collapse or expand, IDEs of the future could have an expandable dialog with a tree of dependencies; or a SVG drawing of data interaction in a given method.

I have to admit, I got most of the way through the article before I could even except the idea of not saving my source code as plain old text. But being such a big fan of open source, I have to admit, this would be a feature that would really interest me. If the language and it's markup could be extended by any number of third party tools, there would be no end to the inventive combinations of features.

When the open source community gets a hold of a flexible set of interchangeable components, they have a tendency to go to town. Just imagine what we could make with this.