Java IDE Review

I don't know if I have a learning disability or what, but learning Java is -hard-. Let's take simple web development in Java, for example. Even if you're familiar with web development in a different language, a simple Java application with a database requires you learn: JDBC, servlets, POJOs, JSP and Tomcat. Then! If you're interested in automating your build.. you know, compiling your code and moving it into the right directories in Tomcat, you have to learn Make or Ant. That's a tall order!

All of these items are distractions from my real goal: writing Java. But what should you use to write Java? I've heard Eclipse is nice, but Sun offers you NetBeans when you download the JDK. However, my friend use gVim for -everything-, but that's not really usable on Windows. What's a Java noob to do?

In the last two weeks I've tried a number of editors and IDE's trying to find something that helps me program in Java. My requirements for a "good" editor are:

• Line numbering
• Syntax highlighting
• Code folding
• The ability to compile Java and view the errors from within the editor
• Relatively easy to use
• Preferrably OSS
• Must run on Linux

Additionally, for an IDE, I wanted all of the above, plus:

• Ant integration, or some way to build the project and put the compiled crap where it belongs
• Source code control integration

Purists may argue that compiling code is NOT the job of an editor, but I wanted to include it anyways.

Below is a list of some of the more popular programs I evaluated, I will try to list them from simplest to most feature-rich.

1. vi
The original fall-back editor, not vim, but vi. Barebones and straight to the point, with no frills to distract you from what you're doing: editing something. Every day I'm editing documents in vi, even when I have other tools that are better-suited for editing, it's just too simple not to fall back on. However, anything more than a quick fix and I'll resort to another editor, but vi still kicks butt. Just don't plan on doing anything fancy like syntax highlighting, code folding or anything else in it.

2. gVim (gvim.org)
I've used vi for years on commercial Unix systems, but I'm far from a vi expert. However, vim is "vi, improved" so you get a metric ton of new features, most of them awesome, all of them with strange key bindings. My buddy JJ swears by gVim, it's the only editor I've ever seen him use, and consequently he knows it like the back of his hand.

However, gVim is just an editor. A great editor, to be sure, but it didn't really provide me the user experience I was looking for. Trying to memorize all the various key combos to do what I wanted was just too much on top of all the other crap I was trying to learn. It served as a distraction.. and I couldn't compile from within it. It's still vi at heart, no matter how you slice it. I'll still use gVim for Python, the development process lends itself nicely to having a Python shell open next to a gVim window. Go figure.

3. jEdit 4.2 (http://jedit.org)
jEdit came highly recommended, many people told me it was their favorite editor! It has a TON of plug-ins to do pretty much everything I wanted, but I admit I didn't spend much time to figure them out. Overall, it's a really good editor, but a bit quirky. I liked the alt+arrow key combo for indenting code, but it didn't always grab the last line I selected. I also couldn't figure out code-folding, it never seemed to work. Additionally, when I used Compiz the window wouldn't resize, it was stuck. This is a known bug, but still annoying. Lastly, it's kind of ugly, but still far more professional than Notepad++. I'd use this editor again with no complaints.

4. Eclipse 3.2 (http://eclipse.org)
When I think "Java IDE", I naturally think of Eclipse. Behind this IDE is a large and active community, decent documentation and a whole ton of functionality.

I had used Eclipse in the past, but found it to be really complicated to set up.. but that was years ago, certainly it's better now, right? Not really. It's still huge, and learning how to use it is another item on my to-do list. I used it for about a week, but never figured out how to get the build process working so it moved crap into Tomcat for me. Worse, I found it to be pretty slow on my machine (1.4ghz laptop with 1.5gig ram). I don't know, maybe it's just me, but I want my editor to be responsive. However, it had all the features I wanted and more, just too steep of a learning curve for my taste.

5. NetBeans 6.0 (netbeans.org)
NetBeans is my new IDE of choice. It has a good balance of ease-of-use and features, at least for me. It's also faster on my system than Eclipse was, but seems to have the same general feature-set. I had a bunch of trouble getting the build process working, same with Eclipse. I don't know Ant, and I didn't invest the time to learn it. I was able to work around the problem by symlinking my ~/NetBeansProject/projectName/build/web directory to $CATALINA_HOME/webapps/projectName. Yes, that's a hack, but it works pretty well.

NetBeans had all the features I listed above, including integration with CVS and SVN and comprehensive documentation.. plus, I actually got the build process to work for me. Overall it's a good IDE, it has code completion (which I don't care for, nor use), decent default fonts and colors, etc. I can't complain. If you haven't tried it, it's worth a look.

Anyways, that's my little review, if anyone actually reads this blog, let me know if there are any other editors/IDEs I should try. I left out commercial editors since I can't afford the $100-500 that they average. That being said, I hear that IntelliJ IDEA is amazing and completely worth the $250. Maybe one day, if I land a job doing full-time Java programming I'll give it a look. Until now, it's FOSS for me.

Testing Perl

I've been spending a lot of time writing Perl these days, and while I'm certainly no expert I tend to do OK. I've also been hacking Python in the evenings with my friend JJ in preparation for PyWeek. As such, I've noticed some fairly obvious differences in how I approach my testing.

In Perl, I typically have "test.pl" file and slam little stuff into there for quick "does this work" type of checking. In Java, I find it just as easy to test within the application since there's typically so much overhead in getting a "Test.java" file together (maybe that's just my inexperience.) Python, on the other hand, has a kick-butt shell. If you have a question about how something works you can just open the Python shell and tap it in, no stress.

Today, while sitting around hacking Perl, I ran across one of those situations where I wanted to test something (in this case, an array of hashes.. I always hose that syntax up.) I decided to test it using the Perl debugger, which can be used as an interactive interpreter, just to see how different it is from Python's shell.

You access the Perl debugger via "perl -de 42" (the 42 is bogus, you can put any number. I chose 42 because, well, it's the meaning of life.) Once started, you can enter commands into the prompt and see their results. Example:

bash-2.03$ perl -de 42

Loading DB routines from perl5db.pl version 1.27
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(-e:1): 42
 DB<1> my $string = "hi";

 DB<2> if ($string eq "bye") { \
 cont:      print "Adios!\n"; \
 cont: } else { \
 cont:      print "Howdy!\n"; \
 cont: } Howdy!

Compare this to Python:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> string = "hi"
>>> if string == "bye":
...     print "Adios!"
... else:
...     print "Howdy!"
...
Howdy!

Python is much cleaner and seems like it was built for this purpose, whereas Perl seems to do this almost as a side-effect. Having to give it a fake program name ("42") is also an indication. I also hated having to enter the line continuation character in Perl ("\"), I kept forgetting that and having it hose up on me. Python handles this much more gracefully. Overall, the Perl interpreter just seems clunky, but then again, I haven't explored it's full potential.

Does anyone really use the Perl debugger like this?

Little stuff

Today I finally got around to finishing up my vmware server install. The host OS is ubuntu 7.04 and my current guest OSs are also ubuntu 7.04 and windows server 2003. I built this computer about a year ago and am just now setting it up. Yes, it was probably a bad purchase. It also has a video card for gaming, but it's headless in the garage, also a bad purchase. :-)

I just wanted to jot a few things down for posterity:

1. If using a wireless network card, vmware may let you configure it as a bridged interface, but you can't really use it that way. Set up NAT within vmware and go with that.

2. If you do use NAT, you'll have to dork w/your iptables config a little bit. Here's a really basic (and insecure) iptables config. I'm already on a trusted network so it works for me:

#/usr/bin/bash
IPT=/sbin/iptables

echo "Flushing rules"
$IPT -L
$IPT -F
$IPT -F INPUT
$IPT -F OUTPUT
$IPT -F FORWARD
$IPT -F -t mangle
$IPT -F -t nat
$IPT -X

echo "Adding rules"
$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -t nat -A POSTROUTING -j MASQUERADE

echo "Done"

3. I use Xming on Windows for my X server. I added the "-an" option the shortcut so any clients can connect. Also insecure, but again.. trusted network. Plus, I only NEED to remote into my home systems very rarely, most everything is doable from the CLI.

I think that's it for now.

SSO Woes part 1

So I've been working on this nebulous "single sign-on" project at work with pretty much no usable successes yet. Honestly, I'm really beginning to dislike closed-source software, especially when you try to implement solutions even a little bit outside the box. Allow me to regale you with tales of my SSO implementations, the pitfalls I've hit. If you want more detail on the implementation, let me know and I'll provide you my notes.

SSO with Apache/Tomcat for Lawson Portal - 7.2.4 apps / 8.0.3 env
This project actually worked pretty well, I have true SSO working for authenticated Windows clients. They can pop open a browser and access protected pages on Apache w/o having to enter their username/password, just as advertised. Good, right? Wrong.

After making the changes to the httpd.conf to support SSO, everything looked good. You could log into the Portal and it would welcome you by name. You could even launch programs, but "inquiring" would fail with an error.

Portal is essentially a mash-up of old and new Lawson web technologies; the old CGI programs and the new Java servlets both play a part. It seems that the CGIs work properly (ie, they accept the REMOTE_USER variable), but the servlets were giving me problems! What's that all about?

I decided to decompile the servlets and take a look. Lo and behold, they were specifically preventing any NON-Basic authentication (unless you were on an AS/400)!! I altered code to allow basic auth and recompiled. It works! Too bad I can't use it, that would be completely unsupported and managing a mod like that (to a whole bunch of servlets) would be a pain, plus I would have to test with the other Lawson products (MS Add-ins, etc.)

Just one example of being blocked by closed-source software.

AMD64, nForce and Ubuntu

As part of my move to California, I've decided to move my "servers" into the garage. I finally brought my first system up last night, Ubuntu 7.04. Apparently the 2.6 kernel has some issues with the nForce chipset and ACPI, so installs would just hang (black screen with a blinking cursor in the upper-left hand corner.)

I was able to get around this by adding "acpi=off" to the boot arguments, but even still, gparted would hang! I eventually just used the entire disk for the install and called it good.

Another twist is that I haven't run cabling into the garage so I grabbed a cheapo PCI wireless card from Fry's ($25) and tossed it in. It's an AirLink AWLH3026T and was supported right out of the box, a welcome change from having to futz with fwcutter.

The whole purpose of this box is to file serve and host VMs for any side work I may stumble across. As such, I installed VMware Server 1.0.3 last night and it went smooth as silk by following the instrutions posted on http://www.howtoforge.com/ubuntu_feisty_fawn_vmware_server_howto. I also installed the web-based management utilities (mui) by following directions on this post http://users.piuha.net/martti/comp/ubuntu/server.html The next step is to find some VMs to run :-)

Learning Java

A long time ago I was a professional web developer. At the time, my toolbox consisted of MS Access, Sql Server and Cold Fusion. Over time it morphed slightly and I moved to the LAMP stack, which was really hard since suddenly I was doing 'real programming'. After a job change, I ended up drifting from heads-down programming and have been doing systems work for the past five or so years, most of it with a focus on the Lawson ERP (COBOL). As such, I've been feeling like my toolbox is missing something; the tools are rusty.

Like a fool, I decided to learn Java.

My first book on the subject, Thinking in Java, is a brick. 1400 pages of unnecessary detail for someone new to _any_ language. If you pay a writer by the word, this is what you get. Right now I'm going to recommend avoiding it, but it could prove valuable in the future as a reference or something.. who knows.

My second book, which I'm about halfway done with, is Teach Yourself Java in 21 Days. So far it's been pretty good, esp compared to the Thinking book. Chapters are short, but not too short. There is enough detail that I can hit Google for clarification on any point they don't cover well, etc.

It seems that a friend of mine has also been looking at Java, he's a fairly novice programmer and we've talked about programming on and off for some time. He was working on a "craps game" application, so I decided to write a little "dice game" of my own, but without the crazy rules of craps.

Additionally, my good friend JJ is a "language lawyer" and has been kind enough to review my code. As such, one of the stipulations is that I also port each little program to Python. So, essentially, I'm learning two languages at once, ha ha ha! We'll see how that goes.