Java

If you’re using Eclipse and working with a class with a lot of static members, you might be affected by the problem of lack of content assist and automatic import for such members. Let’s say you’re using a Hamcrest matchers; you need a is(), notNullValue(), hasEntry() and so on (there are plenty of those). You don’t want to type Matchers.hasEntry() every time you use it in your code. Hey, that’s not why the fluent API was invented in the first place!...

I’m currently under the process of moving all my workplace repositories from SVN to Git (configured to work with Gerrit). As a side not, I already found it to be a great tool for code review, line-precise commenting of the artifacts and for reviewing new employees code before pushing the changes to the repository. But, back to my point. Recently I’ve stumbled upon a problem with committing an empty directory in Git....

By default, Maven’s test plugin Surefire doesn’t scan files for @Test annotations, but rather takes only the files which class names ends with “Test” or “TestCase”. I use both: unit tests and integration tests. I execute the latter using Arquillian framework, so it looks just like pure JUnit test. However, I prefer to name them with the “IT” suffix which means that they’re no longer recognized by Surefire plugin as test files....

Sometimes you might be struggling with such error shown, e.g. in Eclipse: The method … must override a superclass method. If this error is shown in the line when you have your interface method implementation with @Override annotation, it most probably means that you’re using JDK 5 instead of JDK 6. In Java 5, the @Override annotation might be applied only to the methods overriding superclass ones. Since Java 6 you can use the @Override annotation also with the methods that implements the interface ones....

Some time ago I’ve posted about using multiple -exec options for find command which can be used to find in what JARs particular class lies. Below you can find enriched and more intuitive/detailed solution for finding your class in a bunch of JARs: #!/bin/bash if [ $# -lt 1 ] then echo 'Usage: jarfind CLASS_NAME [DIR_WITH_JARS]'; exit 1; fi WHAT="$1" if [ $# -eq 2 ] then WHERE="$2" else WHERE="." fi FIND_RESULT=`find "$WHERE" -maxdepth 2 -name '*....

You probably know that if you use BMT (Bean Managed Transactions) you can get information about current transaction status by using UserTransaction interface (which implementation can be fetched either by JNDI or using dependency injection) and executing it’s getStatus() method. If you use CMT (Container Managed Transactions) you cannot use UserTransaction interface. Instead, you can manage your transaction through SessionContext interface. This interface gives you two places that hooks to the current transaction: setRollbackOnly(-) and getRollbackOnly()....

Just a note to myself – always check what classes are you importing in IDE, because if you see @Singleton in your class, it doesn’t mean it will work as a EJB Singleton. In my case it wasn’t referencing to javax.ejb.Singleton as I assumed, but com.sun.jersey.spi.resource.Singleton. Wasted 2 hours of looking for the answer or issue in a glassfish-3.1 JIRA. Did I mention I should always check the exact package of the imported class…?...

When you create a deployment using Arquillian (great test runner for testing your Java EE code in the container of your choice: jBoss, Glassfish, OpenEJB, … either in embedded, managed or remote mode) remember that the name of the deployment archive file is the exact filename that will be executed in the container. It does make a difference if you use *.war or *.jar for your deployment, so beware the following construct if it’s not exactly what you intended to do:...

If you want to add your classes (or any other resources) to your ShrinkWrap archive to a non-root location, you can use the following: @Deployment public static JavaArchive deploy() { // This is the classes and resources archive JavaArchive ar; ar = ShrinkWrap.create(JavaArchive.class, "resources.jar") .addPackage(TestClass.class.getPackage()); /* * The 'ar' archive will be added to the 'yourDir', so you'll * end with test.jar#/yourDir/TestClassPackage/TestClass.class */ JavaArchive endArch; endArch = ShrinkWrap.create(JavaArchive.class, "test.jar") .merge(ar, "yourDir"); endArch....

Pretty useful thing about the Java classpath definition is that the wildcard (*) can be used in a replacement of all *.jar and *.JAR files in the specified directory. So the following line: java -cp /tmp/app/*:/tmp/myJar.jar com.nullhaus.MyApp will add the /tmp/myJar.jar to the classpath, as well as all the *.jar and *.JAR files in the /tmp/app directory. Just remember that classpath never works recursively, so if you want to scan a subdirectory for jars you need to point it explicitly....