Letters to the Editor

Markus, I tend to detail simple pre- and post-conditions for method parameters (a simple form of Design-by-Contract, if you will) to make better use of my own Javadoc comments. For example, "[may not be null]" for a parameter usually indicates that it is illegal to pass a null object reference as the parameter value (the method will throw an IllegalArgumentException), and "[never null]" for the return value usually indicates that the method guarantees that it will never return null. Those are just elements of my personal coding style. Feel free to ignore them and change the code to suit your own conventions. In regards to your second question, declaring cls final is not necessary. Declaring method parameters (or local variables) final makes them constant in the sense that values of primitive types cannot be changed post initialization time (or after method entry), and values that are object references cannot be reassigned within the method. This const-ness is enforced by the compiler. getClassLocation() will function as before if you remove final from its parameter declarartion. Again, this is an element of my personal coding style. Since I have no need to change cls inside the method, why not make it final? I always start with declaring method parameters and local variables as final and undo that only if I truly need to reassign their values later on. This habit comes from the C++ language, which has a much more powerful and useful paradigm of const-correctness. This coding style has nothing to do with performance but rather helps me avoid copy-and-paste and other common types of mistakes. Vladimir Roubtsov Editor's note: See Vladimir's current Java Q&A for more on Class.

Rafael, I am unaware of any Java Specification Requests (JSRs) or other plans to enhance the JVM architecture to support secure encrypted class deployment. For now, if protecting your intellectual property is paramount to your work, I think using a well-tested commercial obfuscator is your best option. As far as I know, other managed runtime/byte code-based architectures (like .Net) suffer from the same problem. Vladimir Roubtsov