JBuilder migration by hand
This is for the hard core coders out there. This is unlikely to appeal if you are not a java developer or designer.
I thought I would share this as it has taken me a few days of work to find this method. Hopefully it will save someone some time somewhere in the world 🙂
I have inherited a project which was working beautifully but as the team migrated from Java 1.6 to 1.8 (some call this migration from Java 6 to Java 8), I found we needed to rebuild (and re-link) some of the classes.
The project was originally built on a Windows 2000 machine, running Borland’s JBuilder.
To say everything else has moved on is putting it mildly.
So the choices were:
- Try to get JBuilder updated on a later machine and linked to a Java 1.8 JRE
- Bite the bullet and move everything to Eclipse
Obviously, choice 2 makes sense on so many levels!
But Eclipse and JBuilder are two completely different approaches in terms of how their IDE’s (integrated development environments) deal with the whole concept of a class and a project and I don’t mean in terms of just layout on the screen.
What’s all the fuss, don’t you just read the design document or read the build files?
Modern coding practices (Martin Fowler et al. thank you for your contribution to this profession) dictate that most coders don’t have to deal with this kind of low level detail very often. We make concious decisions on standards and methodologies and paradigms early in a project and stick to them for the life of the project.
Only 3 things ever interrupt the smooth running of a successful: changes to your company or structure means you have completely contradictory approaches to the factoring of your software, your team needs to start saving money sooner rather than later, Microsoft (or the producer of your IDE) have stop supporting the build of the OS you have either designed for or build against.
In the 15 years or so since Microsoft Windows 2000 was first marketed much has changed. No least the adoption of Eclipse, produced by IBM, as a free and reasonably competent IDE.
I have to be honest at this point and mention that Eclipse was one of the last IDEs I ever used, in fact, deployment issues when using Eclipse in 2006 meant I took up hand building all my java :>
Not a fan?
That was 9 years ago.
Back to JBuilder. JBuilder uses the idea of nodes to allow the dependencies between Java classes and the build/sub-project structure to coexist in relatively complex projects.
The situation I found myself in was a build script which launched JBuilder and it used a project file with more than 13 outputs and 250 odd classes. Time for a stiff upper lip and some serious consideration.
Normally, as I use Linux to build my Java output, I make use of the fact that any .jar file is in fact a tarball or a group of files concatenated together into a continuous file. As such, I can go and list the contents: if my jar binary is not up the job, I can fall back on to tar. Job done.
Guessing not that straight forward, huh?
No. Windows does offer a few useful tools though. Directory and file compression was included by default in Windows 2008. By taking x.jar and renaming it x.zip, I could at least examine what the successful build looked like.
So, I did this with the original.jar -> original.zip and unzipped into a directory called original.
I made a complete build new.jar -> new.zip and unzipped into a directory called new.
Now, original was a subset of new by definition: remember 13 jars were produced from 250 classes. How do I identify what I didn’t need?
In Unix, I could use sdiff to compare each directory. So that was my search on a search engine of your choice (thanks Google).
$one = Get-ChildItem -Recurse -path C:\original\$args[0]
$two = Get-ChildItem -Recurse -path C:\new\$args[0]
Compare-Object -ReferenceObject $one -DifferenceObject $two
This tells me which files exist in my new directory that I don’t want. I use that to format a jar build script including exactly what I need for each output jar in question.
Most importantly, I have a means of not only repeatedly building the Java 1.x library but also of checking against previous builds.
Job done ✓.
Posted: December 26th, 2015 under 42, Programming.
Comment from Sam J Watkins
Time December 26, 2015 at 9:42 pm
This was not all my own work, a colleague pointed out the tarball reminded me how to achieve that in Windows.
I did try making an Ant build.xml with Eclipse but the complexity of the original structure of the project meant I wasted the best part of a day trying to get that working while this approach was a couple of hours.