Using HK2 with Jersey (with auto-scanning!)

Overview

HK2 has been an interesting ride. For the most part, if anyone asks, I’m still going to suggest Spring for Dependency Injection, because the documentation is a thing of wonder. Plus, Spring Inversion of Control (IoC) and Aspect Oriented Programming (AOP) are the wheelhouse that makes all of the other Spring stuff possible.  However, there are some situations where using these technologies are requested/required, so it’s good to know how to use them.

Understanding Dependency Injection

Dependency Injection is a great way to decouple your code from the implementation.  For example, if you create an interface in your core program, and you can leave the implementation for creation in a different library.  How is that useful?  One example of this would be for database access.  If you create a simple interface, like the following:

Now, use this interface in some form of implementation. This should provide a simple passthrough implementation usage of the interface:

You can then make two different implementations that function very differently, and put them in separate jars.

The first could access a database, such as PostgreSQL:

The second implementation could be a MongoDB implementation:

Now for the interesting part… You want it to be able to change at runtime. So your customer can easily change and use PostgreSQL or MongoDB with ease. Heck, they can even add a Redis store with ease and without having to recompile a single line of code. It seems like magic, but it’s not. It’s just smart decoupling.

Continue reading

The New Hotness – Spring 4’s Spring Boot

The guys who make the Spring framework libraries are no slouches.  They know the ups and downs of their own framework, as well as Java as a whole.  They are also on top of all of the newer JVM technologies, such as Groovy, Scala, Gradle, Spock, etc.  Heck, if they weren’t making money hand over fist, I’d think they would be great core language developers.  The would progress the language to a point that I’d love using it again.

The reason I say all of this is because the developers of the Spring framework realized that there are a couple other frameworks out there (Ruby on Rails, Grails, Django, etc.) that favor convention over configuration.  Meaning, I don’t want to have to set up 50 XML files to configure a project just so that I can get it running as a simple web service.  It shouldn’t be that complicated.  Spring 4 has some answers for you.  Spring introduced Spring Boot, a group of annotations that will favor convention over configuration… at least until you need to change it to something more complicated. The way it acts, I think they may have backported some of the stuff they did for Grails right into Java. Continue reading

SOAP vs REST – Understanding the Underlying Differences

I’ve never used Simple Object Access Protocol (SOAP), because, since I’ve been a developer, I’ve always been involved in projects using Representative State Transfer (REST) services.  Turns out, this wasn’t as simple of a question as I’d hoped.  Also, it seems that it’s not an old protocol that nobody should use.  It actually has plenty of good uses and a bunch of solid tools too.
Continue reading

Accessing Java Resources (a.k.a. getResource vs getSystemResource)

This isn’t a tough article, but one that I always forget and have to look up. This is useful for everyone who has to touch Java for the first time or experienced users who just forget (like me).

Adding a resource, especially when using a build tool Maven, is quite easy. You just include it in the jar (which in maven, is by putting it in ${projectdir}/src/main/resources). Getting it back out is a little trickier, but not too bad.

The easiest way to access this is to use the getResource instead of getSystemResource, which are on the Java Class Loader, to use a resource specific to a given classloader instead of the system. For example, try any of the following:

Note the leading slash when calling Class.getResource instead of ClassLoader.getResource; Class.getResource is relative to the package containing the class unless you have a leading slash, whereas ClassLoader.getResource is always absolute.

Also, as a side-note, if you are trying to access resources from a dependency, don’t. You are doing it wrong. This is possible, but bad design and hard to implement.

Testing in Java – A Primer

Evolution

As with everything in coding, or STEM in general, Java Testing is evolving.  It’s not the same as it was 3-5 years ago, and it shouldn’t be treated as such.  Keep that in mind if you are referencing this article 3-5 years from now.  Hopefully we’ll all be on Java 8 and Lambda expressions or everyone will be familiar with Groovy and Spock and will change how we test again.

For now though, I have noticed that there is no good all encompassing reference for people to start learning how to test properly, so I thought I would put a basic how to up there on using some of the current tools.

Including testing in your project

This is going to depend on your build tools.  Most companies use Maven right now, so I’ll provide this example.  Using Gradle/Ivy/Buildr/etc., there will be an analog, but you are going to have to figure it out yourself.

The following code should be added to your pom.xml so that you have the tools available when your code is testing.  If you plan on messing with the versions listed here, make sure to reference the following chart first: Supported Versions (http://code.google.com/p/powermock/wiki/MockitoUsage13)

Setting up your Imports

In your newly created class, you are going to need access to some things that we’ll cover as I continue on.  For the time being, go ahead and statically import JUnit and PowerMock into your class.  This will allow you to use the static methods as if they were locally defined. Continue reading

Java 7 is Here (and has been for a while…)

Ok, what is the deal with folks actively not wanting to upgrade to Java 1.7?

I understand the small, but growing segment of society that are on Mac OS that don’t really have options until Apple throws some more resources into the OpenJDK development. I can also understand if there are system or contractual requirements for keeping yourself compatible with older versions of Java. However, my question is targeted towards folks who don’t have these excuses, but are just

For example, just recently dealing with a Linux platform guy who complained about having to upgrade. Linux/Unix is unequivocally the best supported platform for Java (one of the few advantages it has. Thank god for VMs). The stuff I had written was written to JDK 7, since the Java support is ending for Java 1.6 soonish (it was extended, but still). He wanted me to write my stuff to not include my Java libraries, rather than install the new JDK. Seriously? Seriously.

I wish he was the only one that had come up with. This has been coming up across the board. Plenty of customers having been pushing back for no reason (though they are going to have to do it anyways). If you look at some of the statistics on newer users (on sites like BlueJ or GreenFoot, people learning Java aren’t even downloading the newest versions. That’s just ridiculous.

For anyone out there that is a Java developer at this point. You should have installed JDK 1.7 already. I understand if you have to include

flags on your compiler to make it compatible with older versions, but you should still have the newest versions. Also, you should know what the new version contains. If you aren’t, for example, taking advantage of the new nio libraries, you are wasting your time on bad code. This stuff makes the Apache commons I/O stuff look insignificant and brings it closer to the scripting languages like Perl, Python, or Groovy. Not to mention how much better JDK works with Groovy, Scala, and Clojure.

This is really just a plead to developers to not get stuck in your sedentary ways. Just upgrade already.