Informatica Libera - Francesco Galgani's Blog

TV, giornali, social e Youtube di solito riescono bene nell’intento di coltivare disprezzo per specifiche categorie di persone, e a volte persino di godimento nella sofferenza altrui. La ninfomaniaca eccitazione dei nostri giornalisti al piovere di bombe dell’UE (spacciate per ucraine) su Mosca, sugli autobus russi, sui treni russi e sui dormitori studenteschi russi ne è solo un esempio.

I nostri rappresentanti politici di alto livello, al contempo, riescono a cogliere con sorprendente genialità ogni occasione per rendere ridicoli e disprezzabili se stessi e l’Italia, per inimicarsi gli alleati veri ed amici facendo loro la guerra, e per apputtanarsi con pulsioni masochistiche irrefrenabili ai maiali di più basso livello intellettivo, etico ed empatico che l’umanità abbia mai prodotto. Così, il crimine è diventato virtù, e lo stare a novanta prendendo frustate, pur di sopravvivere politicamente, è ormai un sabba doveroso e legittimo. Tanto i corpi da sacrificare al demonio, senza nessuna progettualità per il futuro, sono i nostri, non i loro. E intanto, veniamo continuamente divisi dagli odiatori seriali su temi di scarsa importanza, con un forzato silenzio su ciò che è più di interesse collettivo e urgente.

A livello di inconscio collettivo, i messaggi che ci arrivano orientano ciò che la maggioranza di noi pensa su molti temi, dimostrando, tra l’altro, che la democrazia è in sé vuota di significato, essendo la mente del cittadino come un vuoto da riempire. Questo, tra l’altro, è anche il principio di funzionamento della pubblicità commerciale: se funziona, e se ha sempre funzionato, allora vuol dire che è rivolta a persone senza un’identità, senza un pensiero autonomo e senza scelte che non siano già state preventivamente decise da altri. Più la pubblicità e l’agenda setting indirizzano le emozioni e i pensieri, e più il cittadino dimostra a se stesso e a chi ci comanda di essere un idiota. Se l’essere umano avesse avuto un po’ più di coscienza, di controllo emotivo e di capacità di scegliere le proprie fonti, non sarebbe mai esistito un modello imperante di business e di politica basato sulla pubblicità, cioè sulle bugie e sull’inversione di realtà.

Dopo questa premessa con la quale sono riuscito ad offendere pesantemente circa otto miliardi di persone, tra le quali rientro anch’io – nel ruolo di folle che osserva altri folli in un grande manicomio collettivo – adesso vorrei parlare del disprezzo indotto.

Facciamo qualche esempio di categorie che, in un modo o nell’altro, ci vengono offerte come oggetti di amore obbligatorio o di odio autorizzato.

Nel racconto main-stream:

• gli ucraini da amare;
• i russi da disprezzare;
• gli israeliani da compatire;
• i palestinesi da sospettare;
• l’Occidente da assolvere;
• la NATO da normalizzare;
• i dissidenti da ridicolizzare;
• i “populisti” da patologizzare;
• i non-allineati da trattare come ingenui o complici;
• i migranti da compatire quando servono alla retorica umanitaria e da temere quando servono alla retorica securitaria;
• le persone LGBTQ+, o meglio l’interminabile sigla liturgica con cui il main-stream pretende di incasellare identità vive e complesse, da celebrare come simbolo obbligatorio di progresso.
• e così via...

Nella contro-informazione o informazione alternativa, spesso, la polarità si rovescia ma il meccanismo resta identico:

• i fratelli russi sono il popolo dell’eroica resistenza al nazismo occidentale;
• gli ucraini burattini dell’Occidente o, peggio, nazisti in blocco;
• gli israeliani vengono confusi con il loro governo fino a scivolare nell’odio verso un intero popolo;
• i palestinesi diventano martiri assoluti;
• l’Occidente è solo decadenza e indecenza morale;
• la NATO è solo l’impero del male e delle bugie;
• i giornalisti sono solo servi propagandisti;
• gli scienziati perlopiù venduti;
• le donne attualmente in politica una vergogna e un’indecenza per le donne stesse;
• le persone LGBTQ+ solo “agenda”, “provocazione”, “carnevale”, “indottrinamento”, soprattutto quando appaiono nello spazio pubblico con modalità percepite come offensive.

Poi ci sono i bersagli mobili, quelli che cambiano valore a seconda della convenienza narrativa: i musulmani, ora vittime dell’imperialismo ora minaccia alla civiltà; i cristiani, ora retrogradi ora perseguitati; i poveri, ora vittime del sistema ora parassiti; i ricchi, ora benefattori ora vampiri; i giovani, ora speranza ora generazione fallita; gli anziani, ora saggi ora zavorra; i meridionali, i provinciali, i rom, i cinesi, gli americani, gli africani, i poliziotti, gli attivisti climatici, i no-vax, i vaccinati, i pacifisti, i militari, i rifugiati, i maschi, le femmine, i trans, i religiosi, gli atei: tutti trasformabili, all’occorrenza, in categoria morale.

Il punto non è stabilire chi meriti amore e chi meriti odio. Il punto è accorgersi che molte fonti non ci informano, ma ci addestrano emotivamente, inculcandoci una rappresentazione della realtà che è distorta nella migliore delle ipotesi, completamente falsa negli altri casi. Ci insegnano chi piangere, chi deridere, chi temere, chi assolvere, chi disumanizzare. E spesso noi crediamo di esserci formati un’opinione informandoci, mentre abbiamo solo appreso un riflesso emotivo condizionato.

Eppure c’è una cura efficace per questo riflesso condizionato. Posso avere disprezzo per i meridionali se il mio più grande amore, e le mie più importanti amicizie, provengono dal Sud Italia? Posso odiare gli israeliani se un uomo per me importante è israeliano? Posso aver paura e disprezzo per i musulmani se ho vissuto anni di reciproca stima con un musulmano? Posso odiare i russi se mi sento emotivamente molto vicino al popolo russo? Posso disprezzare chi sventola bandiere arcobaleno se tra costoro ci sono persone che conosco e che stimo? Posso disprezzare in blocco tutti i giornalisti e i politici, come peraltro ho fatto con rabbia all’inizio di questa riflessione, se poi, in realtà, ho una grande stima verso alcuni giornalisti che seguo, di cui uno è anche un politico? Se continuassi con gli esempi, finirei con l’includere tutte le categorie, perché sono un essere sociale.

L’amore, l’amicizia e la famiglia sono una sana cura contro tutto questo folle indottrinamento di santi, mostri, vittime pure, e nemici ontologici. Ci vengono insegnati disprezzo e odio verso una categoria? Proviamo a porci in maniera “pulita” verso coloro che ne fanno parte, poi si vedrà…

Cambiano i santi e i mostri, ma resta identico il bisogno di fabbricarli. Noi non abbiamo bisogno di ideologie, ma di contatto reale con persone reali. Dovremmo anche imparare ad essere sempre di più vigili, perché quando una causa viene trasformata in riflesso emotivo, noi cittadini smettiamo di pensare e cominciamo solo a reagire.

(20 giugno 2026)

Volere consapevolmente la realtà della propria vita, senza escludere nulla

Nel mio precedente articolo “La natura del desiderio”, ho scritto che la distanza tra realtà e desiderio è la misura della nostra sofferenza. Lì il movimento interiore era espresso con una parola: “Rinuncio!”. Era la rinuncia alla pretesa che la realtà debba conformarsi ai miei desideri; alla guerra contro ciò che è; al tentativo, quasi sempre impossibile, di piegare il mondo, il corpo, gli altri, il passato e persino la mia mente a ciò che vorrei.

Ora vorrei provare a fare un passo ulteriore.

Rinunciare alla pretesa che la realtà si conformi ai nostri desideri può dare serenità. Tuttavia, credo che esista una possibilità ancora più radicale: non soltanto accettare ciò che è, ma desiderarlo. Desiderare tutto ciò che è. Non in senso metaforico, non come formula consolatoria, non come artificio linguistico per rendere sopportabile l’insopportabile, ma come atto cosciente, volontario, continuo.

Se la distanza tra realtà e desiderio è sofferenza, allora la coincidenza tra realtà e desiderio è felicità.

Di solito desideriamo ciò che non c’è. Desideriamo un’altra condizione, un altro corpo, un’altra salute, un’altra storia, altri pensieri, altri desideri, un altro passato, un altro presente. Il desiderio, così inteso, è sempre desiderio di distanza. Vuole portarci altrove. Vuole sottrarci a ciò che stiamo vivendo.

Ma che cosa accade se desidero esattamente ciò che sto vivendo?

Mentre scrivo queste parole, posso desiderare di scrivere esattamente queste parole. Posso desiderare di essere nel luogo in cui mi trovo. Posso desiderare di avere il corpo che ho, la stanchezza che ho, i pensieri che ho, le esitazioni, le contraddizioni, le condizioni materiali e interiori in cui mi trovo. Posso desiderare non un’altra scena, non un’altra vita, non un’altra versione di me, ma precisamente questa esperienza: io che scrivo, qui, ora, così, tra l’altro in una posizione abbastanza scomoda.

Sembra incredibile, eppure basta questa disposizione interiore affinché il desiderio sia realizzato. Non è autosuggestione, ma pieno desiderio di vivere l’esperienza umana per ciò che è, fino a scoprire che è proprio questa esperienza ad essere il tesoro più prezioso. Divento come chi ha cercato una gemma preziosa per tutta la vita e finalmente si accorge di averla sempre avuta con sé.

Non perché il mondo abbia finalmente obbedito a me, ma perché io ho smesso di desiderare un mondo diverso da quello che si presenta. La realtà non è cambiata; è cambiato il rapporto tra desiderio e realtà. Il desiderio non si protende più verso l’assenza, ma aderisce al presente. Non vuole più fuggire da ciò che accade, ma desidera ciò che accade.

Questo richiede una forma costante di meditazione e di autovigilanza. La mia vita sembra allora svolgersi su due piani. Nel primo vivo, penso, agisco, parlo, scrivo, cammino, mangio, soffro, desidero. Nel secondo osservo me stesso mentre vivo, penso, agisco, parlo, scrivo, cammino, mangio, soffro, desidero. E, osservandomi, desidero che io stia vivendo proprio ciò che sto vivendo.

Divento un essere che osserva se stesso pensante e vivente. Poi questo essere include anche questa osservazione nel desiderio, e desidera che se stesso abbia proprio quei pensieri, quei desideri, quella postura, quella condizione, quella storia, quella fame, quella paura, quella vergogna, quella gioia, quella follia. Desidera che l’esperienza sia esattamente così com’è.

Non solo: se sorge un desiderio diverso, desidera anche quel desiderio. Se sorge il rifiuto della realtà, desidera anche quel rifiuto. Se sorge la rabbia, desidera la rabbia. Se sorge un pensiero disturbante, desidera quel pensiero disturbante. Se sorge un desiderio moralmente inaccettabile, desidera anche quel desiderio, non per trasformarlo in azione, non per giustificarlo, non per farne una virtù, ma per riconoscerlo come parte della realtà interiore che in quel momento si manifesta.

Nulla deve rimanere fuori.

La pratica è estrema proprio perché include ciò che normalmente vorremmo escludere: le ombre, le follie, le bassezze, le paure, le pulsioni, i pensieri indegni, i ricordi umilianti, le ferite, gli errori, le tragedie. Non basta desiderare ciò che appare spiritualmente decoroso. Non basta desiderare il respiro, la calma, la luce, il bene, la compassione. Bisogna desiderare anche ciò che giudichiamo sporco, confuso, brutto, disturbante, impresentabile.

Desiderare tutto ciò che è significa desiderare l’intera realtà della propria vita umana.

Se la mia condizione è l’indigenza, desidero l’indigenza. Se la mia condizione è la fame, desidero la fame. Se la mia condizione è la malattia, desidero la malattia. Se la mia condizione è la solitudine, desidero la solitudine. Se la mia condizione è il fallimento, desidero il fallimento. Se la mia condizione è il rimorso, desidero il rimorso. Se in me sorge il desiderio di non desiderare nulla di tutto questo, desidero anche tale desiderio.

Questo non significa dire che la fame sia buona, che la malattia sia buona, che la tragedia sia buona, o che l’ombra sia buona. Significa qualcosa di più radicale e meno morale: significa desiderare la realtà per il fatto stesso che è realtà. Significa non contrapporre più alla vita vissuta una vita immaginaria che non esiste.

Beninteso, desiderare ciò che è non significa desiderare che continui, né rinunciare ad agire per trasformarlo. Significa cessare, interiormente, di contrapporre all’istante reale un istante immaginario.

Anche il passato può essere desiderato. Anzi, forse il passato è il banco di prova più difficile. Posso desiderare di aver vissuto esattamente ciò che ho vissuto? Posso desiderare i miei errori, le mie perdite, le mie ferite, le mie umiliazioni, le mie tragedie? Posso desiderare non soltanto di essere qui ora, ma di essere arrivato qui attraverso tutto ciò che è accaduto?

Se lo desidero davvero, il passato smette di essere un nemico. Non viene cancellato, non viene abbellito, non viene giustificato: viene desiderato. E dal desiderio può sorgere una gratitudine difficile da spiegare: gratitudine per aver vissuto proprio questa vita, non un’altra; gratitudine per essere stato esposto a questa forma umana dell’esperienza, con tutto ciò che essa ha comportato.

Per me, la base di questa pratica è riconoscere se stessi come parte di un ordine più grande, o, usando una parola difficile e pericolosa, come un pensiero di Dio. Non intendo “Dio” in senso confessionale. Non penso a un Dio personale, esterno al mondo, che giudica, premia, punisce, interviene e decide. Da buddista, preferisco usare la parola “Dio” in senso immanente, forse più vicino al Dio-Natura di Spinoza: non un essere separato dalla realtà, ma la realtà stessa nel suo infinito manifestarsi.

In questo senso, tutto ciò che accade può essere visto come espressione della realtà, o di Dio-Natura: i corpi, gli eventi, i pensieri, i desideri, le condizioni, le gioie, le follie, le tragedie. Da questa prospettiva, tutto ciò che esiste e che accade corrisponde ai “pensieri di Dio” o ai “sogni di Dio”, di cui ciascuno di noi è parte e manifestazione.

Anche ciò che giudico mio non è separato dal tutto. Anche il pensiero che mi attraversa, anche il desiderio che mi inquieta, anche la condizione che vorrei rifiutare, sorgono nella realtà e come realtà.

In termini buddisti, le nostre vite si manifestano nel mondo di Sahā: un mondo impuro e faticoso, attraversato da corruzione, desiderio, paura e dolore, ma proprio per questo anche luogo di esercizio, pazienza e risveglio. Non un altrove da disprezzare in nome di una purezza immaginaria, ma il campo stesso in cui imparare a non respingere nulla della realtà che si presenta.

Amare i propri pensieri, allora, non significa narcisismo.
Amare i propri desideri non significa obbedire loro.
Amare le proprie ombre non significa trasformarle in bene.
Amare la propria condizione non significa dichiarare le proprie difficoltà auspicabili, ma riconoscerne una possibile funzione formativa e compassionevole: formativa, perché danno forma al modo in cui attraversiamo l’esperienza umana e possono renderci più saggi; compassionevole, perché possono metterci in condizione di comprendere meglio la sofferenza altrui. Forse anche queste difficoltà fanno parte del motivo per cui siamo rinati in questo mondo di sopportazione.

Significa amare la realtà che si manifesta come questa vita.

Se tutto ciò che accade è, in questo senso, espressione di Dio-Natura, allora il desiderio consapevole di ciò che accade è una forma di amore per Dio. Non adorazione confessionale, non sottomissione religiosa, non obbedienza a un’autorità trascendente, ma amore immanente per la realtà nella sua interezza.

Desiderare i propri pensieri è desiderare la realtà che pensa in noi.
Desiderare i propri desideri è desiderare la realtà che desidera in noi.
Desiderare la propria condizione è desiderare la realtà che prende questa forma.
Desiderare persino le proprie follie è desiderare che nulla della vita venga escluso dall’amore.

Contrariamente a quanto il senso comune potrebbe suggerire, è una pratica facile, rasserenante, ma all’inizio tutt’altro che spontanea, e proprio per questo deve essere continuamente coltivata. Ogni volta che sorge il rifiuto, possiamo desiderare il rifiuto. Ogni volta che sorge il giudizio, possiamo desiderare il giudizio. Ogni volta che sorge la vergogna, possiamo desiderare la vergogna. Ogni volta che sorge il desiderio di essere altrove, possiamo desiderare anche quel desiderio di essere altrove. L’effetto è quello di una pulizia interiore, di un alleggerimento, di una vita sfiorita che inizia a rifiorire.

Così non c’è più un fuori.

Non c’è più una parte della vita da espellere, una parte della mente da nascondere, una parte del passato da maledire, una parte dell’esperienza da dichiarare indegna di essere stata vissuta.

Rimane soltanto questo: vivere la realtà della propria vita umana e desiderarla, momento dopo momento, nella forma esatta in cui si presenta.

Desiderare tutto ciò che è.

Non perché tutto sia bello.
Non perché tutto sia buono.
Non perché tutto sia giusto.
Ma perché tutto è.

E se desidero ciò che è, allora non mi manca nulla.

(18 giugno 2026)

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)