Subscribe to Jack of all Languages        RSS Feed
-----

Total Eclipse

Icon 7 Comments
Today there was a near-total eclipse. Glasgow was overcast and the only evidence was a slight darkness. Just as we thought we were going to miss it the maximum-eclipse (or thereabouts) struggled through, pale and moon-like through a veil of cloud. Then a few minutes later we caught a brighter glimpse.

But this article is about Eclipse the Java IDE or rather my reliance on it.

A couple of weeks ago I posted a strong opinion that the text editor should be a triviality, entirely decoupled from the project, easily replaced on a whim. I put my own practice to the test by not using Eclipse for at least a day.

The first thing I would have to sort out is compiling and running my program. I consider myself proficient in Java so it should be no problem, right? Wrong! After a while playing about with various switches and options, it became clear I had bitten off too much. It was time to follow my own advice and simplify things. I wrote a Hello World program, compiled it, ran it. Easy. I took baby steps building up the complexity of the script until I eventually had something that compiled my java files and ran all the tests. Here are the baby steps:

  • Compile and run Hello World.
  • Specify an output folder for class files.
  • Add a JUnit test to HelloWorld.java.
  • Move HelloWorld.java to a package in my application.
  • Add a class from my application.
  • Add a test suite that knows which classes to run.
  • Add classes individually (up to about ten), testing the build after each.
  • Add all the libraries I need to the classpath.
  • Delete all the existing class files before compilation.


At this point, I had a working build script but every java file was declared explicitly. Javac expands wildcards (but not recursively) so I was able to replace a list of Java files with a much shorter list of directories. Later that was replaced that with a call to the Linux command find, to find all the Java files.

The test suite was more of a problem. I spent a long time googling how to automatically find and run all tests. The long and short of it is JUnit doesn't have this built in, and it's difficult to find all your own classes with reflection. Libraries exist but I'd rather not add another dependency. I've left it as a hard-coded list of classes. When it gets too annoying I'll write a shell script to auto-generate the class list.

Here's the build script in all its glory. I think it's pretty nice and simple for what it does.

set -e
ClassPath=bin/:lib/*
JavaFiles=`find java/ -name '*.java' -printf '%p '`

rm -R --force bin/*
javac -cp $ClassPath -d bin/ $JavaFiles 
java -cp $ClassPath org.junit.runner.JUnitCore cfoley.AllTests


And here's a description of each line:

set -e
Tells BASH to stop running the script if any command fails (i.e. a non-zero exit code)

ClassPath=bin/:lib/*
puts my classpath in a variable. It's just the bin and lib directories.

JavaFiles=`find java/ -name '*.java' -printf '%p '`
Puts a list of all the Java files in a variable. This is the ugliest part of the script and I'd like to replace it with something simpler.

rm -R --force bin/*
Cleans the project by deleting all the old class files.

javac -cp $ClassPath -d bin/ $JavaFiles
Compiles all the java files, putting the class files in the bin folder.

java -cp $ClassPath org.junit.runner.JUnitCore cfoley.AllTests
Runs my test suite

A Java developer might wonder why I didn't use Ant or Maven. Freeing the project from an IDE only to shackle it to another tool would be an ironic solution. Ant and Maven do offer other benefits so if the project grows in scope it may be worth making the switch. For now the JDK and the shell do everything I need.

Final thoughts: It was a lot of effort to write this build script but it will be easier next time. I even think that growing a build script alongside the project could be simpler than fiddling with the build path in Eclipse. Even better, I can now easily use any text editor I want which was the original goal of this exercise.

7 Comments On This Entry

Page 1 of 1

jon.kiparsky Icon

20 March 2015 - 10:55 AM

Quote

Freeing the project from an IDE only to shackle it to another tool would be an ironic solution.


Well, no more so than writing your own little tool and shackling it to that...
1

BBeck Icon

20 March 2015 - 11:24 AM
I thought we were gonna talk astronomy. :-(

signed,
Not a Java Guy ;-)
1

cfoley Icon

20 March 2015 - 04:43 PM

jon.kiparsky, on 20 March 2015 - 05:55 PM, said:

Quote

Freeing the project from an IDE only to shackle it to another tool would be an ironic solution.


Well, no more so than writing your own little tool and shackling it to that...


I see it less making my own tool and more using the tools provided in the JVM. One distinction is that my script is not a general solution. It's more or less what I would type on the command line to compile and test this project.
0

cfoley Icon

20 March 2015 - 04:45 PM

BBeck, on 20 March 2015 - 06:24 PM, said:

I thought we were gonna talk astronomy. :-(

signed,
Not a Java Guy ;-)


My apologies. For what it's worth the solar eclipse was fun to watch, although the sky wasn't as clear as the one we had in 1999.
0

jon.kiparsky Icon

20 March 2015 - 07:48 PM

cfoley, on 20 March 2015 - 06:43 PM, said:

I see it less making my own tool and more using the tools provided in the JVM. One distinction is that my script is not a general solution. It's more or less what I would type on the command line to compile and test this project.


Still, what you're doing is in fact writing a little tool that will manage compilation for you. And I think you'll find that if it's ever deployed in anger, you'll quickly start adding in the flexibility and generality that it lacks at the moment. That's how software grows, isn't it?

I guess this sounds like quibbling, but I honestly don't see why it seemed necessary to you to reinvent this particular wheel in this case. Can you clarify your thinking on this?
1

cfoley Icon

21 March 2015 - 04:48 PM
Sure. I thought it would be easy to compile my code with javac. It wasn't so I wanted to work it out.
0

GWatt Icon

21 March 2015 - 11:03 PM
I've been in a similar situation, though in my case it was that I hated eclipse's build systems so I wrote a makefile to build my project. I found it easier to deal with.
Unfortunately, when I had to work on a new version with a different build setup I never did make a Makefile for it.
PKG := project
DEPDIR :=
SRCFILES := $(shell find src -name '*.java')
BINFILES := $(SRCFILE:.java=.class)
JARS := $(shell find $(DEPDIR) -name '*.jar' -print0 | tr \\0 :)
JFLAGS :=

$(PKG).jar: $(BINFILES)
        jar cfm $@ manifest.txt -C bin $(PKG) $(BINFILES)

bin/%.class: src/%.java
        @mkdir -p bin
        javac -sp src -cp $(JARS) -d bin $<

clean:
        rm -rf bin $(PKG).jar

1
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

December 2017

S M T W T F S
     12
3456789
101112 13 141516
17181920212223
24252627282930
31      

Tags

    Recent Entries

    Recent Comments

    Search My Blog

    0 user(s) viewing

    0 Guests
    0 member(s)
    0 anonymous member(s)

    Categories