Proxy: The Man in the Middle

Proxies occur naturally all over the place, for example in politics we elect someone to represent us in government because we cannot all be there. So it naturally follows that we would use the same pattern in software design. Here is an easy example: we have a class that implements an interface and submits a credit-card charge to a service provider. The interface provides what the client code expects, and the class adapts that to the provider. So this is actually an adapter pattern:

But what happens if the provider is offline? Well, we could change the adapter class so that it detects the problem and stores the transaction to process later. But that makes the class responsible for both interfacing to the service provider and caching transactions when the provider is not available. We would really like to stick as close as possible to Robert Martin's "Single Responsibility Principle" and separate responsibilities to easily manage them (Martin).

Who's Mock is it Anyways?

How to mock a third-party module for unit tests is a coding problem I often see pop up in design pattern boot-camps. In one boot-camp I teach the design involves using a third-party scale to weigh parcels.

This particular third-party scale returns a random weight each time it is used, so it cannot be used to test the validity of any calculations that depend on weight. So here is the thing: are we testing the adapter, or are we testing the client that uses the adapter? Because what we do in each of those situations is different.

Apache Derby Won't Start Anymore!

We use Apache Derby a lot as a stand-alone SQL database for software development courses. After Java 7 came out we started to have problems with Derby on computers in the classroom. Sometimes it would run, sometimes it wouldn't.

Sometimes it would run a computer with Java 7 or even 8, other times it would not. The common denominator was Java 7+, and while early releases of Java 7 do not exhibit any issues it is just easier to lump everything from Java 7 onward together. So when would it run? If the computer also had Java 6, and JAVA_HOME was set to that JRE, and if Derby was launched with a script that checked JAVA_HOME.

The real problem of course is that Derby is a Java application and the later JREs are locked down more and throw a security fit when Derby wants to bind to a TCP/IP port.

So the simple solution is to just write a script to wrap Derby and use Java 6. But, you may not have Java 6. In fact, you should not have it, there are simply too many security issues for it to be on your computer. Oh bother, what to do now?

Which Java am I using?

What happens if you have multiple JREs on a computer? Which one is is used when you run java at the command line?

You might tell me to look at the JAVA_HOME environment variable, but the only Java launcher I know of that actually checks it is the one that gets installed on OS X. There is no joy with JAVA_HOME for Windows or Linux.

Sometimes I need to know which JRE is being used. Maybe an application has a specific requirement, or I want to change the configuration perhaps to edit the java.policy and allow the Apache Derby database to bind to a TCP/IP port if I have Java 7 or higher.

The Quick Answers

On all platforms you can control which java executable is picked by putting the bin folder of a JRE earlier in the environment PATH variable and bypassing the launcher. Many folks like to set the environment variable JAVA_HOME to point to the the JRE (or JDK) folder, and then use that variable in the path: $JAVA_HOME/bin on OS X and Linux, %JAVA_HOME%\bin on Windows. When you set the variable then changes are reflected in the PATH (if you open a new terminal or command window) and it is always available in any scripts that use it.

If you need a particular JRE for an application, then wrap the application in a startup script that hardwires which JRE will be used to launch it. Other applications that need the default JRE will not be affected.

So the fast answer is that running the java command usually launches java in the last JRE that was installed, unless someone changed that configuration. But what if you don't know what was installed last? Generally you can look at the version and update numbers, but sometimes there may be multiple JREs of the same version.

The fastest way to solve that problem is to execute java -verbose -version. It will not announce the path for you, but it does log to the console all of the jar files loaded. The path to those jar files tells you where the JRE is!

So the rest of this post is an exploration of how the Java launcher actually goes about selecting the JRE that gets used. It is fun, it can be useful to understand what is going to happen when you type java, and it is mostly here so I can refer back to it. It turns out that the decision making process is not the same on every platform. Shocker.