Compare JAR files content; decompiling class files

When I was recently working on a large restructuring and refactoring where I also replaced Ant by Maven, it was really necessary to compare the complete content of two¬†different JAR files. It was required to know that the result of the restructuring and refactoring hadn’t changed the artifacts, thus the JAR files.
In the JAR files were different Class files present. When I compared the content of the two JAR files (with a binary compare) all the content was radically changed. This was partly because the compiler compiled the Class files at a different timestamp.

Since I wanted the best possible comparison between the two JAR files I needed to compare all Class files in the JAR by decompiling and comparing. This should give me a clearer and more honest picture of the differences. For this action I used Beyond Compare. By using an additional File Format (Java Class to Source) I was able to completely compare the decompiled Class files of the two JARS.

If you ever need to compare JAR, WAR or EAR files and need to compare the Class files inside; don’t try to unpack to a folder, decompile to a different folder and finally folder compare. You should use Beyond Compare and save time on comparing. The Beyond Compare license will pay itself off.

Using URL Scheme for Telephone Numbers in HTML

We can use the tel: URL scheme for phone numbers in HTML. Just like the mailto: URL scheme will open the default mail application will the tel: start a telephone call. If the HTML page is viewed on a mobile phone and we select a link with the tel: scheme we can immediately call the number following the scheme. On a desktop computer a VOIP call will be initiated.

We can use hyphens in the phone number for readability, they will be ignored when the call is made. For example the imaginary phone number 123456789 in the Netherlands can be used as shown in the following HTML snippet:

More information is available at http://www.ietf.org/rfc/rfc3966.txt.

Original post

javax.xml.bind.JAXBException: “package” doesn’t contain ObjectFactory.class or jaxb.index

Once in a while we have those small issues which still can take some hours of our day. For example last week I was configuring a Spring JAXB2Marshaller using the context below:

<bean id="jaxb2Marshaller">
<property name="contextPaths">
<list value-type="java.lang.String">
<value>nl.jdriven.myproject.package.with.a.very.long.name
</value>
<value>nl.jdriven.myproject</value>
</list>
</property>
</bean>

However when running my JUnit test using this context the following exception occurred:

It look liked something was wrong with my generated JAXB project. Unfortunately I needed some hours to notice that maybe the break line in the value element of the contextPathslist could cause the issue

After changing the spring-context.xml as below, moving the </value> tag inline, the JAXB2Marshaller worked perfectly.

<bean id="jaxb2Marshaller">
<property name="contextPaths">
<list value-type="java.lang.String">
<value>nl.jdriven.myproject.package.with.a.very.long.name</value>
<value>nl.jdriven.myproject</value>
</list>
</property>
</bean>

Apparently the spring-context is sensitive to break lines when we configure the Jaxb2Marshaller context paths. Due to my habit of using the Eclipse format shortcut Ctrl + Shift + F the formatter kept moving the end tag of the context path to a newline.

We can prevent this issue by changing the settings of your Eclipse XML editor settings. In your Eclipse click Window -> Preferences -> XML -> Editor and set the line width to e.g. 140.

The Quick & Dirty Fraud

If you have a car, then every once in a while, you probably have your vehicle checked to see if it’s still up to safety and environmental standards.

So you take your car to the garage and have it checked. Now, the garage will do some tests and eventually you’ll get a nice paper showing what kind of maintenance they have done.

Nowadays, cars are complex, computerized machines. (The days of dad lying under the car to do some fixing with some elemental tools are all but gone.) This means that as a customer, you will have to rely on the professional capabilities and integrity of the garage. You’ll have to trust that if the garage says the car is fixed and okay, it really is fixed and okay.

Now imagine that you went to the garage, received the paper that your car is okay, go on the road, and your car breaks down. What would be your reaction? You’d probably hold the garage responsible for this, as they are the experts and you paid them to do a good job. What would your reaction be if they told you that they didn’t have time to correctly solve your cars problems and did a ‘quick fix’, without them telling you?

In software development I frequently come across similar situations. Companies hire in IT solution providers, to help them solve their IT related problems and deliver high quality solutions for their business. Now software products and projects tend to be very complex and therefore, customers will, one way or another, have to rely on the professional capabilities and integrity of the solutions provider (or the solutions provider, checking the solutions provider).

How then would we label deliberate quick ‘n dirty fixes by developers, just to get the project ‘done’, leaving the customer with piles of technical debt?

It is the responsibility of solutions providers and professional developers, to point out the consequences of quick ‘n dirt fixes. A good solutions provider therefore will, out of professional honor and integrity, have the courage to point out the severe consequences and even refuse quick ‘n dirty fixes, knowing that in the end, low quality won’t pay off.

Quality isn’t negotiable and long after the ‘quick’ has been forgotten, the ‘dirty’ will probably still be there.

Original article