Invalid signature file digest for Manifest main attributes

Because of some obvious reasons, security is a must when it comes to computers nowadays. I am not much into security but I had to deal with it anyway. Last couple of days I worked with signed JAR files, when my Java compiler suddenly said: "Invalid signature file digest for Manifest main attributes".

It was because some JAR files were not signed correctly since I needed to remove signatures and my automated tool for signatures removal was broken. Fine, but which files are in a bad condition? I was not able to make my compiler tell me. My class path was like 10kB of text and the day was almost over...

Signatures and certificates in a JAR file are in the META-INF directory. These are files with .SF, .DSA, and .RSA extensions. All one need to do to "unsign" a JAR file is to delete those files. Note that, some information are in MANIFEST.MF as well but it is not necessary to remove them until you want to sign the JAR file again.

It is pretty straight forward so what can be wrong? It was my bad, I assumed that all JAR files in my application use the same certificate file. I did not delete all .RSA files but just something like PRODUCT.RSA.

But it took me a while to realize what is wrong. And here is a command that can help you to recognize a broken JAR file:

find -name *.jar -exec echo {} \; -exec jarsigner -verify {} \;

It is definitely a pity that Java compiler (Sun JDK 1.6) does not print out the problematic file name.

"Always avoid working with tools that have a helve"

My daddy told me, son, always try to avoid working with tools that have a helve. I succeeded, I would say. I do not have to work with such tools. At least not at a daily basis. I work as a software engineer. I work mainly with intellectual property. But sometimes I feel like I am working just because of those tools.

Just imagine your only job was to make a better hammer. I believed that a hammer proved to be optimal over the years. It is a mean of achieving a more complicated result. But all those software engineers working on operating systems or application middleware try to enhance tools for computer users or application developers all day long.

The software engineers use another tools to make tools for you. Those another tools like compiler must have been developed by another engineers. But this is not what I wanted to talk about...

The software engineers tend to think too much about their tools. It is good to know your tool, of course. But it should not be recognizable which tool you used. Usually, you cannot recognize a 9mm chisel trace on a sculpture. You should not design according to the tools you plan to use.

I keep asking myself how difficult is to master a programming language. Is it that easy? Is it just a syntax sugar you need to know? Let's take Java as an example. There are too many pitfalls you must know to understand complicated code clearly - thread local variables, dynamic proxy, anonymous inner classes. You can make sure that you do not know the language perfectly, just google sample questions for the Sun Certified Java Programmer exam.

I started programming in Java around 2001. I was able to develop my applications easily without studying many guides. I did not know almost nothing but the language grammar. Now, almost 10 years later, I feel like I know intuitively 95% of the language (some percents were gained very very hard).

And what now? After all, Java is just a tool. Like a software engineer's hammer. It is definitely less than 1% of my knowledge needed to do my job correctly. So big on one side and so small on the other side. What is the right side?

My biggest dilemma is whether I should ask for language specific details when having an interview with a possible new employee at my company. Or should I ask more sophisticated questions? "What are basic properties of each transaction?" or "What is an application server?". And what about assembler? Everything that works need assembler!

Fancy technologies

What makes technologies look good for the first sight? Is it a great demo showing an easy-to-implement solution? What makes you to choose a given technology? A nice graphics, open source, wide community?

Well, I have major interest in Java related technologies so my opinion may be skewed by that. Recently, I felt for some technology (let's call it Technology X) and I chose it for my project. It has the following attributes that I appreciated (not in any particular order):

• open source
• active community
• fancy demos
• great ratio of source lines/work done
• supporting tools
• usable documentation
• some books by known authors exist
• fresh post "bleeding edge" technology

Especially the last attribute was a problem. I usually wait several months before upgrading my Linux distribution to hear from the community about major problems. I waited for a year after relatively wide adoption of Technology X. Obviously it was not enough and my decision proved to be a big mistake.

What might look fancy at the beginning could become a real nightmare. My problem was that Technology X was well prepared for many standard usage scenarios keeping the above list of attributes valid. When I started looking at some specific problems I got into a trouble. And what makes your project exceptional? A specific behavior that nobody else has, in my opinion.

To make the long story short, I ended up dwelling in the Technology X's source code to realize that there are well-known bugs and design flaws that were blockers to my project.

What makes me think of this story was another blog post of a new superb glorious Technology Y that can become a panacea to your projects. As a proof of all the positive features authors demonstrated a Getting started example of nothing too fancy, but enough to give you an idea of...

But realistically, it is possible that later the authors abandon the project and no other blog will be published. It is not likely to see a blog post describing what is not possible with Technology Y. So please, before you write a Getting started blog/article, always make sure that you have tried advanced features of that technology as well.

Eventually, I used Technology Z for my project. It was a complete restart of the development phase. This time I was more cautious. I realized that with the right technology I can start doing some real work early in the technology studying phase. The documentation is precise, yet relatively short. Technology Z has a great support in my favorite IDE. I have control of what and how is done - the technology is flexible in allowing me to choose an appropriate level of granularity in different parts of my project depending on my goals.

I couldn't believe it. Technology Z offers me the same functionality as Technology X. I do not have to write any significantly bigger amount of code or configuration files. I can implement new features in my project in approximately 20% of the original time needed with Technology X. Long live Technology Z.