Generics are very useful Java language feature introduced in Java 1.5. Starting from 1.5 you can statically declare expected types of objects inside collections and compiler will enforce this assumption during compilation:
Map<String, BankAccount> bankAccounts = new HashMap<String, BankAccount>();
bankAccounts.put("a1", bankAccount);
bankAccounts.add("a2", "string"); <-- compilation error
Integer x = bankAccounts.get("a1"); <-- compilation error
bankAccounts.put(new Integer("11"), bankAccount); <-- compilation error
Many projects, however, keep 1.4 compatibility mode for many reasons. I think 1.5 is mature enough (ok, let’s say that: old) so it may be used safely.
(more…)
J2EE is a set of Java-based technologies used to build applications accessible over the network. Flexibility and the ability to configure, based mainly on XML files, leads to the fact that more and more errors are beyond the control of the compiler.
Older systems described the interaction between parts of the system directly in the code and as such could you checked (at least partially) in the build phase by compiler. The trend to move this kind of information outside of Java code causes, unfortunately, many configuration errors will not be caught by compiler. Those errors will be visible later, at run time.
The complexity of the J2EE architecture makes the cycle (recompilation, installation, testing in a browser) long. This significantly makes the development method “change and run” harder. What can we do to speed up the process of developing J2EE applications?
(This is a translation of an article I wrote two years ago on static verification).
(more…)
Sometimes you see that Eclipse stops responding and causes 100% of CPU usage (UI controls not redrawn). The only action can be taken then is to kill eclipse process.
I discovered that it’s caused by big console output option. Test suite with low level (DEBUG) messages are able to kill Eclipse IDE, after setting log level to WARN no such problems are present.
You can also disable Limiting console output. It helped when no verbosity could be changed by logging configuration.
The error
org.hibernate.PropertyAccessException: exception setting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) setter of XYZ.setStatus().
Cause
Using primitive types (long) where NULL is possible or using wrong type (i.e. String if “char” is declared in HBM file).
Resolution
Change from primitive type (long) to wrappers (Long) or ensure correct type is defined in mapping files.
I assume you’re a developer and want to control global log level you are getting on your console window in Eclipse. Just log level. You don’t want to learn all Log4J machinery to create many log files, customize logging format etc. I’ll describe simplest steps to achieve this.
First, create commons-logging.properties file in your src/ directory (or directory on your classpath):
org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
Next, create simplelog.properties in the same location:
org.apache.commons.logging.simplelog.defaultlog=warn
org.apache.commons.logging.simplelog.showlogname=false
org.apache.commons.logging.simplelog.showShortLogname=false
org.apache.commons.logging.simplelog.showdatetime=false
That’s all! Your app will now log on WARN level and above in short, one-line format. Isn’t it simple?
If you want to give different log levels (info for instance) to different packeges:
org.apache.commons.logging.simplelog.log.<package prefix>=info
