Windows as a useable Java development environment?

8 08 2007

Recently I had to spend a fair amount of time working on CONGO on a Windows XP platform. Stonekeep is doing doing it’s first event where CONGO will be running entirely on Windows XP, so all the environmental stuff I’m used to having under Linux doesn’t work, naturally. Things needed to be updated. This presented many challenges…

Normally I’d just import CONGO into Eclipse (where I’ve been doing most of my Windows development), and run with it, but CONGO was my first ‘big’ Java app, and, well, I made some poor design decisions that make moving it into a formal structured environment like Eclipse… somewhat problematic.

What I needed to do was set up my Windows XP environment to behave very in a similar fashion to my Linux environment, without trying to reproduce Linux-under-windows. I’ve gone the Cygwin route before (which tries to emulate a Unix environment completely), but I found the inconsistencies got in the way of being productive, and the installation overhead is enormous. So I needed a compromise.

The needs

There were several basic functions I needed to have in order to run the two sides of my application successfully. CONGO consists of a standalone ‘application server’ (called ‘cserver’) which runs in it’s own standalone Java process, answering XMLRPC requests, and a PHP-based webclient called “Coconut”, providing the user interface. To run both these pieces I needed Java, PHP, a webserver, a database, an installation tool, an editor, and a way to interact with my SVN repository.

The Tools

LAMP
A large part of my needs were covered with XAMPP, a bundled set of tools that provides LAMP functionality to a windows environment (WAMP?). With one swell foop, I had a PHP interpreter, an Apache webserver, and a MySQL instance, plus a database tool (phpMyAdmin).

The Compiler
Sun provided the appropriate JDK (Java Development Kit) to compile the application server as needed. I don’t have a binary distribution of the code yet, so an installation consists of checking it out of SVN and compiling it. The JDK installed just fine (into C:\Program Files\Java\jdk-versionumble)

The Editor
For an editor, I chose to work with JEdit for a while. It’s a pretty editor, and is completely Swing based. It has some annoying twitches, and I’m not sure if I’ll continue using it in the long term, but for this event-cycle, it was fast, workable, and did the job just fine.

The Build Tool

Build tool – This is one of the sticking points for portability into Eclipse. I don’t actually compile CONGO in a ‘normal’ fashion, and my class definitions are all screwed up. To address my odd setups, I use Ant, a very very good build tool specifically designed to work with Java projects. I had already been using Ant build scripts on my Linux installations, so having this available under Windows was a huge win.

I downloaded the Apache Ant binary distribution, and unpacked it. Because Ant is basically just a simple command line tool, it really doesn’t have a Windows installation process, it just needs to be unzipped. I put it in C:\Program Files\ant.

The SVN Client

This one was a toss up. All my code is stored in an SVN repository on a remote machine in a colo facility. In order to check in and out code, I needed to have an SVN client on the machine.

The natural inclination would be to download the command line SVN client, which is available from Tigris.org, but that seemed to be me falling into the “it must be just like Linux!” mode, which I was trying to avoid. Instead, I opted to install Tortoise SVN, a tool that integrates SVN functionality right into the Windows explorer. This turned out to be an EXCELLENT choice. I found TortoiseSVN to be stable, fast, and eminently useable for my checkins and updates, without having a steep learning curve.

windows properties

The Configuration

So far so good. I had all the tools I needed, but Windows isn’t normally comfortable with command line only interaction. I could spend time configuring tools into JEdit like Ant Farm and the like, but that runs the risk of being distracted with some serious yak shaving, something I didn’t have the time or the inclination for. Instead, I opted to set up Windows to handle command line use of Ant.

The primary challenge here was setting up the paths correctly. Under Linux, I’d simply add the path to my .profile and off I’d run. Under windows it’s slightly more challenging. I found a handy little shortcut for doing a ‘fast’ path change similar to using $PATH in Linux:

In Linux:

$ cd /usr/ant
$ export PATH=$PATH:`pwd`

In Windows:

C:\> cd "\Program Files\ant\apache-ant-1.7\bin"
C:\Program Files\ant\apache-ant-1.7\bin> path=%path%;%cd%

This shortcut is a great way to make sure all the things work correctly before actually modifying the system. I did this for both the JDK and for Ant, and lo! I was able to do ‘ant’ commands, builds, and run my app. Hooray!

CONGO under Windows

The last bit was to change my default system path under Windows to include these new directories. This was accomplished by following the tortuous path:
Right click on My Computer->Properties->Advanced->Environment Variables…
Then scrolling through the ‘System Variables’ until you find ‘Path’, click ‘Edit’, and append on the JDK and Ant binary home directories. Windows thoughtfully makes this input window only about 30 characters wide, without the option to resize, so expect to do a little scrolling. Phew. But this meant these paths were set every time I started up a CMD.exe shell

At the end of it all, I had a clean environment where I could not only run my appserver, but also use Firefox to access Coconut. Hooray!

Conclusions

It’s hard to buck trends. There’s no question that Windows is used for serious work, but many Linux users scoff at the concept of using Windows as a viable development environment unless you’re doing Windows specific coding, such as .NET or Visual Studio type work. Much of this derision comes from the different approaches to environment. Windows tends to be pointy-clicky, doing a lot of ‘assistance’ to the developer. Linux programmers prefer command line editing and compilation (though that is rapidly changing as tools like Eclipse, IDEA, and Netbeans gain popularity). Regardless, this article shows it is possible to set up Windows for simple command line operation, with some of the benefits of a full GUI, without spending hours upon hours tweaking and installing random tools.

Advertisements

Actions

Information

2 responses

8 08 2007
Allen

As much as I adore Linux as an application platform, I’ve always done all of my actual development on Windows (using a great many of the tools you’ve indicated here). I’ve tried to use Linux to do my actual Linux dev work before (what a thought!), but at this point the tools I use on Windows are just too ingrained into my internal processes, I think.
Also, you asked: (wamp?) That’s actually the exact name of the Windows LAMP package I currently use for my home development. 🙂 (Someday I’ll have my own dedicated Linux server and won’t have to develop this stuff on my desktop box… *sigh*)

8 08 2007
dbs

Yah, this wasn’t really a “here’s the state of Linux development” or the like. If you really want to migrate, and you’re used to heavy duty tools, Eclipse and IDEA and Netbeans and the like are platform agnostic, and really work the same no matter where you are.
The trick for me was that CONGO is, well, not organized well, and wouldn’t migrate into the more structured Eclipse environment I was used to under Windows, so I had to improvise, which ended up with me learning a lot about how to configure Windows environments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: