What We Support

Java Native App Development & Maintenance

New development, repair, and maintenance of Java desktop apps built with Swing / AWT / JavaFX. We also support migrating assets stuck on Java 8 and Windows distribution via jpackage / GraalVM native-image. From 500k JPY.

Problems this service addresses

  • The developer of a Swing / AWT business app is gone, and no one can fix it
  • The app is stuck on Java 8 and security reviews keep flagging it
  • Applet / Web Start retirement removed your internal distribution channel
  • Every rollout hits trouble from mismatched JRE versions
  • You want to move to JavaFX but can’t estimate the blast radius
  • You want a new Java desktop app but don’t know how to choose the stack

What we handle here is Java desktop apps running on Windows. The focus is working with the assets you still have and improving them in stages, rather than rebuilding on principle.

Themes we handle well

  • New business apps and internal tools built with Swing / JavaFX
  • Analysis, feature additions, and bug fixes for existing Swing / AWT apps
  • Migrating from Java 8 to Java 17 / 21, including dependency cleanup
  • Runtime-bundled exe / MSI distribution with jpackage
  • Evaluating and adopting GraalVM native-image for native binaries
  • Fixing freezes and stutter around UI threading (EDT / JavaFX Application Thread)

Typical way of working

  1. First, we organize the app’s structure, Java version, dependencies, distribution method, and pain points.
  2. Next, we lay out the options — migrate, repair, or keep as is — with costs and risks, and decide the order of work.
  3. Implementation then covers the build setup, tests, distribution packaging, and logging for operation.

When this is a good fit

  • You want to fix an old Java desktop app but don’t know where to start
  • You want to combine a Java version upgrade with a rethink of distribution
  • You want help choosing between a native Windows app and a Java app, starting from technology selection
  • You want one point of contact for a mixed set of .NET and Java internal tools

Frequently Asked Questions

Can you take on a Java app whose original vendor or developer is unreachable?

Yes. As long as the source code remains, we can start from analysis and take on repair and maintenance. If part of the source is lost, we can still start by taking stock of what remains.

We are still on Java 8. Should we move to a current version?

We don't push modernization across the board. After sorting out security requirements, dependencies, and the remaining service life, we help you decide among migrating to Java 17 / 21, keeping the current setup running safely, or replacing the app.

We want to distribute without asking users to install a JRE.

We support bundling a runtime into an exe / MSI with jpackage, or producing a native binary with GraalVM native-image. We'll sort out which fits better, including startup time and build-pipeline impact.

We can't decide between replacing with a web app and keeping the Java desktop app.

We start by sorting out whether there are reasons to stay on the desktop, such as device integration or access to local resources. When replacement is the right call, we plan it the same way as our Windows app replacement service: specification inventory, staged migration, and rollback.

Get in Touch

If this service area matches the problem you are dealing with, please contact us with the current situation and what kind of support you need.

← Back to Home