The IDE that’s rocked the community so much that Manning decided to publish a book about it: IntelliJ IDEA in Action.
For those who don’t believe IDE’s offer a significant increase in productivity take a peek.
Oh, and for those of you infatuated with split screen features (and I know you’re out there) - yes you can split your view as much as you like 
Having just returned to Melbourne after a longer than expected stint in The Netherlands, I have been going through the rigors of resume updating, assessing the market, applications, interviews and a temperature shift of some +34 C!
It’s generally a stressful time considering opportunities, balancing the base urgency of income with working in a challenging environment with quality people. Unfortunately, usually one doesn’t imply the other, with the odd stand-out exception. What’s made it a tad worse for me this time is the stressful and time-consuming nature of relocation. It’s been a distraction from performing pre-interview tasks that most competent organizations demand, such as solving coding problems or answering questionnaires. It’s also distracted me from pushing through my book list, with a book I’ve been looking forward to punishing, Agile Web Development with Rails, unfortunately taking a back seat.
Looking for a position this time around has also been a tad different for another reason. I’ve been asking myself if using the “J2EE” word is a bad thing from both a job advert point-of-view and from advertising myself as a “J2EE Developer” point-of-view. I’m very comfortable using the “Java” word but “J2EE” is another kettle of fish. Certainly I consider the use of the “EJB” word to suggest that perhaps an organization isn’t that switched on. I have no doubt most organizations using EJB are not doing so for sound technical reasons.
I guess a big reason why I’m dubious about using the “J2EE” word is its traditionally strong association with the “EJB” word. Of course I expect any “Enterprise” development I’ll be doing in the near future to be using some part of J2EE, so based on that alone it would be unwise to consider the “J2EE” word badness. It’s also not that bad given it contains a heap of API’s with perhaps only one bad apple in the lot.
But still J2EE anti-sentiment grows. More and more often comments on theServerSide discussions read “J2EE has cost organizations billions”, “J2EE has set the industry back years” and “EJB1/2 have done irrecoverable damage – EJB3 is too late”. Sure, maybe early on we veered from the asphalt, but the industry has firmly steered back on with Spring, Hibernate and alike. You cannot possibly argue that they (i.e. JCP committees) are continuing to steer us in the wrong direction – they have demonstrated a track record of responding to feedback. Maybe they steered us in the wrong direction when the industry wasn’t sure where it was going, and now it does and they are being responsive.
So right now I’m not too fussed using the “J2EE” word. Perhaps shortly I’ll be modernizing my role description to “Software developer with Java, Ruby, Python,
I guess this mirrors my sentiments towards, one day, having a world with one currency and language.
Before my last assignment, for sometime I had hoped to work on an a Swing App as a short break from developing web UI’s and to see how the other side lives. (Just like Simon does it seems)
Well my first experience has left me fairly jaded, mostly because Swing was far more complex than I expected – certainly far more complex than it should be. Perhaps Swing is another example of overtly complex software development in Java.
The most significant gripe I have with Swing is its tool and framework support. They don’t seem to be there yet, at least to the same quality and depth of web tools and frameworks. I guess its a reflection of the volume of Swing vs. Web App implementations. There are plenty of tools to assisting in composing Swing screens, but there’s always a catch. The code generated is terrible (sound familiar?), they require a custom component library, they come at significant cost. There have been no frameworks like a Struts that has strongly influenced Swing application development.
Some (non-coders) I worked with were of the opinion that Swing Apps must be simpler to develop than Web Apps. There’s less tiers right (as in physical tiers)? Yes, but I believe it’s actually harder. Yes, less phyiscal tiers may mean simpler installation and configuration, but as a software developer that doesn’t help my day-to-day activities. From a software perspective the same tiers exist - but Swing offers developers even more opportunities to hack. For instance, as the View is completely Java it offers more opportunity for the View to be spaghettized. Also a significant amount of ‘glue’ code is required to enable drag-and-drop, copy and paste, undo and redo functionality and alike. Glue that can be quite easily hacked to hold domain logic and other layers. So it requires plenty of discipline to maintain the conceptual integrity of Swing Apps, even more than Web Apps.
Talking of Swing Hacks, I recently purchased a book titled just that, Swing Hacks, containing 100 ‘hacks’ for constructing complex Swing UI’s. For mind, right now that title makes perfect sense for Swing.
Swing tries to provide you with the tools you need out the box, like progress bars, file choosers and transfer handlers, but they often require implementation or customization. This slows your progress and constantly gets you asking yourself, ‘It feels like I’m re-inventing the wheel here. Surely this type of thing has been done before? How could it possibly be this verbose?’.
Going even deeper, occasionally Swing’s API made checkstyle compliance extremely difficult. In cases were the API presented methods that contained some 8 or so parameters, the team had no alternative but to crank out a suppressions file. Data Abstraction Coupling was another that the UI layer consistently struggled with, after all it’s fairly common for containers to house a fair amount of components.
Then there’s the functional testing tools, there are plenty of them but each have their short-comings. Mind you, we were using open source tools (eventually choosing Jemmy) so you get what you paid for, but plenty of customizations were required. Screen discovery as Pam mentioned in her blog was one of them. We encountered larger issues striving to have our functional tests executed on both Windows and Macs, but we never expected that to be a simple task. Different key-strokes and different component behavior all mounted to tests that were time-consuming to produce, so much so that some journeyed to manual testing land (mysteriously never to be discussed again). The functional tests were also extremely fragile, for instance drag-and-drop tests needed to literally control the mouse, so no mutli-tasking for developers while tests executed. Regardless of these set-backs, the value of immediate test feedback is too great for any team to justify scrapping them.
I admit that working with a Swing team that was relatively inexperienced compared to the Web teams I’ve worked with has significantly influenced my thoughts. Still, Swing is screaming for simplification. I understand that Mustang will re-write/enhance some of Swing. I particularly applaud the decision to Improve Swings drag-and-drop Support. Great - it’s all much needed, but don’t stop there. In the short term, Swing is crying out for some simplifying frameworks, just as Web Apps were 5 years ago.
