Win7 Calc is cool!

Having recently upgraded Vista to Win7 I didn't notice firstly that Calc.exe has been renovated significantly. Now there are four different calculator types - Standard, Scientific, Programmer, and Statistics. Plus there are new panels for unit conversion and date calculations.

Idea of a litmus test for the company that hires you

I suspect this might be a good question to raise on an interview with any potential employer in software engineering industry: "With regard to the engineering you do when creating your product(s), if you were a car manufacturer what kind of car make would you match your whole production line with - AvtoVAZ, Toyota, Ferrari?". The list, of course, can vary to contain names known to the other party but the idea would still be the same.

I see no other way to quickly reveal how significant and relevant the tools and technologies employed by the company are. Sometimes they might tell you they use Perforce but then it appears they don't use branches and store compiled binaries in it for some wierd reason. Sometimes they claim to use Continuous Integration system but then you find out they don't write unit-tests so it makes using of CI close to sheer nonsense. Or, even worse, they do write unit-tests but without assertions. Some mention they are Agile but meaning by that things are in total mess and uncontrolled. Think for some time and I bet you will be able to find your own examples of such lies.

It is just a rough guess, yet I hope it is on the right track.

Integer.valueOf(): a few facts

Integer.valueOf(int x) added since Java 1.5 has one interesting feature - it resolves all incoming int values through a cache so to minimize the number of java.lang.Integer instances in application by re-using the cached values. This cache is also configurable with a system property java.lang.Integer.IntegerCache.high which is used to define the upper bound to populate the cache to. The minimum value is hard-coded and it is -128.

Surprisingly the upper bound for java.lang.Long, where a similar cache also exist, is hard-coded to 127 and is not at all configurable.

Entity metadata: Java vs XML

The architecture of the last multi-tier project I worked for included a bunch of C# frontends connecting to a few Java services. There were a number of business domain entities. The state of almost every entity was continuously mutated.

Gory details of java.lang.String interning

While exploring through the JDK source code today I came to some degree of understanding of how interned strings are treated by garbage collector (GC).

In the first versions of java interned strings were not collected at all. They were accumulated in the PermGen so it was quite possible to very quickly end up with OutOfMemory (OOM) exception when abusing intern() call. The current version of JVM uses a smarter way to maintain the string cache.

Opposed to some people saying that strings are kept as weak references the actual approach is different. During the first part of mark-and-sweep phase GC delegates to the static string table (a specialization of Hashtable) to get rid of all non-alive entries. These entries are not deleted but relinked instead from the hashtable bucket (the linked list they reside in) to the linked list of free entries (revise

   BasicHashtable::free_entry(BasicHashtableEntry* entry)← 
   void Hashtable::unlink(BoolObjectClosure* is_alive)←
   StringTable::unlink(BoolObjectClosure* cl)

call chain for details)
One important observation here is that memory taken by a freed entry is not deallocated. That means the more non-identical strings are interned by the application the more PermGen memory is consumed. Correspondingly if the JVM string table is too intensively used, for example, by attempting to cache too many non-identical strings it is easy to cause OOME. While in a case where the cached strings are known to have big percentage of duplicates interning along with fine tuning of PermGen may significantly reduce the overall memory consumption.

Tribute to C++

It's been a long time since I last did anything in c++. After many years with Java and C# I don't really feel like fiddling with tons of headers and source files without a really good fast navigation between the types, methods, etc. One of the biggest advantages of Java/C# is that declaration and implementation are combined in one source file. That greatly simplifies navigation and refactoring (unless, of course, the application is designed that badly that it stops you from making any changes in a reliable fashion).
However, the knowledge of C++ still appears to be extremely helpful, for instance, when I need to clarify some details of JVM operation. Every time a question comes for which there is no good answer readily available (e.g. does JVM really apply any optimizations to final methods?) I'd better dig into JVM source code rather than wasting my time on reading many controversial opinions on the question. After all it is just a waste of time trying to understand who's right, who's wrong. So usually a better option is to make it certain by yourself.

P.S. JVM does apply optimizations to a final method. For example, see Parse::optimize_inlining(), ciMethod::find_monomorphic_target(), methodOopDesc::can_be_statically_bound() methods (JDK6-6u18 sources). And understanding if these optimizations may really boost your application performance is best assessed with testing. That's the only reliable approach.

A hint for indenting with XMLStreamWriter

Default implementation of javax.xml.stream.XMLStreamWriter does not support such output features as indentation and multi-line output. Correspondingly the resulting text is always a long one-line string which many of us would want to format in a pretty style for better reading. There is a solution bundled with Java 6 although it is sort of internal Sun facility which may have gone one beautiful day.:-) The class is named com.sun.xml.internal.txw2.output.IndentingXMLStreamWriter, it is public, and it resides in rt.jar. Using it is a matter of couple of lines in your code:

        final XMLStreamWriter defaultWriter =
            XMLOutputFactory.newInstance().createXMLStreamWriter(writer);
        final IndentingXMLStreamWriter sw = new IndentingXMLStreamWriter(defaultWriter);
        sw.setIndentStep("    ");

As shown above it allows you to vary the indent character sequence giving certain flexibility by that.
The only problem I can think of might be due to the end-of-line character internally hard-coded by '\n'. I would prefer having system-dependent or, better, a user-provided line terminator instead.
P.S. Just discovered that this class is only included into JRE not into JDK. That means one sure way to solve the original problem is to duplicate the class source in your application. There is nothing special in its logic as it routinely decorates an instance of XMLStreamWriter with the required functionality. The source code for JDK 6 can be downloaded from this page.