Roy's musings

Some time back a friend asked me an algorithm question: Given an integer random number generator randomN() that can generate random number in the range [0, N), how will you generate random numbers in the range [0, M) where M I used modulo arithmetic to generate the desired random numbers in the range [0, M). And I reasoned out that if N = q*M + r, every number in the range [0, r] has an occurrence probability of (q+1)/N, but the numbers in the range [r+1, M) has an occurrence probability of only q/N. It is easy to visualize this. See the diagram below: You can see that we can divide line of length N units (given in green) by lines of length M units (given in black). When N is not exactly divisible by M, in the last part alone we have only r units. So if we choose a random integer in the line represented in green, and then take a modulo M on the value, all the values except the values in the range [r+1, M) (represented in red) will occur q+1 times. But the values in that int...

You might have used Hibernate for your ORM needs. The most important thing that you should about Hibernate cache is that it is implemented using a Map and a reference every entity that you have read from the database is kept in that Map. The key of that Map is the Entity ID (which could be just a Long or some form of composite primary key you have defined and wrapped in an EntityKey ). The value stored is the entity itself (proxied). If you read a 1000 entities (or rows) from the database, a reference to each one of them will be kept in the Map. If those entities have relationships specified (one-to-many or many-to-many) with other entities and those entities should be loaded eagerly, you are asking Hibernate to load a lot more than 1000 entities. If you venture into processing a large set of rows (say 100,000 rows), a reference to every one those rows is going to be kept in the Map. Sometimes the amount of memory needed could be so large that your process might run out of memory ...

If you upgrade JDK to 1.6 update 22 (build 04), the SecretKeyFactory is broken. As a result you will not be able to load any PKCS12 key stores. You will get NoSuchAlgorithmException thrown. I have reported this issue in the bug database. You can view the bug here . I guess it will take upto a day for this bug to be externally visible, if you don't have a SDN account. Here is the sample program to reproduce the issue: public static void main(String[] args) { SecretKeyFactory instance = SecretKeyFactory.getInstance("PBEWithMD5AndDES"); System.out.println("Returned instance: " + instance.getAlgorithm()); } You will get the exception below: Exception in thread "main" java.security.NoSuchAlgorithmException: PBEWithSHA1AndRC2_40 SecretKeyFactory not available at javax.crypto.SecretKeyFactory.<init>(DashoA13*..) at javax.crypto.SecretKeyFactory.getInstance(DashoA13*..) at main.TestClient.main(TestClient.java:96) Work ...

Problem: You are given a byte array, that represents a number in big endian format (the most significant byte first). You have to convert the byte array to its equivalent hex string. What is the most efficient way to do it? Solution: There are many ways to do it. But let us start with the easiest and correct one and optimize our solution. BigInteger class provides a constructor to convert the byte array to a BigInteger. We can convert that BigInteger to a hex string using the BigInteger.toString(radix) method. The solution is given below: public static final String toHexStringUsingBigInteger(byte[] input) { BigInteger bi = new BigInteger(input); return bi.toString(16); } We can also come up with a hand crafted solution that extract nibble by nibble and convert them into their equivalent hex character and finally forming a string. This solution is given below: public static final String toHexStringUsingCharArray(byte input[]) { int i = 0; if (...

Problem: Consider that you want to have a method called "Object invokeAndGet(Object targetObject, String methodName, Object... args)". This method should be able to invoke the given method on the target object and return the value returned by the invocation. If the method has overloaded forms, then depending on the argument types, the invokeAndGet method should invoke the correct form. Solution: Though this problem looks trivial and seems like it can be solved by using reflections APIs, it gets really tricky when you have to deal with primitive types. This is due to the fact that autoboxing converts the primitives into their corresponding wrapper types. For e.g. an integer value is autoboxed into Integer object, etc. To begin with let us assume that we have the following implementation of the method: public static Object invokeAndGet(Object obj, String methodName, Object... args) { try { Class<?>[] argsTypes = new Class[args.length]; ...

Problem: Create an instance of HashMap in Java with entries in it. I don't want to create a new HashMap instance and keep adding entries to it. I want to have a concise way of creating a HashMap with entries. Solution: Guava library comes with factory methods that can create a HashMap without using the verbose form of "Map myMap = new HashMap ()". You can simply say "Map myMap = newHashMap()", assuming you have done a static import of the Maps.newHashMap method. But that is not sufficient. It would be better to provide a utility method that looks like this: "Map myMap = newHashMapWithEntries(firstKey, firstValue, secondKey, secondValue)". That way it is easy to create static-final maps instead of writing a separate method to populate them or to populate them from constructor, as given below: public class MyClass {    private static final Map<String, URL> serviceUrls = createServiceUrlsMap();    private static Map<String, String> cre...

I was browsing through the Linux kernel documentation and came across this excellent documentation on Memory Barriers . I was able to relate many of the concepts explained in this document with the issues that used to exist in the older buggy JVMs. I would strongly recommend to anyone to go through this kernel document to easily understand the 1.5+ Java Memory Model, especially the concept of happens-before ordering. The same author has written another excellent paper "Memory Barriers: a Hardware View for Software Hackers" , which covers the same topic in a bit more depth. Paul McKenney and David Howells - thanks a lot for your excellent document that helped me understand the key concepts behind memory barriers.

Recently I read an article in Artima , titled "Have Generics Killed Java?". This article is not the first one to complain about the complexities introduced into Java due to Generics. I used to a C++ programmer for around 6 years and been a big fan of the language. When I switched to using Java, during the pre-Generics era, I simply loved the simplicity and lucidness of Java. After reading the section on Generics in Effective Java, and having learnt the IFs and BUTs of the Generics, I realized how many things one has to remember to make effective use of Generics. I rememberd an answer given by Bjarne Stroustrup , the creator of C++, a few years before the introduction of Generics. The gist if his answer was that every language commercially successful and used in large scale follows exactly the same path C++ and (now) Java is following. That is to start simple and eventually getting more and more complex. After reading the FAQ for C++0X and some of the modules in Boost lib...

If you are using Cobertrua to get coverage reports, you may run into the error message shown below (lines folded for clarity): Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'myBean' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Initialization of bean failed; nested exception is org.springframework.beans.ConversionNotSupportedException: Failed to convert property value of type '$Proxy28 implementing net.sourceforge.cobertura.coveragedata.HasBeenInstrumented, org.springframework.aop.SpringProxy, org.springframework.aop.framework.Advised' to required type 'com.mydomain.MyDao' for property 'myDao'; nested exception is java.lang.IllegalStateException: Cannot convert value of type [$Proxy28 implementing net.sourceforge.cobertura.coveragedata.HasBeenInstrumented, org.springframework.aop.SpringProxy, org.springframework.aop.framework.Advised] to required type [com.mydomain.MyDao] for ...

There are many instances when I wanted to just log the properties of a given object (most of the time its a bean). This will be useful in two ways: 1) learn about the concrete type of the object 2) serves as a good learning aid to understand what are all the properties that can be get/set in that object. Of course, if you have the documentation and the source code for the class in question, that would be the ultimate aid. Nevertheless, the following piece of code would be useful to print the properties of the given object/bean, using the getter methods that are available in the object.     public static void printProperties(String msg, Object o) {         String className = o.getClass().getName();         if(msg != null && msg.length() > 0)             logger.info("{} (type {})", msg, className);         Method[] methods ...

I use slf4j for logging purposes. All the logging methods (Logger.info, Logger.debug, etc.) provide an efficient way of passing one or two argument objects. For e.g. logger.info("The response from server is [{}]", serverResp); logger.debug("Key [{}], Value [{}].", key, value);  But if you want to pass three or more arguments you have to create an object array yourself and pass. Like this: logger.info("Status [{}], message [{}], time taken [{} ms].", new Object[]{status, msg, timeTaken}); Doing a new everywhere in the code doesn't seem like an elegant way of doing it. I was thinking about a cool way of doing it, and this is what I came up with. Here is a utility method that makes use of varargs: public static Object[] toObjArr(Object... args) {     return args; } In the code we can use this utility function like this. import static com.mydomain.Utils.toObjArr; ...     logger.info("Status [{}], message [{}], time taken [{} ms].", toOb...

Question: What is the most efficient way of creating a collection (Set, List or Map) with a single element? Answer: The most efficient way of creating a collection with a single element would be to make use of the Collections.singletonXXX() methods. Collections.singleton - To create a set that has only one element. Collections.singletonList - To create a list that has only one element. Collections.singletonMap - To crate a map that has only one entry. The collections returned from these methods are immutable. Compare these methods with Collections.unmodifiableXXX() methods. The umodifiableXXX methods already accept a collection as an argument.

I recently learned about Java Native Access (JNA) and was simply amazed at how easy it is to make native calls. I have used JNI earlier in my projects to access native code, but it is a bit painful experience. JNA makes it a bit easier to make those native calls. I haven't experimented much with passing structures and getting structures (or pointers to structures) as return values. As far as the arguments and return types are one of the primitive types, the interface is very easy to define and use. Give it a try, you will like it.

Remember that the Calendar's internal fields include year, month, date, hour, minutes, seconds, milliseconds and time zone. Whenever you are calling a set() method with multiple fields, like set(year, month, date), it will not affect the rest of the fields. Remember that there is no set() method with multiple fields available to set the milliseconds. If you would like to set the milliseconds, you must use set(Calendar.MILLISECOND, value). Likewise, if you are planning to set all the fields, its a good idea to reset all the fields using clear() method. This will clear milliseconds as well. Most of the times, millisecond field may not be of interest to you. But if you are going to use the UTC milliseconds, by calling getTimeInMillis(), then make sure you set the right values for milliseconds as well.

I recently ran into a weird issue. I had to debug a piece of code that I wrote. So I launched the application in Eclipse in debug mode, and set a few break points. Though I can see that the log messages related to all the break points appear in the log, it didn't stop in all the break points. In some break points it stopped and in some other it didn't stop. I checked the output directory, I checked the flags to the compiler, even I downgraded to Ganymede. Nothing seemed to work. When I asked the question in the stackoverflow.com, I got the answer in five minutes . Looks like JDK 1.6 update 14 has an issue with debugging. So upgrading to JDK 1.6 update 16 helped. But still I am seeing the issue occasionally.

If you rely on getting the heap usage by methods provided in Runtime, then consider making use of the MemoryPoolMXBeans. The code to print the memory usage is extremely simple: List mpool = ManagementFactory.getMemoryPoolMXBeans(); for(MemoryPoolMXBean b:mpool) { System.out.println(b.getName() + ": " + b.getUsage()); } You will see something like this when you run this: Code Cache: init = 163840(160K) used = 468672(457K) committed = 491520(480K) max = 33554432(32768K) Eden Space: init = 917504(896K) used = 202792(198K) committed = 917504(896K) max = 4194304(4096K) Survivor Space: init = 65536(64K) used = 0(0K) committed = 65536(64K) max = 458752(448K) Tenured Gen: init = 4194304(4096K) used = 0(0K) committed = 4194304(4096K) max = 61997056(60544K) Perm Gen: init = 12582912(12288K) used = 108360(105K) committed = 12582912(12288K) max = 67108864(65536K) Perm Gen [shared-ro]: init = 8388608(8192K) used = 6162160(6017K) committed = 8388608(8192K) max = 8388...

Recently I had to make use of the JdbcTemplate.batchUpdate() facility in Spring. I was connecting to the Oracle database using Oracle JDBC driver. As per the documentation, the batchUpdate() function is supposted to return an integer array. Each element in the array contains the number of rows affected the respective INSERT/UPDATE/DELETE query in the batch. But during my testing I found that, I was always getting all the elements to be -2. Initially I was thinking it was a bug in the driver code. Then when I was referring to the JDBC Programmers Guide , I figured the following: For a prepared statement batch, it is not possible to know the number of rows affected in the database by each individual statement in the batch. Therefore, all array elements have a value of -2 . According to the JDBC 2.0 specification, a value of -2 indicates that the operation was successful but the number of rows affected is unknown. There are more examples and explonation of error codes in the same page . ...

I came across this article titled "Essential Java Resources" in developerWorks and found out to be useful.

Monitors in Java are in reality mutex + conditional variables. Silly note, but I think understanding this is essential. A theoretical background of monitors could be found in the wiki .

I was getting curious about if its possible to write a Java program that finds if the underlying native platform is little- or big-endian. I guess its not possible to write such a program without having part of the code in C/C++ and using JNI. If anyone reading this blog feels otherwise, please let me know. There is an API available from NIO to find out the native-endian. I think this API should use some native code underneath.