Posts Tagged ‘java’

C you again

Wednesday, April 7th, 2010

I was on a conference call today and someone mentioned that C has regained its place as the industry’s most popular programming language. I couldn’t believe it, after all Java has ruled the #1 spot for the last four years.

A quick check on the TIOBE index showed this to be true:

April 2010 Language League

The explanation they give is not that C is growing but that Java is declining. So what does this mean for the industry? Is Java dying? Is there another contender for the top spot gradually working its way up the ladder?

The one thing that stands out is that C is a good language to know. It’s been around a while and it’s not going anywhere in a hurry. I wonder if they’re still teaching it at college and university :)

Bookmark and Share

Make WAR not love

Friday, February 12th, 2010

I’ve been testing a tool that manipulates Java web application archives (WARs) – but it’s a challenge to ensure I’ve got a representative cross-section of real-life WARs to test against.  So far, I’ve been hunting for samples and coding up my own WARs – convolving the Java specifications with common patterns I’ve seen recommended on developer forums. It’s a shame there doesn’t seem to be a repository out there of a broad range of samples for me to deploy to my application server and test the tool against.

Unless anyone’s aware of anything different…?

Bookmark and Share

Communicating in coffee

Friday, November 20th, 2009

I was looking for a quick and simple way of passing a Java object between two Java programs with a wire connection between.

My first thought was object serialization. The problem with this mechanism is that it’s very brittle (change an object on one side and not the other and it goes bang!!). Also, it only really works if you have control of the JVM levels on either side. Which in this case I did, but if I was to share the code with others then they might not be in the same position.

I next considered what XML utilities were packed with the latest JVMs. This led me to JAXB. It seemed an ideal solution. Though it did imply that I either had to start from some XSD, or I had to correctly annotate the classes that I wanted to encode. This seemed a bit more overhead than what I was after.

Obviously there are other solutions… Web Services, 3rd party XML / JSON tools. But again, the consideration around overhead and also the hassle of downloading 3rd party libraries turned me away. After all, I’m just after a quick and simple solution for what is a basic application.

In sMash I would have used some of the great JSON / XML libraries that are supplied out of the box. But I’m not using sMash this time, so I need to look at what’s supplied in the Java class library.

After chatting with a colleague I found the answer.

He recommended I use the java.beans.XMLEncoder & java.beans.XMLDecoder classes. After a bit of fiddling with Input/Output streams I created some utility methods that allow me to make a single call to these services. They encode / decode any Java object that follows the Java Beans specification i.e. it has a zero arguments constructor and getter / setter methods for all variables in the class.

I have pasted the utility methods here for your convenience. Note, because I am running this code on the mainframe I need to explictly request that the bytes be returned in UTF-8 format.

public static String getXMLFromObject(Object object)
{
final ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
final XMLEncoder            encoder      = new XMLEncoder(outputStream);

String result = null;

encoder.writeObject(object);
encoder.close();

try { result = new String(outputStream.toByteArray(), "UTF-8"); }
catch (UnsupportedEncodingException e) { e.printStackTrace(); }

return result;
}
public static Object getObjectFromXML(String xml)
{
Object result = null;
try
{
final ByteArrayInputStream inputStream = new ByteArrayInputStream(xml.trim().getBytes("UTF-8"));

XMLDecoder decoder = new XMLDecoder(inputStream);

result = decoder.readObject();

decoder.close();
}
catch (UnsupportedEncodingException e) { e.printStackTrace(); }
return result;
}

(apologies for the dodgy formatting. It comes out ok on the editor screen)

Bookmark and Share

Feeling not so groovy

Sunday, December 14th, 2008

In my previous post, I mentioned I’ve started writing some scripts in Groovy. All was well until I wanted to persist data between tasks using JSON. The plan is to have a cron job that extracts data from a source and encodes it in a JSON file. I’ll then have a Project Zero application providing a service which when invoked would load the JSON data and return a summary of the data.

The good news… Project Zero has excellent built in JSON support through the zero.json.Json.decode and zero.json.Json.encode methods – which are amazing powerful and simple.

The bad news… When it comes to command line Groovy from groovy.codehaus.org, there doesn’t appear to be any built in support – bah!

So, using Groovy’s ability to use work with standard Java classes I trawled around for a Java JSON implementation. There’s a bunch listed on the www.json.org page, but having looked at a few none of them appear to be as simple as the Project Zero version.

The one that stood out was json-lib.sourceforge.net, but the number of dependencies it has on jars that have to be downloaded from external projects is mind boggling.

I tried importing the Project Zero jar files into my project to see if I could use the libraries they supply. But I soon discovered that it relies heavily on a running Project Zero environment. So no luck there either.

Surely it can’t be this difficult to have some simple JSON utility functions in Groovy. Right now I’m contemplating writing my own.

Bookmark and Share

println “Hello World”

Thursday, December 4th, 2008

Having spent most of my time testing on the mainframe, I’ve spent little of that time actually writing command lines scripts for tests (other than some Unix System Services work). Now that’s not to say I’m not completely familiar with scripting since my primary work station has been running Linux for a considerable time.

However, recently I needed to a little more advanced scripting on my Linux machine. So it was at this point I thought “which scripting language should I pick up and use?”. Obviously there’s a decent selection to choose from: Perl, Python, Ruby, Groovy, others (including Rexx).

In the end I settled on Groovy due to my years of experience in writing Java applications, plus Project Zero provides Groovy support.

With my first script in mind I set down to write and learn on the fly. After getting my head around the new syntax I found myself making progress. Also it’s quite nice being able to drop down to the Java syntax and use utility classes that you know to exist and are already familiar with. I know I’m not writing the prettiest Groovy code at the moment, but the way I see it is scripting languages are there for getting things done. And in one afternoon I picked up Groovy, installed the Eclipse plugin for it, and created a working script to do exactly what I needed. I was happy.

I have this niggling thought though… if I get in to Groovy, will it confuse the hell out of me when I go back to pure Java?

Bookmark and Share