Wednesday, May 27, 2015
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).
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.
Friday, May 8, 2015
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?
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 AnswersOn 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.