Networking and Unix
July 19th, 2018Jul 19th, 2018
April 19th, 2015Apr 19th, 2015
In the past I have been a great fan of Launch4j which I have used on projects like TemplateFx to create a single Windows executable for my Java application. This has always relied on the end user having a version of Java installed as it wasn’t able to support bundling a JRE into the actual EXE file.
Over the last 12 months or so the development model of Java has changed – instead of having a new release every 3 years, we are now seeing a new release every 6 months. Java 11 will also be the first release where we don’t have a public Oracle JRE available for non-commercial use. Oracle will continue to provide support for Java 8 up until 2019/2020, but beyond Java 8 they expect you to start using OpenJDK for non-commercial use (64-bit only as they dropped support for 32-bit with Java 9) and recommend you bundle OpenJDK with your applications – see http://www.oracle.com/technetwork/java/eol-135779.html.
With this in mind, I am looking at ways that I can continue to advance the code beyond Java 8, but still provide a solution that works for people – it is unlikely that people will upgrade beyond Java 8 as Oracle isn’t automatically updating people beyond it. It is also unlikely that people will go out of their way to download OpenJDK, hence the reason for this post.
Under Project Jigsaw introduced in Java 9, where the JRE is now split out into smaller run-time modules, it has now become feasible to start bundling a version of the JRE with your application (this does have some disadvantages unless you update your application when the JRE is updated). Historically if you tried to bundle a JRE with your application then you would end up with a 200MB executable, but this post will show you how I was able to bundle OpenJDK 10 with my TemplateFx distribution, taking up a total of around 25MB.
April 22nd, 2014Apr 22nd, 2014
UPDATED: 12th August 2016
I recently came across a requirement to provide password based encryption and decryption of data in a Java program. I initially assumed I just needed to pass my data through some internal Java “encrypt (plaintext, password)” type function and all would be fine. Unfortunately I found it isn’t quite as simple as this and there are quite a few pitfalls you need to overcome if you want to do this securely and properly.
I also wanted to work within the limitations of Java and only use native libraries (e.g. “javax.crypto”), which rules out the popular Bouncy Castle cryptographic library – rolling your own crypto functions is also a very bad idea (repeat “very bad idea“) as even the experts can get it wrong sometimes. I also wanted to ensure it worked with Java 7, which rules out some of the newer more modern modes of AES like GCM (Galois/Counter Mode).
April 6th, 2014Apr 6th, 2014
It seems Apple’s long term goal is to eventually drive a wooden steak through any technology that doesn’t adhere to their vision of the future. Before they had finished putting the final nails on the coffin of Flash, they have moved onto Java and placed it firmly within their crosshairs. This hasn’t been totally unwarranted though, Oracle has had a lot of bad press recently (and Sun historically) with respect to Java security, which has resulted in Apple disabling Java in the browser on numerous occasions until exploits and vulnerabilities have been patched – a strategy that some think was drastic, but it places pressure on vendors to fix things quickly and in this case, it appears to have worked.
I am going to start off by saying that since Java 7 Update 51, that using self-signed certificates is pretty much a waste of time for Internet deployments. With Update 51, Oracle has beefed up the security aspects of Java, which now blocks self-signed JAR files from being run via the web – even for applications which only want to run within the restricted “Sandbox”.
There are a couple of ways around this. The first is to reduce your security settings from the recommended (and default) High option to Medium (in the Java Control Panel), which allows self-signed JAR files to be executed after presenting a scary warning message (for the time being anyway). When set to High you don’t even get a choice, it was just blocked. The second is to get your clients to import your self-signed root certificate into their trust store – this approach could work within a closed or corporate environment but won’t on the Internet. The third, and recommended approach, is to sign your JAR file with a code signing certificate which has been signed by a trusted CA, but this will set you back a few pennies.