By David J. Barnes published by Pearson
Click here to view this on Amazon.co.uk
Click here to view this on Amazon.co.uk
I’ve always felt that XML processing in Java is overly complex. Surely something that so many business applications need to do on a regular basis should be simpler and easier by now.
Recently I needed to get access to the raw XML being retrieved in this case from an Amazon Web Service for two reasons. Our application needed to store the raw XML into a database for caching and audit purposes. The other reason was so that we could look at the raw XML to research some corner case issues when the data we received wasn’t quite what we were expecting.
Have done a:
Document doc = db.parse(requestUrl);
You would have thought that Document would have a method along the lines of
RawXML = doc.getRawMessage();
It’s at that point that you really start to question why something so obvious and so simple is missing from standard Java libraries. I did some Googling around and found lots of people asking similar questions. The solution isn’t difficult it’s just unbelievably clumsy.
Basically what I do now is to read my XML source into a string. Once it’s in a String I can do whatever I need with it. For some reason DocumentBuilder.parse doesn’t have a version that accepts a String. You therefore have to use your String to create an InputStream that you can then pass to Parse.
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newDocumentBuilder(); // Fetch the XML into a string URL myURL = new URL(requestUrl); InputStream myInputStream = myURL.openStream(); Scanner myScanner = new Scanner(myInputStream, "UTF-8"); myScanner.useDelimiter("\\A"); String myRawXMLRequest = myScanner.next(); myInputStream.close(); myScanner.close(); // Output the Raw XML Request to prove we have access to it System.out.println(myRawXMLRequest); // Now instead of passing the RequestURL directly to the parser we // wrap the Raw XML String in a new Input Stream and pass that into the Parser. // Old code was: // Document doc = db.parse(requestUrl); // New code: Document doc = db.parse(new InputSource(new StringReader(myRawXMLRequest)));
After downloading Eclipse (Luna 4.4.2) on Max OS X 10.10.3 Yosemite it failed to start-up. It gave the highly misleading error message To open “eclipse” you need to install the legacy Java SE 6 runtime.
Installing Java 6 isn’t a good idea. It’s out of support and now has a number of serious security issues. Common sense says there has to be a better solution.
Try going to the OS X Command line and enter the command java -version
In my case then displayed the message, To use the “java” command-line tool you need to install a JDK.
Note that it’s asking you to install a JDK. I knew I had the latest version of Java runtime (JRE) installed so had expected the Java -version command to display Java 8. Clicking on More info will take you through to the Oracle Java download site.
From here download the Mac OS X 64 bit JDK and then when the download has completed click on the dmg file in the download loads directory and follow the install instructions.
Once complete try the Java -version command again from the command line to prove the install has been successful. In my case this came back with:
java version “1.8.0_45”
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Now clicking on the Eclipse icon will successfully launch Eclipse.
To prove it here’s the Eclipse About box to show Eclipse Luna 4.4.2 successfully running on OS X 10.10.3.
Update: June 19th 2016:
A recent update broke the above solution. I hadn’t used Eclipse on the affected Mac for a few weeks so I’m not sure if it was broken by a Java update, an OSX update or even an Eclipse update. Anyway the solution was a simple extension of the above steps.
Find your eclipse.app and CTRL right click on it, you will then see a ‘Show Package Contents’ option
Now navigate to the eclipse.ini shown below:
Now edit eclipse.ini and look for the highlighted line:
Shown above is the correct setting for my Mac that now works. I’ve seen this incorrectly set to either the wrong location or even to a specific Java patch level. If you’ve got a different location under -vm make a note or backup and then try changing it to this more standard value.
If you have any problems or follow-up questions do please leave a comment below.
I recently received updated VPN software from a client. I’d been using their previous GBAuth.jar quite happily for a number of years on my Mac but after installing the new version it just failed to work at all. Double clicking on the GBAuth.Jar file to run it and the Mac would think about it for a moment and then do nothing. Not a single error message, just nothing. I keep my Mac up to date with all the latest patches so I knew I had the latest version of Java installed – or so I thought. What I’d forgotten is that Apple only maintain Java version 6 if you want Java 7 or above you have to download it from Oracle.
Before I went to all the trouble of downloading and installing Java 7 from Oracle I wanted to check the version of Java used to build the old and new versions of the Jar file. There are Jar file viewers but the easiest way for non-Java developers is simply to rename the jar file so it has a .zip extension, e.g. rename GBAuth.jar to GBAuth.zip. You can then double click on it and have OSX expand the zip file. Within the root of this zip file you’ll find the Java Jar manifest.
You can right click on the MANIFEST.MF file and open it with a text editor.
As you can see the new Jar file was actually created by Java 1.7.0-b18 so I couldn’t really expect it to work on my Java 6 installation on my Mac. Just to prove this was the issue I looked at the old Jar file….
So this proved that the previous version of the Jar had been compiled with an earlier Java version.
I then downloaded and installed Java 7 for the Mac from the Oracle site and the Jar file worked perfectly. In all of this I was only really surprised that double clicking a Jar file built under a previous version of Java just caused it to failed to run silently without any error message or assistance. It’s not a great consumer experience.