News: 0180380097

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Applets Are Officially Going, But Java In the Browser Is Better Than Ever (frequal.com)

(Saturday December 13, 2025 @10:44PM (EditorDavid) from the Java-vs-Tea dept.)


"The entire java.applet package has been removed from JDK 26, which will release in March 2026," [1]notes Inside Java .

But long-time Slashdot reader [2]AirHog links to this blog post reminding us that " [3]Applets Are Officially Gone, But Java In The Browser Is Better Than Ever ."

> This brings to an official end the era of applets, which began in 1996. However, for years it has been possible to build modern, interactive web pages in Java without needing applets or plugins. [4]TeaVM provides fast, performant, and lightweight tooling to transpile Java to run natively in the browser...

>

> TeaVM, at its heart, transpiles Java code into JavaScript (or, these days, WASM). However, in order for Java code to be useful for web apps, much more is required, and TeaVM delivers. It includes a minifier, to shrink the generated code and obfuscate the intent, to complicate reverse-engineering. It has a tree-shaker to eliminate unused methods and classes, keeping your app download compact. It packages your code into a single file for easy distribution and inclusion in your HTML page. It also includes wrappers for all popular browser APIs, so you can invoke them from your Java code easily, with full IDE assistance and auto-correct.

The blog post also touts [5]Flavour , an open-source framework "for coding, packaging, and optimizing single-page apps implemented in Java... a full front-end toolkit with templates, routing, components, and more" to "build your modern single-page app using 100% Java."



[1] https://inside.java/2025/12/03/applet-removal/

[2] https://www.slashdot.org/~AirHog

[3] https://frequal.com/java/AppletsGoneButJavaInTheBrowserBetterThanEver.html

[4] https://teavm.org/

[5] https://flavour.sourceforge.io/



Good riddance (Score:1)

by backslashdot ( 95548 )

Applets sucked so badly, that I will never believe Java can be good for any UI.

Re: (Score:2)

by DeanonymizedCoward ( 7230266 )

> Applets sucked so badly, that I will never believe Java can be good for any UI.

Well, Arduino is written in Java (at least the legacy versions), and it's got a reasonably functional UI. Doesn't do very well at handling multiple displays, but aside from that it gets the job done with less cursing than I typically apply to Python. Also the IrScrutinizer project, which I use from time to time.

OTOH I've seen some really awful Java UIs too, mostly in embedded-systems IDEs from companies that ought to know better.

Re: (Score:2)

by ArchieBunker ( 132337 )

I still don't understand why the Arduino IDE won't allow you to put spaces in filenames. My OS supports it so what's their excuse?

Re: (Score:2)

by Mr. Dollar Ton ( 5495648 )

Arduino's IDE has about the abysmalest UI one can imagine. Even QBasic wasn't that bad. Luckily, it is so featureless that it can be swapped out for a 5-line Makefile and your favourite text editor.

Re: (Score:3)

by znrt ( 2424692 )

applets and what you call "java ui" are not really the same.

applets/japplets had their place as interactive widgets in the browser. their main problem was the distribution of the runtime, jre (which was indeed a miserable experience), and the slow startup due to the jvm initialization. anyway, there weren't many alternatives either: ms ocx/vcx/activex controls were proprietary and limited to ie, js was still truly barebones and lacking support and compatibility, a few other exotic alternatives had less supp

Re: (Score:2)

by karmawarrior ( 311177 )

Applets were a problem for a variety of reasons. The JVM at the time was buggy, Netscape was buggy, and the combination of the two could lead to crashes. Additionally several bugs in the JVM were actual security holes giving Java an unfair reputation for poor security (it wasn't Java or Java's design, it was a crap implementation.) And I don't think browser makers ever quite embraced the idea despite believing early on that Java was "the future".

In part, the latter was because of a combination of Microsoft

No (Score:2)

by Equuleus42 ( 723 )

I do not like this Sam-I-am, I do not like the JVM.

Re: (Score:2)

by Marc_Hawke ( 130338 )

Is there an actual JVM here? Looking at what TeaVM does, it seems it's more of a 'cross-compiler' (if that's a term, post says 'transpiles'), and it allows you to write JAVA but compile it to JavaScript (WASM). (Which are famously 'not the same thing.')

So, it's for JAVA programmers who don't want to learn JS? The deliverable seems like a monolithic, minified, partially obfuscated text file?

No. (Score:4, Informative)

by Gravis Zero ( 934156 )

> it seems it's more of a 'cross-compiler' (if that's a term, post says 'transpiles')

Both cross-compilers are transpilers exist and are different things.

* A cross-compiler compiles code on one platform but generates and executable for a different platform. Example: building an ARM64 executable on a x86_64 platform.

* A transpiler is a "translating compiler" which translates code from one programming language to another. Example: Java source code to Javascript source code.

> So, it's for JAVA programmers who don't want to learn JS? The deliverable seems like a monolithic, minified, partially obfuscated text file?

Maybe but it's a near certainty that people will target WASM. WASM is bytecode that has many similarities to assembly language, so it's likely to be binary blob.

Yes, it will almost certainly be a monolithic, until someone starts hosting the myriad of Java platform libraries.

Re: (Score:2)

by BKX ( 5066 )

In this case, I think it's both. When it compiles to JS, it's a transpiler. When it compiles to WASM bytecode, it's a cross-compiler. Yahtzee!

First "this is a shameless slashvertisement" post? (Score:2, Insightful)

by Bodrius ( 191265 )

The small bit of nerd news is shadowed by the press release as comment.

Re: (Score:2)

by znrt ( 2424692 )

this!

is!

slashdooooooooot!!!!!!!!!!

This just happened now? (Score:2)

by supabeast! ( 84658 )

This is the first time I've heard about Java applets in over a decade. I just sort of assumed that they went away along with the rest of desktop Java when Apple dropped the JRE from MacOS and people used that as an excuse to ditch Java.

Wasm is a joke (Score:1)

by RightwingNutjob ( 1302813 )

Needs a mountain of javascript glue code to access the DOM...and the javascript glue code has to be literally doing bit swizzling and byte swapping on the vm's memory space.

Oh to think of a car analogy...

Re: (Score:2)

by PPH ( 736903 )

> to access the DOM

the DOM? There's only one?

This is what we lost when native Java support went away. Not everything is a simple tree.

Why should I choose java for my next project? (Score:2)

by Yxven ( 1100075 )

I'm honestly asking. I used java for my first real programming project 20 years ago. It was kind to me, but my most recent java attempt (which wasn't particularly recent) made me feel like even though the language has improved, the ecosystem still feels clunky with all the classes you need to create to do anything. Since then, I've generally felt like C# has the momentum (but I haven't seriously tried that one yet). Why should I choose java over C#?

Re: (Score:3)

by znrt ( 2424692 )

today you probably shouldn't, because oracle and because, as you say, java has been overengineered to absurd levels since even before oracle took over.

however, if you need linux support java is probably still a better alternative than c#. true multiplatform has always been java's strongest point. besides, there are many other alternatives. python for example has great momentum too and is quite "kind" and easy to get into. what kind of project do you have in mind?

Re: (Score:2)

by TheDarkMaster ( 1292526 )

The trick is that you don't need to be a purist for object usage, and you don't really need to create tons and tons of abstraction classes to do what you want. These are mistakes made by stickler Java users who, as another commenter rightly put it, overengineer things. You should only use the level of complexity necessary for what you intend to do and fortunately Java allows this, even though you see very little of it in the examples that appear on the internet.

Re: (Score:2)

by karmawarrior ( 311177 )

C# is a better language over all. Java has suffered for a variety of reasons:

- An insistence on backward compatibility, which is why, for example, generics are kinda half-assed, the standard library has lots of gotchas as functionality was grafted on poorly.

- Apparent confusion of "slowly" with "carefully" which means many features are missing decades later, and what finally gets in there seems to be half a solution, as if the Java team wants to see whether it works before finishing it. The "AutoCloseable"

Re: (Score:2)

by Snotnose ( 212196 )

Try Kotlin. Fully compatible with Java, works fine with Java libraries, and it doesn't have all the boilerplate of Java. I had a love/hate with Java, but it's love/love with Kotlin.

Auto-Obfuscation? Yes please! (Score:2)

by DeanonymizedCoward ( 7230266 )

> It includes a minifier, to shrink the generated code and obfuscate the intent, to complicate reverse-engineering.

Yes, I'd my machine to run even more deliberately-obfuscated code, preferably written by an idiot for the lowest bid and then obfuscated by a machine until no one, least of all the author, knows what the hell it's doing.

Re: (Score:1)

by supabeast! ( 84658 )

Was that a dig at Windows?

Java has no business in the browser (Score:2)

by 93 Escort Wagon ( 326346 )

Applets may only now be going away officially, but fortunately most people wised up and stopped using Java for the web many years ago.

[1]Java Script [wikipedia.org] is unrelated to Java, but it sounds the Java folks are apparently hoping they can somehow [2]retcon [wikipedia.org] that.

[1] https://en.wikipedia.org/wiki/JavaScript

[2] https://en.wikipedia.org/wiki/Retroactive_continuity

Re: (Score:2)

by karmawarrior ( 311177 )

WebAssembly means that, no, Javascript is not the only language available for manipulating web pages on the client side any more, it can be anything you want. If Java is ready for that, and programmers want to use Java, there's no reason they shouldn't - it's a safer, more robust, language than Javascript. Of course, they can also use Rust, Go, or a whole host of other languages.

Also, FWIW, applets have been dead for a decade or more now, no mainstream web browser has supported them since 2017. The article

Re: (Score:2)

by karmawarrior ( 311177 )

> and programmers want to use Java

Is meant to read

> and if programmers want to use Java

*sigh* Second time today.

Write once, run anywhere - NOT (Score:2)

by itsme1234 ( 199680 )

It's been a sh*show beyond belief with the applets, JNLP, stuff requiring older Java, browsers disabling support and all kinds of ancillary nonsense. Office for NT 4.2 (the first 32 bit one) runs on modern Windows with no shenanigans and it comes from more than 30 years ago. But nope, some older java is blocked beyond belief. They pulled even the Internet Exploder from Windows 10 with some update (WTF?).

Eventually the most straightforward way to run some Java code needed to manipulate some hardware ended up

I don't think 'It's better than hurling yourself into a meat grinder'
is a good rationale for doing something.
-- Andrew Suffield in
<20030905221055.GA22354@doc.ic.ac.uk> on debian-devel