Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
Java

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

Posted by EditorDavid from the Java-vs-Tea dept.
"The entire java.applet package has been removed from JDK 26, which will release in March 2026," notes Inside Java.

But long-time Slashdot reader AirHog links to this blog post reminding us that "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. 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 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."

Applets Are Officially Going, But Java In the Browser Is Better Than Ever More | Reply

Applets Are Officially Going, But Java In the Browser Is Better Than Ever

Comments Filter:

  • Good riddance (Score:3, Insightful)

    by backslashdot ( 95548 ) on Saturday December 13, 2025 @06:31PM (#65856661)

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

    • 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.

      • 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?

      • 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:2)

        by tlhIngan ( 30335 )

        That's because Java itself didn't get a native GUI toolkit until late late late in its life. Things like Swing and such were GUI toolkits, but it never looked native so you could always tell. These days it looks native because there are native GUI toolkits you can use where a Java app will look like it always was a Windows app on Windows, a macOS app on Mac, and ... something on Linux.

        Of course, there was a native toolkit available - the web browser, which is why most apps started moving that way. Java appl

    • Re:Good riddance (Score:5, Informative)

      by znrt ( 2424692 ) on Saturday December 13, 2025 @08:27PM (#65856821)

      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 support still. if you needed a serious multiplatform solution for advanced ui/and logic in the browser applets were actually the only real option, and it worked very well for specific needs. heck, i even used applets without any visible ui, as a built in local server in the browser to do processing. eventually it all got washed away by js+html (and worker threads) once it evolved enough.

      "java ui" is/was a superset of that and for many years was the most solid multiplatform alternative for desktops. and swing in particular (the second iteration, after awt) is actually quite cool and a powerful comprehensive ui library with everything from proper event handling to a flexible layout system (actually quite a few, although there was nothing you couldn't do with gridbaglayout), support for mvc, component specialization, themable and whatnot, plus a huge general purpose standard library below (crypto, io, databases, networking, math, whatever). ofc it had a few quirks and some people hated it, mostly for the non-native looks, but i did a few apps where you wouldn't know they were developed in swing. all in all it was the best multiplatform option available, by far, for many years. qt was probably the only serious alternative, and it also had odd looks and didn't have a standard library. which is why "java ui" (as opposed to applets) is still used today and has a huge legacy that will be around for a good while, despite oracle (which is saying something).

    • 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

    • yea, it had it uses, but as always people decided to use it for wrong reasons, done it poorly, then blamed it all on the lang. No one was forcing people to use applets for UI, UI could be written in HTML with some JS to interface the applet for actual heavy lifting, like reading smartcards via custom native code or some other wierd protocols.
    • People didn't like embedded FLASH first.

    • Jetbrains would disagree.

  • No (Score:2, Funny)

    by Equuleus42 ( 723 )

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

    • 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:5, Informative)

        by Gravis Zero ( 934156 ) on Saturday December 13, 2025 @07:56PM (#65856791)

        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:3)

          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!

          • When it compiles to JS, it's a transpiler. When it compiles to WASM bytecode, it's a cross-compiler.

            1) It's directly compiling to bytecode which makes it a bytecode compiler.
            2) Bytecode is an intermediate representation, not specific to any hardware, thus excluding the bytecode compiler from being a cross-compiler.

            see also:
            * https://en.wikipedia.org/wiki/... [wikipedia.org]
            * https://en.wikipedia.org/wiki/... [wikipedia.org]
            * https://en.wikipedia.org/wiki/... [wikipedia.org]

            • What if you translate from one bytecode to another? eg into MMIX bytecode.

              • That would be binary translation [wikipedia.org] which is a type of recompiler [wikipedia.org]. Binary translations can be done using either static or dynamic recompilation.
                * A static translator completely translates the binary to the new target, fully resolving addresses.
                * A dynamic translator [wikipedia.org] partially translates the binary to the new target, caching sections but not all addresses are not fully resolved.

                Since bytecode is an intermediate representation [wikipedia.org], it can easily be easily be fully translated using static recompilation as addressing

              • BTW, if you are talking about this MMIX [wikipedia.org] then you wouldn't be translating to another bytecode but rather, MMIX's machine code. [hm.edu] Translating from bytecode to machine code is compilation. This can be done ahead of time to simply generate a usable binary using a compiler or it can be done at runtime via just-in-time compilation.

                • Thanks for the (two) replies. Yes, I was confusing bytecode and machine code, or rather, I was thinking of two potentially different machine codes with isomorphic instruction sets, but potentially different resource availability (RAM, number of registers).

                  • Just FYI, I'm unaware of a fully static recompiller due to:
                    1) address calculation issues with indirection
                    2) data modification requirements

                    I've seen one static recompiler but it was naive at best and failed entirely when it came to dynamically generated instructions. There are also other issues regarding assembly language tricks like using the operand of an instruction as an instruction by directly jumping too it. This is a neat trick that occurs in Super Mario Bros. for NES.

                    Static recompilation is an are of

            • I disagree with the interpretation that bytecode is some kind of in-between thing. Bytecode is the machine language for an abstract machine (the VM) which is basically emulated on every machine that has an implementation. Look at Java bytecode. There's have been actual physical CPUs that directly run Java bytecode. So Java bytecode is the machine language for those machines. The JVM just emulates those machines. The fact that it does that with JIT binary translation doesn't change it from being an emulator.

      • Re: (Score:2)

        by rta ( 559125 )

        Before WASM there was asm.js (https://en.wikipedia.org/wiki/Asm.js) which is an efficient subset of js used as a target for "transpilers". Yes it's "code" is legal javascript, but it's not something people would actually write to.

        as to TeaVM it describes itself well as:

        TeaVM is an ahead-of-time compiler for Java bytecode that emits JavaScript and WebAssembly that runs in a browser. Its close relative is the well-known GWT. The main difference is that TeaVM does not require source code, only compiled class files. Moreover, the source code is not required to be Java, so TeaVM successfully compiles Kotlin and Scala.

        As to why you'd want to use one... well maybe you want to package existing logic. Or you just want to write some complex stuff but not deal w/ the hell that is maintenance of a large JS project. and by "some complex stuff" i mean

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

  • 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.

  • 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.

      • well there's the entire multiverse of DOMs and can live happily in just one browser tab. It's nice to have options, it just doesn't mean one needs to use all of them all at once

  • 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:Why should I choose java for my next project? (Score:4, Insightful)

      by znrt ( 2424692 ) on Saturday December 13, 2025 @08:43PM (#65856839)

      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?

      • Python is always my go to whenever I want to actually get work done quickly (probably due to familiarity), but haskell really made me love strong types. I believe that projects built using strong types are the least work to support long term.

        If I were to start another programming project, it would probably be a turn based strategy game. I'd want to be able to support desktop/web/mobile. I'd care the least about web, but it's easiest to get strangers to give you feedback on a prototype if they don't have to

        • Re: (Score:2)

          by znrt ( 2424692 )

          i had no idea that libgdx existed :-).

          in that case i would have a go with godot, i think it covers your requirements. it's a bit idiosincratic and quirky but it's so light and fast as a tool that it's really a joy to work with. by the time unity finishes loading you might already have coded and tested a prototype with godot. i've only used it with gdscript, though, and while that's not really a full fledged and mature language it does the job for me. form what you say you might probably prefer to use it wit

          • This conversation made me look at libgdx again. It looks like it's alive and kicking. I loaded some guy's game jam game on my phone almost instantly. The community definitely seems smaller than godot's, but the project sounds mature (and it's web version is working, unlike godot 4's).

            Maybe, I actually should consider java for my next project, but that's a problem for future me. I'm stuck in the idea phase.

    • 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.

      • My latest experience with it (which is pretty old at this point) suggested that while I could keep my code reasonably sane, if I wanted to use any standard library, I had to implement all sorts of abstract classes to do something that would be handled by passing a call back function in other languages.

        Has the general ecosystem improved much since then?

        • It depends on the library or function you're trying to use. What I wrote before applies more to the code you're trying to write: When you use a third-party library, you're usually bound to use it in the way the author implemented it.

          As an example, I saw two distinct ways to create a PDF file, done using two different libraries. The first requires a lot of configured "factory" classes and unnecessary abstractions, while the second only requires you to create an instance of the class and then execute a sin

    • 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"

      • - An insistence on backward compatibility,

        That's one of the main reasons I continue using Java. When you have projects that literally last for decades, you can't have them dependent on "trendy languages" that break things all the time.

        • C# takes a different approach, you target a specific .NET framework rather than "C#". That way it's been able to develop, but backward compatibility is still a thing.

          I think at some point Oracle or Sun should have released a "Java 2" which included the lessons learned from the first iteration. No backward compatibility issues because Java 1 would still be a thing, but Java 2 could have fixed the holes and ensured the language had the features that are currently half-assed.

          • Isn't that what Kotlin and Scala and the half a dozen new JVM languages we see per year are all about? Take the decades of investment on the JVM and the lessons from java, start clean and keep interoperability at bytecode level...

          • It won't work. If you target a specific version of the framework (or JVM in the case of Java), you'll end up with several different versions of it having to run on the same client machine, with the risk that one won't be able to coexist with the other. Of course, if you have a dedicated machine for your system, you can focus on a specific version, but even then you'll end up missing out on security fixes from newer versions of the framework, not to mention the extra work for developers in having to maintain

    • Re:Why should I choose java for my next project? (Score:5, Interesting)

      by Snotnose ( 212196 ) on Saturday December 13, 2025 @11:36PM (#65856979)
      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.

    • Re: (Score:2)

      by bsolar ( 1176767 )

      Why should I choose java over C#?

      Depends on what your project is about. If you are doing a learning project there are good reasons to learn Java-based solutions, regardless of how better or worse other solutions are.

      Java is a very mature language with a lot of career opportunities especially in large enterprises. If you get involved in the backend stack of a financial company there is a very good chance you will work with Java. If you are starting a project to learn something that might help you in your career and have a feeling your caree

      • Re: (Score:2)

        by cowdung ( 702933 )

        I our company we do jobs in both Java and .Net.

        We have more demand for Java backends than we have for .Net.

  • 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.

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

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

    • 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

      • > and programmers want to use Java

        Is meant to read

        > and if programmers want to use Java

        *sigh* Second time today.

    • oh you troll you ... JavaScript was named after Java, just for marketing

  • 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

    • While in the past it seemed like Java would run anywhere, from clients to servers, and even the occasional smart card, today most Java VMs are now SIM cards. While not an official part of the standard, SIM cards commonly provide a Java VM so operators can use the SIM toolkit without having to port their software to every single SIM vendor. Essentially this allows operators to have a more fine grained control over things like carrier selection on roaming, or formating numbers for outgoing calls. In some coun

  • The point is that running code in your browser is a very dangerous and highly abused idea. It was back when Java Applets or Active X components were around, and it still is with all the "ad/surveillance" ecosystem draining our batteries.
    Yes, there are use cases for this, but it seems to me that abuse of it is now much greater than any useful use. And even the seemingly sensible use cases seem like they make everything worse. Just look at Jira, for example. Pages take ages to load.

  • Another alternative is my browser extension [mozilla.org] that emulates the Live Connect [oracle.com] aspect of Java Applets. Live Connect let Java call JavaScript and JavaScript call Java using normal fuction calls. My extension doesn't do Applet Graphics, but they sucked anyway.

    It's a good way to use a browser as the UI of a Java app. The Java app has more speed, permissions, and type-safe object-orientation, while the browser side can leverage the many browser UI libraries.

Slashdot Top Deals

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

Close