Configuring a Modern Java Development Environment in Windows with Windows Subsystem for Linux

I am a Java developer, and the impedence mismatch between Linux and Windows is still there, but the Linux is actually useable as a shell in Windows now, thanks to the RedStone 2 Release of Windows (aka the Creators Update or Version branch 1703). Now I’m not saying this is perfect – not by any means. The filesystem abstraction means that this stuff is way slower than you will get when compared to a barebones Linux or OSX environment. But sometimes you don’t have a choice. And this should only get better over time – believe me.  My friends working at Microsoft are using Linux just as much as I am.  Below, I’m detailing how to get your Java environment set up to use in Windows 10 when targeting a Linux installation.

Install Ubuntu in the Windows Subsystem for Linux
if you aren’t using a POSIX environment, it is suggested that you either install Bash for Windows, also known as the Ubuntu Subsystem using the Windows Subsystem for Linux (WSL). I make this distinction because, as of the latest release of Windows, they are starting to support multiple Linux distributions. Please note, some issues have been encountered when enabling Developer Mode, especially in locked down corporate environments – please see this and specifically choose the edit your registry option.

Continue reading

Maven Settings

So there are so many settings that get set before running a Maven build that it gets crazy.  There was a Confluence wiki that I used as part of Codehause (before they closed their doors) that I referenced a bunch when I was doing hard-core Maven plugin development that was extremely helpful.  You see, there are a bunch of ways that you can get the maven properties, but each of them requires setting up something in your project or running some odd command – but all I want is a simple reference.  So, I looked at this confluence site (which can still be found here, at least for the short term future) and compiled a list of very useful properties that everyone should have at their fingertips.  That way, whether you are setting up a project or doing plugin development, you can hit this reference.

Understanding Where The Properties Come From

First though, I’d like to cover the several ways that these properties are set.  Some are clear, some are not so much.

Maven loads up the XML files into Java Objects, and provides them for Maven plugins and the developer to use.  These XML files include pom.xml files, parent pom.xml files, as well as the settings.xml (and occasionally security-settings.xml, but I won’t cover that too much here).  The hierarchy can be a bit hard to follow for the uninitiated, but remember that all properties are resolved and then inherited (IN THAT ORDER) and the inheritance works in the way that pom.xml > parent pom.xml > settings.xml.  Or, a better way to think of it is that the most specific one wins.  Also, just in case it wasn’t clear, this is all case-sensitive, so “MyProgram” and “myprogram” are two separate variables.

When you want to access a variable, you just use the Ant model of variable replacement, which is the following: “${var_name}”.  This will evaluate the var_name and resolve it as part of your maven build.

Continue reading

Using HK2 with Jersey (with auto-scanning!)


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

Painfully Obvious – Synchronizing Git and SVN

So I was put into a funny position where we need to mirror our code to a customer’s Subversion (SVN) repository recently. Basically this is a customer requirement. We have been working in Git forever though, and the paradigm shift to move back to Subversion is just not acceptable once you get used to Git or any of the other DVCS options. It’s literally painful. Unfortunately, some customers dictate the rules. So, we were trying to figure out how to mirror the code in the best possible way. Let me walk you through my day and thought process. Please note, the end solution was not one that was perfect. Actually, the perfect solution doesn’t really exist, but this is the best we could do and hopefully it saves folks some time.

The scenario

Most of our changes were being kept in Git, with an occasional push to Subversion. But when in Subversion, we may have some integration issues and have to push back a couple of changes. If we can keep the history synchronized, awesome. If not, the merges just need to be reasonably painless. Continue reading

Making your Git Diff/Merge More Useful

OK, it is understood that you should try to keep your commits small in git, as well as other content versioning systems, but sometimes, you have to refactor or have a branch that won’t die.  Unfortunately, the merge process gets really painful.  Depending on what you are merging, this can sometimes be made much easier.  For example, if you are coding, the default line-by-line compare kinda sucks.  So I did a bit of research with my buddy, David Souther, to find out how to make this better.

Patience algorithm

The first algorithm is called the patience algorithm, which is documented visually here.  It’s basically searching for matching full lines to find points that haven’t changed.  This is useful, because if you are programming an API, this is likely to change less frequently than the code inside the API.

Histogram Algorithm

This is the one that jgit uses by default.  Eclipse, in turn uses the egit plugin, which uses jgit under the hood.  So basically, Eclipse uses this by default.  I attempt to stay out of the IDE as much as possible these days though, so I’d rather this be run on the command line.

Myers Algorithm

There is also a third, only sometimes useful one called Myers algorithm, which is a basic greedy algorithm.  It can sometimes be useful when you know that your code is in large runs in particular section.  More info here.

Testing it out

To test these out, anyone can do the following to see the default compare of a file and the last change in its history:


versus the following, which will run the patience algorithm:


Keeping the Change

You get the general idea.  Just adjust the algorithm with the “–histogram” or “–myers” flags.  If you want to keep a particular one, run “git config –global diff.algorithm patience”, which will save this as your default git diff algorithm.