I make apps for other people


HTTPS and self-signed certificates in Java

Posted by Chris Jones
On November 13th, 2015 at 07:02

Permalink | Trackback | Links In |

Comments Off on HTTPS and self-signed certificates in Java
Posted in Java
  1. You need a copy of the self-signed server certificate, typically an arm file.
  2. You need to add this certificate to a Java truststore (keystore)

        keytool -import -trustcacerts -file cert.arm -keystore clienttrust.jks

    Make a note about the password. You’ll be including it in the startup script so don’t reuse a personal password.

  3. Modify startup script to look to the truststore (with the password you set in the previous step)

        java -classpath ".:lib/*" $JVM_ARGS -Dlog4j.configuration=config/log4j.xml \
        -Djavax.net.ssl.trustStore=/path/clienttrust.jks -Djavax.net.ssl.trustStorePassword=password \
        -Djavax.net.ssl.trustStoreType=jks \
        com.company.path.ClassName "$@"


If you’re having HTTPS connection problems, add the following parameter to your startup script’s java command line:


OMG Eclipse

Posted by Chris Jones
On March 19th, 2014 at 09:02

Permalink | Trackback | Links In |

Comments Off on OMG Eclipse
Posted in Java

I haven’t been using Eclipse since I worked at Amazon, except for a few short stints pulling configuration values from one project to another at Overstock. Now that I’m at IBM, the corporate home of the Eclipse Project, and on a project that requires it (because I can’t get the IntelliJ IDEA Rational Team Concert (RTC) plug-in to install correctly) I’m getting a chance to see just how bad parts of Eclipse are.

I’m missing:
* Search everywhere
* Being able to click a button to point to the current file in the project/workspace
* When creating new files, being able to scroll around and reference other files to maintain consistency in naming
* Find a file by name (not just a class name). I’ve got over 24,000 files in this project . . .

I can adapt to the keystrokes well enough, but I’d hate to see how Eclipse would dog on any less of a machine than the Lenovo W530 I’m using.

Mint VM setup

Posted by Chris Jones
On December 30th, 2013 at 13:13

Permalink | Trackback | Links In |

Comments Off on Mint VM setup
Posted in Java, Tech

On Windows, use VMWare. I’ve run into problems with Oracle VirtualBox and Windows networking, although it works very well on Linux.

On the Thinkpad T420s I needed to enable VT-x (Virtualization support) in the BIOS setup under the Security-Virtualization menu.

VM Configuration
For a Core i5 vPro with four cores, I assign:

  • Four GB of RAM
  • Two processors
  • 32 GB of disk in a single file

Distribution Choice
On my hardware (Thinkpad T420s) I’ve had problems with Fedora. Ubuntu derived distributions work fine, including Linux Mint. I’ll assume that you’re using Linux Mint 16 Petra 64-bit.

I’ll download the .iso version via BitTorrent. Both VMWare and VirtualBox can mount and use ISO files for VM installation, plus it boots significantly faster than physical media.

Plug-in architectures in Java

Posted by Chris Jones
On March 14th, 2010 at 17:56

Permalink | Trackback | Links In |

Comments (2) |
Posted in Java

An off-hand discussion at work (“This application is being used by more groups now . . . wouldn’t it be cool to make it so they can develop independently?”) led to me looking into Java classloaders this weekend. Here’s the core for an application that’s treated like a bus in that it looks to see what’s plugged into it and provides communications (context) to each plug-in.

Signature of a Java service

Posted by Chris Jones
On October 28th, 2009 at 08:37

Permalink | Trackback | Links In |

Comments Off on Signature of a Java service
Posted in Java

I’ve dealt with Java services at Amazon too long when I can spot one by the CPU/memory signature.

The classic signature of a long-running Java service

The classic signature of a long-running Java service

This is pretty typical of a long-running service garbage collecting with old generation objects. Note the CPU utilization as the VM removes old generation objects and subsequent drop in memory utilization.

Cache eviction

Posted by Chris Jones
On July 25th, 2008 at 17:09

Permalink | Trackback | Links In |

Comments Off on Cache eviction
Posted in Java, Tech

B: size of the buffer
K: number of items having distinct access probabilities

LRU eviction: O(KB)
FIFO eviction: O(K)

Unless it costs a lot more to load an object into the cache, FIFO eviction may make the most sense. In most LRU implementations I’ve written, the cost to maintain the “use” status of the cached object was more expensive than a cache miss because of the object had been evicted. Consider the cost of loading the object versus the SLA for the service. Also, if the cache objects retrieved tend to be clustered very strongly with few if any changes, the cached objects won’t be evicted from the cache very often. A FIFO strategy only loses in the case of a full cache where rarely used objects are occasionally inserted and frequently used objects are evicted and reloaded.

The JVM garbage collector is generally less efficient with larger heap sizes. Heaps over 1 GB with efficient garbage collection is possible if the JVM is properly tuned. Concurrent Mark and Sweep collector may be buggy in very large heaps–tiny JDK 6+ JVMs in federation worked okay. Cache growth should be limited (especially with hashmap caches). The number of long living objects is a problem moreso than the size of those objects, so consider serializing/deserializing the objects to byte arrays (the JVM is optimized around short-lived object garbage collection and the cost of young generation garbage collection is proportionally lower than older generation garbage collection).

Tuning JVM Garbage Collection JDK 5.0

JCS vs Ehcache metrics


Posted by Chris Jones
On June 22nd, 2007 at 15:41

Permalink | Trackback | Links In |

Comments (2) |
Posted in Design Journal, Java

CombatSim version 0.3.0 is now available. This is still considered alpha quality, although it has undergone some testing.

Download CombatSim-0.3.0.zip now!


  • Various logic fixes
  • Actors are now internally stored as a dynamic data structure, so future versions will allow the user to specify complex arrangements, including friends or allies
  • Actors have a very basic aggro mechanism for determining who to attach and when
  • The combat core is now invoked externally and does not require a separate thread or real time clock; callers specify what time the core is invoked, so attacks in the past or using an accelerated clock can be run
  • A basic metrics system (including sums and histogram data) is integrated to the combat core and simulator for reporting
  • Reporting is dynamic for the number of actors, including graphical, table, and CSV reports
  • Problems with excessively long combat rounds in random actor testing have mostly been resolved: actors could have unrealistic or out of balance stats which caused cases of exceptionally high hit points coupled with very low damage or change to hit
  • Random combat order for actors can’t be overridden at this time
  • Combat rounds may not exceed 5000; the metrics take up too much room in the Java heap and can cause an out of memory error (I didn’t increase heap size in the launcher script)

Instructions for use:

  1. If you’ve been using an old version of CombatSim, remove your combatsim.settings file
  2. Download CombatSim-0.3.0.zip
  3. Unzip CombatSim-0.3.0.zip
  4. On a Windows box, double-click CS.bat; on a Linux or OS X box, execute ./CombatSim-0.3.0/CS.sh; on an OS X box, double-click CS.sh
  5. Press the “Fight!” button to simulate combat

I think I’ve spent around 40 or 50 hours on the iterations of this simulator. The end is in sight:

  • Change the UI to allow the user to edit arbitrary numbers of actors
  • Change the UI and default actor load to include more than one skill
  • Implement the method on the actor to choose the appropriate skill in combat
  • Add Focus as an attribute to the actor to guide skill use
  • Consider how to allow new combat rules to be plugged-in without recompiling the program


Posted by Chris Jones
On June 7th, 2007 at 09:39

Permalink | Trackback | Links In |

Comments Off on CombatSim-0.1.0
Posted in Design Journal, Java

CombatSim-0.1.0 is a bug-fixed re-release of 0.0.3. Elapsed combat time calculations are correct, as is effective DPS calculation. The code has been refactored (since 0.0.2) to facilitate reuse in a real game, albeit a trivial one given the state of the combat core, and the overall sim is ready for the next set of enhancements, including n-attackers and multiple combat skill use. Later, I’d like to add the capability to define your own combat rules (within the data structures the sim provides).

Between 0.0.2 and 0.0.3, the format of the combatsim.settings file changed slightly and the old version is no longer completely compatible (two fields were added). As this is not an alpha quality application, I didn’t see the need to back-down to the prior version of the settings file and transparently upgrade it.

Overall, I believe that with the recent reexamination of the code, the new metrics classes, and iterative development, this is the most accurate and useful version of CombatSim yet. You’ll need the Java 5 or Java 6 runtime (JRE or JDK) and this version has been tested against Win32 and Linux.
CombatSim-0.1.0 on Linux
One last word: this combat engine is the most primitive version of the engine I plan on using in my next development project.

CombatSim 0.0.3

Posted by Chris Jones
On June 5th, 2007 at 18:19

Permalink | Trackback | Links In |

Comments Off on CombatSim 0.0.3
Posted in Design Journal, Java

A new (buggy) version of CombatSim. This one has some combat tuning problems (specifically when actors are very imbalanced in stats) and doesn’t as strongly check for bad rounds (combats that take too many rounds).

Consider this an intermediate version with heavy refactoring (all for the best in the end) and many improvements in the API and code quality. It’s still very buggy, though.


As before, this is a Win32 only release (I didn’t update the shell script). Install a recent version of Java 5 or Java 6 (JDK or JRE 1.5 or 1.6) and double click on CS.bat to start CombatSim.

CombatSim 0.0.2

Posted by Chris Jones
On May 24th, 2007 at 22:26

Permalink | Trackback | Links In |

Comments (2) |
Posted in Design Journal, Java

Written on buses and during the occasional evening, CombatSim 0.0.2 is ready for your use. It requires Java JRE 5.0 or higher and must be uncompressed into a folder before it can be used. CombatSim can be started by either double-clicking the batch file, or from the command line with (roughly):

[Win32]    C:\CombatSim-0.0.2> CS

This version adds histogram support, writing CSV files of the results, and saving settings between runs. It is in no way completely tested, so consider it of alpha release quality.

Download CombatSim-0.0.2.zip here (3.4 MB).

This is a much bigger download than version 0.0.1 because of the chart library used. It’s late and the shell interpreter on OS X is pwning my startup script, so don’t count on CS.sh working. It tested fine on Cygwin but is very unhappy on my PowerBook.

Feel free to post any questions as comments or contact me via email.