One thing I dislike about Netbeans is the ant integration for single file compilation. Pain in the [insert-euphemism-for-nether-regions-here]! Okay, there’s an automatic creation of the ide-file-targets.xml — but it has required a degree of modification for most (read as ‘all’) projects I’ve worked on. Case in point — if you separate your source files from your unit tests (src & test directories for example), the default creation of this file doesn’t work (or at least it doesn’t for me). The fixed classpath in the default target exacerbates the problem, forcing one to edit the file as soon as you add jars to the project (unless you set up a dynamic classpath from the get-go).

Handling this file is, I believe, something that neither I, nor any developer, should have to deal with. It feels uncomfortably like having to hack the IDE for something that should be built in by default. Integration with ant is all very well, but I don’t think editing those project-generated ant scripts should need manual intervention except for the most unusual of circumstances. And certainly not to add single-file-compilation for code in another source directory.

By the way, in order to add another source directory (such as a ‘test’ dir) for single-file-compilation, add a new action to project.xml as follows:

  
 compile-selected-files-in-test
 
files
  test
.java$
relative-path
  
   ,
  
 

(This is just a copy of the action created automatically when you first pressed F9 to compile a file in the main source tree — with a new target and folder).

Then add the new target to ide-file-targets.xml:

 Must set property 'files'

 
 
  
 

Note that I’m using a dynamic classpath in the above target (with a refid to the actual classpath) — whereas the default usually has a list of jar files.

My latest article has just been published in O’Reilly’s ONJava:

“Playing Together Nicely: Getting REST and SOAP to Share Each Other’s Toys”.

It’s running earlier than expected — for some reason I thought it was scheduled for next Wednesday, rather than this week.

One correction that may (or may not) get reflected in the article — from the paragraph on page 4:

Although the rather pedantic nature of validating WSDLs (missing, anyone?) means slight changes can have significant impacts on validation, and I’m only guessing (because I have yet to fully test this final feature) as to its ultimate usability.

The first bracketed section should read:

(missing “/” anyone)

Alluding to the fact that leaving a slash out of url in wsdl can sometimes have far more effect than you might think.

Relief ensues, as the font smoothness in Netbeans, on my small laptop screen, is still apparent on the large LCD. There are neither the groaning slowdowns nor massive spikes in CPU usage that I was getting in Eclipse with the same projects loaded, so the experience is positive all round.
Not to forget that I’ve been using Netbeans for years, so despite the novelty of using an alternative IDE, I somehow feel more productive in Netbeans (though perhaps mainly through familiarity).

So, it would appear that my own “inexorable march to Eclipse” has turned into an all out retreat back into the fold. How does it feel? In the words of Wesley Snipes (in US Marshals, I think): Righteous. Very righteous.

SIDE NOTE: Looking forward to Mustang (Java6) since the fonts in the Linux GTK look-and-feel look even better…

Initially I didn’t like the concept of a workspace in Eclipse, but now I do. Going back to Netbeans, I suddenly miss the facility. I have a bunch of projects I need to use at work, and then another group of projects for various development efforts I’m running at home. I don’t want the work projects visible at home, and I don’t want the home projects visible at work (either way it’s distracting) — but there doesn’t appear to be an obvious way to accomplish this in Netbeans. I can think of a couple of hacks, but none are particularly nice.

Another stunning omission is lack of support for syntax highlighting other languages. Python/Jython highlighting is available with the Coyote project. Not sure what other languages are available, but it seems as if PHP, at least, is not. It’s a bit of a joke that JEdit has had support for C/C++, PHP, shellscripts, etc (basically you name the language and support is probably there) for an age, but Netbeans is up to a 5 release with support for bugger-all other than Java. Yes it’s an IDE and therefore has a different set of objectives to an editor like JEdit, but if you’re a developer working in more than just Java, the omission is glaring. Anyway, doesn’t the “I” in IDE stand for “integrated”?

Speaking of JEdit, the anti-aliased BitStream mono font, also looks acceptable there, so I think I’ll be moving back to JEdit, for my Python projects at least.

I am the mexican jumping bean of IDE usage.

Eclipse performance (Java dev, not python) has suddenly groaned to a halt. 98%+ CPU usage doing even simple operations. Some operations can take a minute or more before the CPU recovers. Performance was okay, before I started attempting to get some legacy code running outside of its framework — so lots of errors per file, and massively bad performance. Increasing memory allocation, fiddling with GC settings, and so on, makes no difference — and turning off auto-compilation makes a modicum of difference, but (IMO) renders the IDE otherwise unusable (personally I don’t think eclipse is designed well-enough to function outside of it’s default mode of operation).

So back to Netbeans to see if it’s any better (my suspicion is, it will be). Gah! There’s that ugly font again. However, this time, a quick google search recommends turning on anti-aliasing, along with choosing a better font than monospace. I was aware the anti-aliasing option was there, but didn’t bother trying it, since last time I tried the results were less than optimal. Now that I think about it, the last time I tried was probably an early beta of Netbeans 4 (or perhaps even back in pre 3.6 days) — and I imagine I only tried with monospace (yuck). To my surprise (and that will teach me for not researching properly to start with) BitStream Vera Sans 12 (with anti-aliasing), looks exceptionally good. Not sure if it’s up to the standard of Eclipse, but actually it might be.

The big question is whether it will still look good tomorrow morning on the 19″ LCD running at 1280×1024, as it does on my laptop (12″ widescreen 1280×800)….

From Simon Phipp’s weblog, an article on redherring about Eclipse:

…companies like Borland and Oracle are seeing their JBuilder and JDeveloper products lose relevance… …Borland has said its 2006 product will be based on the open-source competition. Oracle announced in June that it would lead an Eclipse tooling project and made JDeveloper free.

Personal opinion time, but I think JDeveloper’s loss in market share has a lot more to do with the fact that it was (perhaps still is?) a pile (feel free to guess what I think it’s a pile of). Admittedly I haven’t touched it in a year or so, but I had a colleague who was a fan and whenever I had to help him with something, I always found it too quirky… and not in a good way.

JBuilder, I haven’t used in years. For quite a while, it was my IDE of choice, but after Forte (later to become NetBeans) was available for free — and despite the fact it was an absolute pain in the proverbial at the time, I still moved onto NetBeans as soon as I had the opportunity. But for sentimental reasons, I’m sorry to hear Borland’s market share is dwindling in the Java space, since I’ve used their products since (I think) Borland C++ in the MS-DOS days. But that doesn’t mean I’d want to go back to JBuilder.

More recently, I’ve needed to use an older version of eclipse, in the form of WebSphere Application Developer (WSAD) and very briefly Rational Application Developer (RAD). After initially being impressed with a (small) selection of the tools and wizards built into WSAD, I’ve lapsed back to a state of extreme indifference. I still prefer NetBeans — even though that IDE still doesn’t exactly fit my personal development style either. Fonts are nicer in WSAD, but NetBeans feels more responsive (at least in Fedora, it does); NetBeans doesn’t seem to get in my way as much, but WSAD has tools that are, occasionally, really useful (xml schema validation, springs immediately to mind). The plugins for NetBeans are… well… generally lame, while the plugins for WSAD/Eclipse are as varied as the community itself — but on the other hand WSAD and RAD are, in my opinion, bloated memory hogs. RAD ultimately died a death on my laptop, despite having 1GB of RAM — which is just craziness. I’ve no experience (yet) to indicate whether this is a problem on the Eclipse platform as a whole (on linux), or just a WSAD/RAD specific issue.

To be quite honest, if I could have JEdit, with the slickness of a Netbeans 4 (or even Eclipse 3) look-and-feel, I’d dump both Netbeans and Eclipse in a second. Of course, when I last checked, JEdit’s code-completion plugin was still buggy and, for me at least, pretty unusable — so that rules it out for a lot of developers — but I still use it for Python/Jython development, and the occasional quick java hack. At home, at least, the inexorable march, has taken a side road (that said, I may join the general throng heading towards Eclipse-town, if my experience with pydev proves a success).

I’m with Rick, there are some things I like about WebSphere Portal… but unfortunately the list of things that annoy me grows ever longer. Some aren’t necessarily IBM’s fault — the whole portlet framework is flawed; entirely too intrusive, somewhat obscure (some things are as obvious as a polar bear in a snowstorm), and at times, downright painful:

• support for other templating mechanisms is seriously limited (read: non-existent). I’m using Velocity, but it wasn’t without significant effort (think of those taglibs you use in JSP, then imagine portlet life without them — and the taglibs use functionality that’s not covered in the javadocs). Yes, I probably should have used JSPs (and next time, will), but I prefer Velocity — particularly for complex pages.
• features that you might think would be easy to control, are either impossible, or at the very least excessively difficult: How do you get the name of the page that a portlet is running inside? Why is changing the mode of the portlet so difficult? etc
• the user interface…. shudder
• portlet reusability is a pain – the process of copying and reusing an individual portlet should have minimal cost associated with it (and not involve copying the entire web application)
• pages layouts are nowhere near flexible enough
• the html page header should be (at least semi) accessible; for including javascript files, stylesheets and so on, without having to embed them in the page
• from the WTF files: vaults, segments, credentials, etc (API design-by-monkey)

Those are just off the top of the head, and without mentioning the horrific memory usage, the fact that the html generated by Portal is horrible, the lack of an independent test environment, the fact that the test environment won’t install on my Fedora laptop without having a few million terabytes… of RAM, and the server tends to crash on occasion if you’re doing lots of webapp updates (which, of course, you do during development).

Okay, so I did mention them.

Gah!

I take it all back.

Currently rolling back to Websphere Application Developer 5.1.2 (from the nicer looking RAD6). I originally made the move to RAD because it seems that the Portal Test Environment doesn’t work with WAD5.1.2 on Linux, and rumour has it that the TE does work on Linux with RAD6…

However, after spending 5 hours on an install, one takes the time to read some docs & forum messages, and discovers that the minimum system requirements for installing the portal test environment is 2GB of RAM!?!@!#? (obvious rejoinder: why the hell didn’t I check first? answer: who expects an install to require 2GB?)

A couple of thoughts jump immediately to mind — both unprintable.

In any case, not only is the installation an impossibly long task on my development system, the RAD6 environment doesn’t make a huge amount of sense compared with WAD5. Websphere Server settings in particular don’t appear to be where I expect — and it’s difficult to justify taking the time to figure it all out at the moment, when I already know how to debug in ver.5.

So, back to WAD for the moment. Which won’t make life easy to test portlets, and doesn’t have anywhere near as attractive an interface, and acronym. Sigh.

I’ve recently moved to using Rational Application Developer [edit: now RAD, not WAD]. Not out of choice. I’ve played with Eclipse a few times in the past, but never been particularly impressed – which makes me one of few, it seems, considering the mindshare that eclipse has garnered.

There are a number of things which I find annoying, among them the intrusiveness of the IDE, an inability to customise directories and path structures in a way which I am familiar with, and so on. Worst of all, there’s a sense of deja vu harking back to the days when I (briefly) used VisualAge (shudder), and even though Eclipse/WAD/RAD aren’t close to being that horrific, there’s still guilt by visual association.

However, I do like the integrated test environments — which came as a surprise, since with NetBeans I have generally gone into the options, turned off pretty much every module, and then scripted the bejeezus out of the command line to do everything I want (outside of the IDE). I’ve always found the scripted approach (either using Python or Jython or plain old bash) more powerful — but admittedly the RAD style is growing on me…

…probably like a fungus.

Up until now, I have used Log4j in most of my development efforts — be they personal, open-source or corporate (there’s an argument I should have been using a logging bridge of some kind, to insulate any 3rd party users of my code from having to use my logging system of choice — but most of the work I’ve been doing hasn’t had a huge number of 3rd party users, so it hasn’t been that much of an issue). However, I recently came across Graham Lea’s simple-log; the basic premise of which appeals to my drive to simplify things as much as possible. So, bye bye, Log4J, it’s been great!

I’m currently running a couple of java applications which rely on the commons-logging bridge, alongside of which I use velocity (which itself uses Avalon LogKit or Log4J by default). In order to integrate simple-log and drop log4j out of my lib path, I need to provide a logging implementation for commons-logging, and also change the default velocity runtime logsystem.

SimpleLogger.java (stick your own package in front of it), does both. To use it, make sure you set the runtime property for commons, e.g.:

-Dorg.apache.commons.logging.Log=yourpackagehere.SimpleLogger

and then set the logsystem for velocity (where ve is the VelocityEngine), using the same property:

ve.setProperty(VelocityEngine.RUNTIME_LOG_LOGSYSTEM_CLASS,     System.getProperty('org.apache.commons.logging.Log'))

Read the rest of this entry »