Eclipse

http://www.eclipse.org/downloads/index.php

Download the JDT Eclipse installer. Source code, etc is optional.

Eclipse is a multi-platform, open source, Java-aware Integrated Development Environment. It has many terrific features which will save you time when writing and debugging code. It is open source and supports multiple platforms. Eclipse is not "Java-centric", and there are active projects which use Eclipse to develop C/C++ code.

We recommend the most recent release from the "current stable builds" list. Eclipse templates change between major versions such as 2.1 and 3.0, so be aware that once you upgrade you can't easily downgrade again. Eclipse is evolving rapidly. We will not attempt to update this area of the website for every minor Eclipse release. Please get the most recent stable build and assume that its operation will be very similar to what is shown here. At a minimum you will need the Eclipse Platform and Java Development Tools - you can get all this in one whack by downloading the Eclipse SDK, but it's a 100 MByte whack and includes source code and other items which you may never use. You can download just the "Platform Runtime Binary" and the "JDT Runtime Binary" which together are about half the size of the complete JDK.

http://www.sunspotworld.com/SPOTManager/

If you want the beta releases, go to the Preferences tab and select that...

Also see this informative blog by a member of the SPOT team.

You can now get access to the latest SPOT SDKs including pre-releases (use at your own risk!). You don't have to already have SPOT hardware. You also must have Ant and a JDK to use the SPOT SDK.

SPOT's JVM, Squawk, is now in the final stages of being open-sourced, and it is free for non-profit use. If you want to use it commercially you must purchase a license. How much does that cost? It varies (contact Sun) but you can expect to pay in the neighborhood of $100K.

Greenfoot: http://greenfoot.org/
TrackBot scenario: https://trackbot-greenfoot.dev.java.net/

All embedded Java systems as well as the PC. Much smaller and leaner than Eclipse, so loads much faster. Excellent and preferred for quick editing of code files, code snippets, etc where you don't want to hassle with an Eclipse project.

JEdit is almost unbelieveably slick and elegant. It's a very responsive Java application itself. The whole JEdit runtime download is under 1.5 MBytes, and full source code is available. The plugin manager is a thing of beauty, but recently Eclipse and other IDEs now also handle plugs very well.

JEdit is suitable for all your Java development, but doesn't handle large projects as nicely as Eclipse.

JEdit is lean and simple and relies on plugins for many of the features you will consider essential, such as class browsing.

http://www.macromedia.com/software/dreamweaver/
(free trial, or you can purchase the product for about $400)

... or use your favorite free HTML editor (it doesn't need to be fancy)

Java SE SDK:
http://java.sun.com/javase/downloads/index.jsp

This is the Java Standard Edition. You want the J2SE SDK 1.4.1 or later. You may also want examples. Do not use the older JDK1.4 which has known problems when cross-compiling. While you are there you may want to download relevant white papers. With Java 1.5 the numbering system has changed - it's became "Java SE 5.0".

If you're new to embedded Java, and to cross-compiling (i.e. running a program on hardware different from that used to compile it) it may seem odd that the version of this JDK has almost nothing to do with the version of Java you will be running on your embedded system. Don't worry about this for now, it will be explained in the tools installation details.

http://java.sun.com/products/javacomm/

download javacomm20-win32.zip (300 KBytes), or whatever is the latest version for your platform. Or, if you have the option, use rxtx instead.

In order to use serial communications on your PC, and use the standard Java communication API on embedded systems, you need the Sun COMMAPI. Javaxcomm is the standard Java serial and parallel I/O support package. All true Java systems support javaxcomm serial I/O. Embedded systems don't support the parallel port since it's PC-specific.

Sun has not maintained the windows version of javaxcomm very well,, and has not released the code so that others can maintain it. However there suddenly appear to be new releases especially for Solaris and Linux. But you don't get the source code, so... you may be happier with RXTX.

Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.

Why another build tool when there is already make, gnumake, nmake, jam, and others? Because all those tools have limitations that Ant's original author couldn't live with when developing software across multiple platforms. Make-like tools are inherently shell-based -- they evaluate a set of dependencies, then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as Unix, that you are working on.

Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.

Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.

Windows NT/2000/XP systems only

optional but very handy

Windows XP and some applications (Adobe Photoshop is one) want to have a swap file located on a different physical drive from the one containing the application. Having a swap file on a different physical disk apparently offers better performance, since each drive will have its own RAM buffers. Ideally each drive would also use a different IDE controller.

I like to keep my system files and non-development apps on drive C and all my developer files on drive D. That way I can mess with drive D all I want and run no risk of scrambling the operating system.

The base Java class files are identical regardless of the platform on which they will be executed. This is the "write once, run anywhere" feature of Java (some would say that "write once, debug anywhere is more accurate"). Java platform-specifc support is contained in optional packages which you reference in your program and at compile time. You will be using a PC-based Java compiler in "cross compiling" mode.

"Cross-compiling" means that you will use a compiler executing on a given hardware platform (A Windows PC for example) to create code which will be executed on a different platform (JStamp for example). Most embedded systems require cross-compilers, so this is a concept familiar to anyone who has done embedded system development. You cross compile by using the javac "bootclasspath" and "classpath" options, but more on that later.

1. Do not build with default J2SE runtime libraries, use only the appropriate embedded runtime libraries. Including J2SE libraries will lead to puzzling errors in JemBuilder or runtime exceptions.
2. Use the javac "target 1.1" option
3. Use the javac "source 1.3" option if you are using J2SE 5.0 or later
4. Use Ant build files, or some other way to "clean" your output folders (delete .class and other compiler output) at the start of each build. This saves you from ever getting a build which is a mix of old and new class files.