Java SE Embedded

Author: Tomas Zezula

Version 0.1


  • User has to be able to run the application both locally and on a device
  • User has to be able to debug the application both locally and on device
  • User has to be able to profile the application both locally and on device
  • Several different devices has to be supported in a single project
  • Switch among local execution and on device execution has to be trivial and fast operation.
  • Easy set up of remote device

J2SE Project Integration

To fulfil the above requirements the best solution is to integrate the on device execution as an run configuration of the J2SE project. Such a integration requires UI changes in the J2SE project properties and several new extension points such as creation of the custom runtime configuration and dynamic project customiser changing the UI according to active configuration has to be added.

Build System Integration

The second part of this task is to incorporate the on device execution into the J2SE build system. The on device execution consists of deployment and actual remote execution. There are several possibilities for deployment such as ftp, http, scp as well as for execution telnet, rlogin, ssh. It's questionable if several deployment and execution methods are needed or scp deployment is enough. The decision significantly affects implementation of the execution.

The deployment can be implemented using:

  • Ant standard tasks scp and sshexec - supports scp, ssh only.
  • Depending on native commands installed on the user machine - may be problematic on Widows where basic commands like ssh, scp are not available by default.
  • Custom task implementing the transfer by 3rd party libraries (eg. jsch for ssh, scp). The custom task provides biggest control over the deployment but has several disadvantages regarding the project shareability and headless build.

The J2SE project build script is a part of the public API and cannot be changed, an incompatible change of the build-impl.xml will affect millions of existing projects. Implementing the remote execution has to be done as without incompatible changes to build-impl.xml.

Possible solutions:

  • Extension of the build-impl.xml as done by JWS, J2SE Native Packaging or JFX. Hard to do as it's impossible to override either the run, debug, profile targets or java macrodef due to Ant target overriding rules.
  • Custom build-impl.xml for remote execution. Different version of a build-impl.xml for remote execution as it's currently done for non default platform. The bottleneck of this solution is harder shareability and runtime configuration switch will cause regeneration of the build-impl.xml which is an expensive operation. Even for non default platform there is a task to get rid of such a build-impl.xml change.
  • Override the run, debug, profile directly from project's build.xml. The build.xml is an user editable file and overriding these targets from it may break the user project.

The execution method should be determined as a results of prototyping the above possibilities but the careful extension of the build-impl.xml seems most correct solution.

How To

Java SE Embedded How To


  • Remote Plarform Image:yes_EditorPlan68.png
  • jrecreate support Image:yes_EditorPlan68.png
  • Remote execution Image:yes_EditorPlan68.png
  • Remote debugging Image:yes_EditorPlan68.png
  • Remote profiling Image:yes_EditorPlan68.png
  • Detection of compact profile on remote VM Image:yes_EditorPlan68.png
  • Detection and fixes of missing or incompatible remote platform Image:yes_EditorPlan68.png
  • Using keyring password Image:yes_EditorPlan68.png
  • Build script versioning Image:yes_EditorPlan68.png
  • JavaFX Project Remote Platform Validation (3d)
  • Disabling Debug for Remote Platforms with no debuggable VM Image:yes_EditorPlan68.png
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo