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.

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!

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.

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:

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."

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.

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?

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�

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?