Ingegneria del Software

A recent private conversation reminded me of a misunderstanding that has followed Java for decades. The person I was talking to had associated Java with the browser, with JavaScript, with invasive scripts, with old plugins, with poor privacy, and with the general feeling that modern computing often forces users into systems they don’t control.

That confusion is understandable. The names are similar, old browsers really did support Java applets, browser plugins really did become a source of security and usability problems, and Java’s historical promise of “write once, run anywhere” was often experienced by end users as “install this runtime before anything works”.

But that’s not the whole story. In fact, it may be the wrong story.

Java wasn’t born to make users dependent on a runtime. Java was born to reduce dependence on operating systems. Its deepest promise wasn’t that every user should manually install Java. Its promise was that software shouldn’t have to be rewritten from scratch for every platform, every vendor, and every device category.

For a long time, that promise was only partially fulfilled. Today, however, Codename One is approaching it from a different angle: Java or Kotlin for the developer, native applications for the user, and a single codebase that can target mobile, desktop, and web environments.

The Name Collision That Never Went Away

The first misunderstanding to remove is simple but persistent: JavaScript is not Java. MDN’s JavaScript documentation explicitly warns not to confuse the two languages: they have different syntax, semantics, execution models, ecosystems, and roles in software development.

JavaScript is the scripting language of the web browser. When we open a modern website, JavaScript is typically what makes the page dynamic: menus, forms, interactive maps, client-side validation, single-page applications, live updates, animations, and countless other behaviours. It is also true that disabling JavaScript often makes modern websites unusable, because the contemporary web has become deeply dependent on it.

Java is a different language and a different platform. It is statically typed, class-based, compiled to bytecode, and historically associated with the Java Virtual Machine. It is widely used on servers, in enterprise systems, in tools, in Android’s history, and in many kinds of long-lived software infrastructure. The two languages share a confusingly similar name, but they should not be treated as variations of the same technology.

This name collision has damaged Java’s reputation among non-specialists. For many users, “Java” became a vague word associated with “things running inside the browser”. But what ran natively inside browsers was JavaScript. Java’s browser story was much more specific: it was mostly the story of applets.

Browsers Were Not “Made in Java”

The mainstream browsers of the late 1990s and early 2000s — Netscape Navigator, Internet Explorer, Opera, Safari, Mozilla, and later Firefox — were not generally “made in Java”. They were system-level applications, mostly written in compiled languages such as C and C++, because they had to integrate tightly with the operating system, handle networking and rendering efficiently, and run on hardware that was far less capable than what we take for granted today.

Java’s relationship with those browsers was different. Browsers could load Java applets: small Java programs embedded inside web pages and executed through a Java Runtime Environment and a browser plugin.

In the context of the web of the second half of the 1990s, this made sense. HTML was limited, CSS was young, JavaScript was immature, browser compatibility was chaotic, and many interactive features that we now consider ordinary were not yet available as native browser capabilities. A Java applet could provide interactive graphics, educational tools, small games, chat clients, visualizers, and custom interfaces that plain HTML could not easily deliver.

For a moment, applets looked like a possible future of web applications.

But they weren’t the future.

Why Applets Lost the Web

Java applets had real problems:

• startup could be slow;
• the runtime could feel heavy;
• browser integration was inconsistent;
• security dialogs were confusing;
• plugin versions varied;
• compatibility was fragile.

From the user’s point of view, the experience often felt alien to the page around it: a rectangular foreign object embedded into a website, waiting for a runtime to wake up.

This doesn’t mean the idea behind Java was wrong. It means the deployment model was wrong for the web.

Flash, later owned by Adobe, became more successful in the browser for animations, games, video, advertising, and rich interactive experiences. It had its own authoring tools, a design culture, a timeline-based workflow, and a lower barrier of entry for many designers and creative professionals. But Flash had the same structural weakness: it was also a plugin. It wasn’t the web itself.

The web eventually chose another path. HTML5, CSS3, faster JavaScript engines, SVG, Canvas, native audio and video, WebGL, and later WebAssembly allowed browsers to absorb many of the roles previously delegated to external plugins. Adobe officially ended support for Flash Player on December 31, 2020, and blocked Flash content from running in Flash Player beginning January 12, 2021. OpenJDK’s JEP 504 later removed the Applet API, describing it as obsolete because neither recent JDK releases nor current web browsers support applets.

That wasn’t a defeat of Java as a language. It was the end of a particular client-side deployment strategy.

The Browser Moved On — and That Was Correct

Modern browsers no longer need Java applets or Flash to deliver rich user experiences. CSS can handle many interface animations directly. SVG can represent scalable vector graphics. Canvas can draw dynamic scenes. WebGL and WebGPU can expose hardware-accelerated graphics. JavaScript can coordinate complex user interfaces through browser-native APIs.

This is a better model for the web. A web page should not require an external plugin to show a chart, play a video, animate a menu, or run a small application. Those capabilities belong in the browser platform itself.

But the fact that Java disappeared from the client side of the browser doesn’t imply that Java lost its relevance. It means that Java’s future was elsewhere: servers, tools, enterprise systems, Android-related ecosystems, backend platforms, and cross-platform development models that don’t require end users to install Java manually.

That distinction is crucial. When a Java application runs on a server, users don’t receive Java bytecode in their browsers. They receive HTML, CSS, JavaScript, JSON, images, fonts, video, and other web resources produced by the server. Java remains invisible to the user. It is an implementation technology, not a browser dependency.

The same principle becomes even more interesting in client application development: Java can be the language of the developer without becoming the runtime burden of the user.

The Original Promise Was Still Noble

Java’s original promise was radical: write software once and run it on multiple operating systems. This threatened the traditional dependency between applications and the operating system. If developers could target a cross-platform runtime instead of a single vendor’s platform, the operating system would lose some of its power as a gatekeeper.

This is why Java wasn’t only a technical project. It was also strategically important. In the United States antitrust case against Microsoft, the Department of Justice described Java and Netscape as middleware threats to the Windows monopoly because they could provide alternative platforms for application development. Sun Microsystems’ legal conflict with Microsoft over Java compatibility was part of the same historical tension: a cross-platform Java ecosystem could weaken the gravitational pull of Windows-only software.

Whatever one thinks of the companies involved, the technical ideal remains compelling: developers should not be forced to rewrite the same application separately for every operating system, and users should not be locked into one platform merely because the applications they need exist only there.

That’s the noble side of Java. Not corporate nostalgia. Not plugin nostalgia. Not applet nostalgia. The deeper ideal is practical freedom from platform lock-in.

Where the Old Model Failed

The old Java client model often confused two different goals:

• portability for the developer, meaning a single codebase that can run across platforms;
• uniform runtime installation for the user, meaning that the user must have Java installed before the application can run.

The first goal is excellent. The second is where many real-world problems appeared.

For developers, a common runtime was attractive. For users, however, it could become friction: install Java, update Java, worry about security warnings, handle plugin or runtime compatibility, and distinguish between the application and the environment required to launch it. On the desktop, this made many Java applications feel less native than platform-specific alternatives. In the browser, the plugin model eventually became unacceptable.

The lesson is not that Java should abandon its cross-platform ambition. The lesson is that the ambition must be implemented differently.

The user should not have to care that the developer used Java.

The Better Model: Java for the Developer, Native for the User

The better model is this: let the developer write in Java or Kotlin, let the framework abstract the common application layer, and let the build system produce the appropriate output for each target platform.

That changes the meaning of “write once, run anywhere”. It doesn’t mean “ship a generic runtime and hope the user has it” anymore. It means “write one application and generate something that each platform can actually accept as natural”.

On iOS, that means an iOS app. On Android, an Android app. On macOS, a native Mac application. On Windows, a native Windows executable. On the web, a web-compatible target. The developer’s source language and the user’s delivery format no longer have to be the same thing.

This is where Codename One becomes important.

Source Code Recovery Is Not the Same Problem Anymore

There’s also another historical objection to Java that deserves a brief mention. In the early 2000s, during a job interview, I was asked which programming languages I worked with. I answered, first of all, Java. The person interviewing me wasn’t pleased. The objection was roughly this: “We deliver compiled software to our clients, not software from which the source code can be easily recovered”.

At the time, that objection wasn’t entirely irrational. Java bytecode is much easier to decompile than a traditional native binary. If a Java application is distributed carelessly, especially with debug information or without serious obfuscation, recovering human-readable source-like code can be surprisingly easy. I saw this myself years ago, in a legal professional context, when I was asked to recover the source code of a corporate Java application. The task was much simpler than many people would expect.

This isn’t an argument against free software, open-source software, or public-domain software. On the contrary, I personally believe that software released under free licenses, or even into the public domain, often has better long-term prospects than closed-source software. But it would be naive to deny that many companies and independent developers still build part of their business model around keeping their implementation private.

I discussed this issue years ago in a more technical article about reverse engineering Codename One applications. Some details have naturally aged, because the framework has evolved, but the general point remains useful: reverse engineering must be discussed per target platform, per build mode, and per transformation pipeline. A debug Android build, an obfuscated release build, an iOS build, and a web build don’t expose the developer’s original work in the same way.

Codename One changes the practical shape of this problem. The user doesn’t receive the original Java source code, and the final application isn’t simply a classic Java desktop program distributed as bytecode to be run by a local JVM. Depending on the target platform, the application goes through translation, optimization, native compilation, minification, or platform-specific build pipelines. Reverse engineering may still reveal strings, behaviours, protocols, resources, and parts of the generated code. It should never be treated as a substitute for proper security architecture. Sensitive logic and secrets should remain on the server whenever possible.

But recovering the developer’s original Java source code is a very different matter. In this sense, Codename One also answers an old business objection to Java: it lets developers work in Java without necessarily exposing the application in the old, easily decompilable form that many people still associate with Java distribution.

Codename One Reframes Java’s Promise

Codename One is an open-source, commercially supported cross-platform framework for building applications in Java or Kotlin. Its goal isn’t to revive applets or to force the old Java desktop model back into relevance. Its goal is to let developers build applications from a single codebase while targeting iOS, Android, desktop, and web environments.

In practical terms, a Codename One developer works with Java or Kotlin, Maven, a simulator, cross-platform UI components, CSS styling, build tools, and native integration points. The end user doesn’t install Java to use the application. The Java code is a development asset, not a user-facing dependency.

For readers who want a practical introduction, I wrote a Baeldung tutorial on cross-platform Java development with Codename One. That article focuses on hands-on development: project structure, Maven workflow, simulator usage, layouts, styling, persistence, REST integration, and the general mechanics of building a realistic application.

This article has a different purpose. It’s not a tutorial. It is an attempt to explain why Codename One matters historically: it offers a modern answer to a problem Java has carried since the beginning.

Why the Recent Codename One Updates Matter

The recent Codename One updates are especially significant because they move the framework closer to the most defensible interpretation of Java’s original promise: write in Java or Kotlin, but deliver native applications without making the user install a JVM.

The new native Windows port is a major example. Codename One describes it as a standalone Win32 executable generated through ParparVM, Direct2D, and DirectWrite: no JVM, no bundled runtime, and support for x64 and arm64 from one build. This is exactly the kind of result developers wanted in the late 1990s when they kept asking how to compile Java programs to an EXE.

The native Mac application target points in the same direction. A Codename One project can now build a real macOS application through the iOS pipeline, with desktop integration such as a title bar, native menu bar, interactive scrollbars, and desktop notifications, while avoiding the old assumption that a desktop Java app must bundle or require a JVM.

The same wave of updates also introduced a portable 3D graphics API and a gaming API with Box2D physics, alongside cross-platform printing and Apple Wallet support. This matters because cross-platform development shouldn’t be reduced to forms, buttons, and standard business interfaces. If Java or Kotlin can also express richer visual and interactive applications from a shared codebase, the original idea of platform independence becomes much broader.

These updates matter because they attack the old psychological problem directly. Many users and even many developers still hear “Java desktop app” and imagine Swing, AWT, JavaFX, a heavy runtime, and a non-native feel. Codename One is trying to make that association obsolete.

Just as important, Codename One isn’t limiting itself to UI portability. Recent work has brought WebSockets, GraphQL, and gRPC into the core, while the build-time code generation pipeline now includes an OpenAPI client generator, SQLite ORM, JSON and XML mappers, component binding, SVG and Lottie processing, and declarative routing. That’s not merely a way to draw buttons on many screens. It is the outline of a full application platform.

Not Nostalgia, but Continuity

It would be a mistake to present Codename One as a return to the past. The past is not coming back. Applets are gone. Flash is gone. Browser plugins are gone. The web rightly moved toward native browser standards. Users don’t want to install runtimes just to open a page or launch a small utility.

Codename One is interesting precisely because it doesn’t ask us to return to that model.

It keeps what’s valuable in Java: a mature language ecosystem, static typing, a huge developer base, a strong tooling culture, long-term maintainability, and the ideal of cross-platform development. At the same time, it avoids the most damaging part of the old client-side Java experience: exposing the runtime problem to the end user.

In that sense, Codename One isn’t a nostalgic defense of Java. It is a continuation of Java’s best idea through a more appropriate technical architecture.

The Social Value of Cross-Platform Development

There is also a social dimension here that is easy to underestimate.

When every platform requires its own codebase, software development becomes more expensive, more fragmented, and more dependent on large teams. Independent developers, small companies, educators, associations, public-interest projects, and local initiatives often cannot afford separate native teams for iOS, Android, Windows, macOS, and web.

A good cross-platform framework doesn’t merely save time. It can change who is able to build software at all.

Of course, no framework abolishes the power of platform owners. Apple, Google, Microsoft, browser vendors, app stores, SDK policies, signing requirements, and distribution channels still matter. Codename One doesn’t magically remove those constraints.

But it can reduce duplication. It can lower the cost of supporting multiple platforms. It can let a small team produce software that would otherwise require several specialized teams. It can let a Java developer participate in mobile and desktop application development without abandoning years of experience.

That’s why I see Codename One not only as a technical tool, but as a practical form of developer freedom.

What Java Becomes in This Model

In this model, Java is no longer something the user must install. It’s no longer a browser plugin. It’s no longer an applet box inside a page. It’s no longer a visible runtime requirement.

Java becomes a source language, a design environment, an ecosystem, and a way to express application logic that can be transformed into platform-appropriate outputs. The user receives the application. The developer keeps the productivity, structure, and portability of Java.

This distinction is essential. The failure of Java applets did not invalidate Java’s ambition. It invalidated a particular delivery model. Codename One’s strength is that it separates the ambition from that failed delivery model.

Conclusion: Java’s Promise, Reinterpreted

Java was supposed to free us from the operating system. For many years, that promise was compromised by plugins, runtimes, corporate battles, desktop friction, and the limitations of the early web.

But the promise itself wasn’t wrong.

We still need ways to write software without surrendering completely to each platform’s separate technology stack. We still need tools that let developers reuse knowledge, code, architecture, and effort. We still need cross-platform development that doesn’t punish users with awkward installation requirements or non-native experiences.

Codename One is one of the most interesting attempts to make that promise concrete again. Not by putting Java back into the browser. Not by reviving applets. Not by asking users to care about the JVM.

Instead, Codename One points toward a better formulation:

Java for the developer. Native applications for the user. One codebase across platforms.

That isn’t merely a technical convenience. It is the modern version of Java’s original ideal.

(June 18, 2026)