Migrating to install4j 7

Thursday, July 13, 2017 | Posted by

In nearly all cases, migrating to install4j 7 just means opening and saving your project with the install4j 7 IDE. Nevertheless, there are some considerations with respect to backwards compatibility and a couple of behavioral changes.
  • The minimum supported Java version is now Java 7 up from Java 6 for install4j 6. This also means that the old Java 6 Apple JRE is no longer available as a separate type on the Bundled "JRE" step of the macOS media wizard. The launcher runtime still supports Java 6 and you can set the compiler variable sys.ext.forceMinJavaVersion to true in order to allow "1.6" as a minimum version. Note that no classes in the API can be called from Java 6.
  • The "native splash screen" feature for Windows has been removed. This went back to the pre-Java 6 days when Java did not offer splash screen functionality and was missing several important features. If you had this feature selected for one of your launchers, it now uses the regular Java splash screen
  • When a rollback terminates at a rollback barrier, the exit code of an installer application is now 0. To restore the old exit code of 1, you can set the "Exit code" child property of the "Rollback barrier" property to 1
  • In the "Key validation expression" script property of text components, the "keyCode" parameter has been removed. It was always 0 before and did not serve a useful purpose.
  • If you develop your own screens with the API, the methods isShowIndex, hasTitlePanel, hasDefaultInsets and hasDefaultButtons have been removed from the interface com.install4j.api.screens.Screen and so your existing implementation of these methods will no longer be called by install4j. This functionality is now covered by styles which are much more flexible than the previous limited styling capabilities.
  • In the API, methods with Object[] arguments for variable parameter lists have been converted to varargs. This should not cause source or binary incompatibilities but may show warnings in your code if you call such methods.
  • The "Create a quick launch icon" action has been removed with no replacement. The last OS where it had any effect was Windows Vista.
  • If you have not set a maximum Java version, and do not use a bundled JRE, any installed Java 9 JRE will be used. Java 9 has backward compatibility issues that may prevent your application from working unless you explicitly support it. Consider limiting the maximum Java version to "1.8" in that case.
  • If the "Request privileges" action fails, an installation directory in the user home directory is set. To restore the old behavior of keeping the default installation directory deselect the "Fall back to user specific installation directory" property on the "Request privileges" action.
If you notice anything else, please let us know!

JProfiler's integration into IntelliJ IDEA

Thursday, March 23, 2017 | Posted by

This screencast shows the JProfiler plugin for IntelliJ IDEA. A run configuration is profiled, source code navigation is discussed and the call graph data display in the IDE is shown.

Finding a memory leak with JProfiler

Wednesday, March 22, 2017 | Posted by

This screencast explains a basic strategy for solving memory leaks with JProfiler.

There is an older version of this screencast from 2009 that is not accurate for the heap walker anymore but that shows other useful features in JProfiler.

Complexity analysis in JProfiler

Tuesday, March 21, 2017 | Posted by

Complexity analysis in JProfiler is a tool for experimentally determining the Big-O behavior of algorithms based on the execution times of single selected methods. A bubble chart with curve fits of common complexities visualizes the results of the analysis.

Zero-configuration remote attach

Monday, March 20, 2017 | Posted by

This screen cast shows how to attach to a remote JVM with zero configuration on the remote side. The only requirement is an SSH connection to the remote machine. Remote JVMs are listed in the JProfiler UI and a JVM can be selected for profiling.

Comparing install4j to other deployment solutions

Thursday, October 06, 2016 | Posted by

Samuel Ruggieri from Voyager Games has written an interesting article comparing install4j against Java Web Start and other installer builders. His conclusion is this:

"At the end of this adventure, I have another experience that demonstrates the old adage that it’s cheaper to buy software than to build it. In this case, it’s cheaper and better. Software engineer hours are expensive, and for a non-trivial Java application, you’ll burn scores of them if you try to build a custom deployment and auto-update solution. At the end of that development, whatever you’ve built will almost certainly be inferior to what install4j can give you with a bare minimum of expense, both in terms of time and effort."

If you're thinking about comparing different deployment solutions for your Java application, maybe his article can provide some shortcuts.

Analyzing specific parts of the call tree

Thursday, November 26, 2015 | Posted by

This screen cast shows how the "Set root" action is used to analyze a specific part of your code. The "Set root" action in the call tree view is used to select the call stack of interest. The hot spot view and the call graph then only show data for the selected part of the call tree.