Java

I came to conclusion that even in fully-Scala projects it’s better to define enums using Java. Even third-party libraries that have support for Scala enums suffer from the fact that in runtime all Scala enums have the same type. So if you get some enum value - you have no way to tell to which enum type does it belong. Let me show you how bad it can be with json4s.

Just discovered weird behavior of Scala's protected methods: they're actually compiled to public methods in byte-code. Therefore if you try to override them in Java code with another protected method compilation will fail with something like this: "attempting to assign weaker access privileges; was public". After some googling I've discovered that other people also spotted this issue. I think such weird compiler behavior was needed because of access level mismatch in Scala and Java - but I thought that Scala's protected is more restrictive then Java's.

Turned out that error "org.postgresql.util.PSQLException: Multiple ResultSets were returned by the query" may be caused by semicolon (;) in the end of the query when working with Postgres via JDBC

Peculiar thing about HQL subquerries - at least in Hibernate 4.1: if you use alias in subquery, it refers to the whole table, not just to its subset that is related with main query. For example - suppose that entity Bar has integer field idx and we'd like to get Bar with minimal idx for each Foo. This query will produce WRONG result: SELECT Foo FROM Foo f JOIN f.bar b

Suppose we have list of objects and we want to marshal them via JAXB: ... @XmlElement(name = "value") public List<Object> getValues() { return values; } ... By default this would produce following output: ... <value xsi:type="xs:int" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema">123</value> <value xsi:type="xs:boolean" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema">true</value> <value xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema">Lorem ipsum</value> ... Pay attention that standard schema URIs duplicated for each list item - quite inefficient if we have lot of items. This issue can be addressed with package-level annotations.

Recently I had a problem with Spring MVC. My mappings made by @RequestMapping annotations were ignored, but I was sure that annotation processor was picking the bean correctly. It turned out that if you use org.springframework.web.servlet.handler.SimpleUrlHandlerMapping to do some mapping in XML then you need to include DefaultAnnotationHandlerMapping explicitly into your application context: <bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping"/> This is not needed when you have only annotation-based mapping - then  DefaultAnnotationHandlerMapping is included by default.

Suppose you have two classes: public class Foo { private String[] array = (String[]) new Object[]; public static void main() { Foo f = new Foo(); } } public class Bar<T> { private T[] array = (T[]) new T[]; public static void main() { Bar b = new Bar<String>(); } } Will they compile? Will they run? At a first glance it may seem that both make inappropriate casting from superclass Object[] to subclass String[].

I was wondering how efficient addAll() method in Java collections is and looked through the JDK code (Sun/Oracle JDK 1.6.0-27). Here is code for ArrayList.addAll(...): public boolean addAll(Collection<? extends E> c) { Object[] a = c.toArray(); int numNew = a.length; ensureCapacity(size + numNew); // Increments modCount System.arraycopy(a, 0, elementData, size, numNew); size += numNew; return numNew != 0; } So here you can see incomming collection content copied into intermediate array.