Java Geeks Discuss 'The War for the Browser' and the State of Java Modularization (frequal.com) 67
Self-described "Java geek" nfrankel writes:
At the beginning of 2019, I wrote about the state of Java modularization. I took a sample of widespread libraries, and for each of them, I checked whether:
- It supports the module system i.e. it provides an automatic module name in the manifest
- It's a full-fledged module i.e. it provides a module-info
The results were interesting. 14 out of those 29 libraries supported the module system, while 2 were modules in their own right.
Nearly 2 years later, and with Java 16 looming around the corner, it's time to update the report. I kept the same libraries and added Hazelcast and Hazelcast Jet. I've checked the latest version...
Three full years after that release, 10 out of 31 libraries still don't provide a module-compatible JAR. Granted, 3 of them didn't release a new version in the meantime. That's still 7 libraries that didn't add a simple line of text in their MANIFEST.MF
Meanwhile, long-time Slashdot reader AirHog argues that "Java is in a war for the browser. Can it regain the place it once held in its heyday?" All major browsers have disabled support for Java (and indeed most non-JavaScript technologies). Web-based front-ends are usually coded in JavaScript or some wrapper designed to make it less problematic (like TypeScript). Yes, you can still make websites using Java technology. There are plenty of 'official' technologies like JSP and JSF. Unfortunately, these technologies are entirely server-side. You can generate the page using Java libraries and business logic, but once it is sent to the browser it is static and lifeless... Java client-side innovation has all but stopped, at least via the official channels....
How can Java increase its relevance? How can Java win back client-side developers? How can Java prevent other technologies from leveraging front-end dominance to win the back-end, like Java once did to other technologies?
To win the war, Java needs a strong client-side option. One that lets developers make modern web applications using Java code. One that leverages web technologies. One that supports components. One that builds quickly. One that produces fast-downloading, high performance, 100-Lighthouse-scoring apps. One that plays nicely with other JVM languages. What does Java need?
Spoiler: The article concludes that "What Java needs Is TeaVM... an ahead-of-time transpiler that compiles Java classes to JavaScript."
- It supports the module system i.e. it provides an automatic module name in the manifest
- It's a full-fledged module i.e. it provides a module-info
The results were interesting. 14 out of those 29 libraries supported the module system, while 2 were modules in their own right.
Nearly 2 years later, and with Java 16 looming around the corner, it's time to update the report. I kept the same libraries and added Hazelcast and Hazelcast Jet. I've checked the latest version...
Three full years after that release, 10 out of 31 libraries still don't provide a module-compatible JAR. Granted, 3 of them didn't release a new version in the meantime. That's still 7 libraries that didn't add a simple line of text in their MANIFEST.MF
Meanwhile, long-time Slashdot reader AirHog argues that "Java is in a war for the browser. Can it regain the place it once held in its heyday?" All major browsers have disabled support for Java (and indeed most non-JavaScript technologies). Web-based front-ends are usually coded in JavaScript or some wrapper designed to make it less problematic (like TypeScript). Yes, you can still make websites using Java technology. There are plenty of 'official' technologies like JSP and JSF. Unfortunately, these technologies are entirely server-side. You can generate the page using Java libraries and business logic, but once it is sent to the browser it is static and lifeless... Java client-side innovation has all but stopped, at least via the official channels....
How can Java increase its relevance? How can Java win back client-side developers? How can Java prevent other technologies from leveraging front-end dominance to win the back-end, like Java once did to other technologies?
To win the war, Java needs a strong client-side option. One that lets developers make modern web applications using Java code. One that leverages web technologies. One that supports components. One that builds quickly. One that produces fast-downloading, high performance, 100-Lighthouse-scoring apps. One that plays nicely with other JVM languages. What does Java need?
Spoiler: The article concludes that "What Java needs Is TeaVM... an ahead-of-time transpiler that compiles Java classes to JavaScript."
The agenda ... (Score:1)
Re: (Score:2, Insightful)
And consume all available RAM while doing it...
Re: (Score:1)
This is nonsensical! (Score:4, Insightful)
"How do we make this screwdriver a better socket wrench"?
These are tools. You don't go chasing different jobs for the sake of promoting a particular tool. That's almost the definition of putting the cart before the horse. If there are excellent client side syntax and interpreters for a class of cases, the worst use of engineering hours is to adapt another, less suitable language perform the same work with additional complexity.
My professional career has spanned a bit more than the life cycle of Java to date. I've seen other technologies come and go, in that time. It's reasonable to see that Java, having once spilled into many niches, will last decades into the future as a business computing language that superseded COBOL. Meanwhile, many things that Java inspired or suggested became a part of newer tools, better suited for web clients or simply more fortuitous in timing.
The conclusion is, if you want to develop client-side libraries and applications, work in JS, instead of extending the wrong tool for the wrong job.
Replacement percentage (Score:1)
We are stuck with Java, C# and C for the foreseeable future for all but web client work.
That's better than doom on the horizon for today's JavaScript framework of the year - Angular. Try hiring someone knowledgable to work on the hot JS frameowrk of 4 years ago link Knockout.
Staffing risk is the elephant in the room. One learns that when they work on large systems older than 2 years.
We'd do well as the Yogi consultant said:
- When you've reached the top of the mountain, you cannot say 'it's easy to climb t
Re: (Score:2)
Do you remember the kind of garbage we had to use for Web server work before we had popular managed languages? (In my world, mostly CGI scripts using Perl, then PHP, long before it became truly usable). I'm absolutely fine with C# for server-side work. Java and Python, too although neither would be my first choice. Perfect, no, but certainly a huge leap above the stuff that ran the first decade or so of the Web.
OTOH, I'm not sold on huge Javascript frameworks. None out there that I know of that even at
Re: (Score:2)
The conclusion is, if you want to develop client-side libraries and applications, work in JS, instead of extending the wrong tool for the wrong job.
Javascript is the wrong tool for the job. Unfortunately, it's also the only tool available at the moment.
Re: (Score:1)
TeaVM works with web technologies, it doesn't attempt to create an alternate UI.
* HTML for content
* Styling via CSS
* DOM access
* Web API access
Just the logic is implemented in Java. Or another JVM langauge, if that is your preference. The force multiplier is coding front-end and back-end logic in the same langauge. IDE refactorings apply to the entire project. And SAST/DAST tools can be applied everywhere, a big when for larger projects.
Before you knock it, be sure to try it. It is just 2 quick steps:
What problem is it trying to solve? (Score:1)
Why would java be more attractive than the tools already in place? Learning javascript isn't particularly onerous, neither are the various libraries and frameworks all that difficult to work with. So how would adding Java to that mix make things better?
Re:What problem is it trying to solve? (Score:5, Informative)
It allows lazy programmers to continue working in the one language + frameworks they already know instead of learning the language + frameworks most suited to the job at hand.
We see this all the time. Have a lot of JavaScript programmers? Well obviously, we need some way of writing desktop apps in JavaScript, because heaven forbid we have to learn a new language. Cue Electron. Pay no mind to the dozen layers of unnecessary abstraction, gigabytes of wasted memory, and CPU cycles flushed down the toilet.
Re: (Score:2)
I use VS Code for C++ programming, without using all the extension bells and whistles. Compared to Eclipse, it feels more lightweight for a cross platform edi
Re: (Score:2)
Re: (Score:2)
Because Java is a far far better language than Javascript.
Yes, someone had to say it.
The year 2000 called... (Score:1)
Dead Simple (Score:4, Informative)
Re: (Score:2)
That's what TeaVM ( http://teavm.org/ [teavm.org] ) does. However, it has several advantages over Blazor:
* Uses JavaScript instead of WASM (big speed advantage)
* Only bundles the needed classes instead of a whole runtime (startup time advantage)
* Actual threading support.
For a full analysis of TeaVM's benefits over Blazor WASM:
https://frequal.com/java/TeaVm... [frequal.com]
Re: (Score:1)
And browsers are the new IBM 3270 terminals. I don't know which suck worse: Java or browser "standards".
Re: (Score:1)
These guys are deluded (Score:3)
Modules in Java are unused because they just complicate things needlessly, while providing nothing of value. The motivation for them was apparently to split the JVM to make it more "agile" for container deployments or something. And of course, JVM has not become any more agile or popular. Contrast this with Go modules, they were introduced 2 years ago and pretty much all projects has switched to them.
Meanwhile, Oracle has shown itself incompetent with projects that actually can give Java a new life. For example, project Loom that aims to bring lightweight threads to JVM is so far 3 years late. True ahead-of-time compilation proposals have stalled, with only a half-useful AOT caching being delivered.
Re: (Score:2)
There's a few good things that modules provide. For example, allowing a module to hide its internals better so that callers don't depend on implementation details. But those things don't really benefit the library implementer, so doing it isn't high priority.
It also assumes the user is on a recent version of Java. Android has actually managed to splinter Java a bit- it's permanently stuck on Java 8, and unlikely to ever move forward. So you have a choice- support Android and stick to Java 8 (which does
Re: (Score:2)
There's a few good things that modules provide. For example, allowing a module to hide its internals better so that callers don't depend on implementation details. But those things don't really benefit the library implementer, so doing it isn't high priority.
This honestly is not a big deal in reality.
It also assumes the user is on a recent version of Java. Android has actually managed to splinter Java a bit- it's permanently stuck on Java 8, and unlikely to ever move forward. So you have a choice- support Android and stick to Java 8 (which doesn't have modules), or drop Android and have an unending stream of disappointed users.
Well, another reason to blame Oracle. Not that Android actually needs most of "regular" Java libraries.
Re: (Score:3)
How big is your app and how many people are working on it? If you're working on a small app, its utility is near 0. If you're working on a large monolith that has several hundred devs of various skills, it can be a life saver. I've had several times where devs in other parts of the app decided to depend directly on my ORM models and their assumptions made my life difficult.
It's a nice to have an was a good addition to the language. I use it where available. But
Re: (Score:2)
modules
Even as an admitted Java fanboy, this just makes me cringe.
I watched a talk several month ago where someone was still beating the dead horse of jigsaw, and even they were forced to admit multiple times through the talk that there are still significant problems that make actually using these features completely impractical.
At this point, the community has already solved most of the problems that the java module system might have helped with. Its a poorly thought out feature that doesn't really work and doesn
Re: (Score:2)
You're talking about modules, but your comment applies to lots of things that have happened to Java since Java 8. Modules are a PITA to actually use. We really didn't need 73 new variations of the Switch statement. Etc.. Oh, and removing JavaFX from the Java core? Java finally has a GUI framework that works decently well, so they dropkick it i
Re: (Score:1)
The fact that developing with the official Java UI technologies is becoming more challenging is one of the exciting things about TeaVM. It compiles to HTML and JS, which deploy like any other website. Any web API is available. And it checks all of the boxes you want from a web development tool:
* fast
* produces compact JS
* produces great Lighthouse scores
* works great with the latest web tech (Flexbox, SPA, PWA, etc.)
Definitely give it a shot, the "Getting Started" instructions will have you up and runnin
Re: (Score:1)
Re: (Score:2)
Modules in Java are unused because they just complicate things needlessly, while providing nothing of value.
It's so much that there's nothing of value but it's one of those features that's very valuable for large industrial-strength libraries and projects, and especially the Java runtime libraries, and of small value to everyone else. The real downside is that, like every new feature of Java, they've made migration and backwards compatibility too easy, and people end up with the unnecessary complication of a mix of the old and new.
Google Web Toolkit? (Score:4, Informative)
Re: Google Web Toolkit? (Score:2)
Why? Just to keep Java users from having to learn JavaScript?
Seriously. I went from a big-ass Spring GWT implementation that had 100,000 lines to support a handful of web pages to a NodeJS/Handlebars platform that supported hundreds of pages in 10,000 lines. And no lengthy compile!
Wasn't it to provide type safety? (Score:4, Informative)
I can't imagine anyone working on a team too big to fit in a minivan wanting to mess with an uncompiled language, but to each his own. Java has many flaws, but most who seek to replace it seem to never learn from the past.
Rant aside, GWT was sold as a way of having a highly structured UI codebase that integrates with the backend and is highly knowledgeable of the lower tiers. Did it succeed? I honestly have no idea. I was using JSF during the GWT heyday...a front end framework with a few amazing features, but was far too complicated and intimidating for a new user and was very much from the EJB school of overengineering Sun was famous for. It was convoluted, but heavily standardized and worked well from cross-continent large teams like the ones I've worked on. GWT stunk of Google's "fuck working with other people, we're fucking Google, standards don't apply to us...let's reinvent the wheel because we're Google. Who needs 20 years of real world jobsite experience, we'll just reinvent the wheel in a total vacuum, the Google way!"
To be honest, UI developers are the most undisciplined lot I've ever worked with and have the shortest attention span. I think any technology is doomed to fail if the UI folks get their hands on it. They never seem to understand the notion of backwards compatibility or paying customers or business needs...just fun experiments in reinventing the wheel. Our backend investments? Great...Work done 10-20 years ago is still running with little maintenance. Our front-end investments? We have about 100 UIs. The oldest is almost 3 years old and is already scheduled for a rewrite. I don't mean a reskinning...a full rewrite and changing of frameworks where they throw everything away and redo it? In almost every case, they barely change the UI or flow...just rewrite with Angular or React or whatever the latest fad is.
A tangent? sure...but our oldest Java apps are still running after 20 years and actively maintained with much of the original codebase. Our oldest UI? 3 years and requires a full rewrite to use the latest Angular. Java has been a much better investment for my employer than the technologies that replaced iton the client side.
Re: (Score:1)
Re: (Score:2)
Different, not harder (Score:2)
Maybe programming a UI is just harder? I can imagine having to work with pesky users might be part of the problem. But yes, I've met the constantly shifting to the newest latest framework syndrome.
I started my career doing UIs. I do know it well, particularly the technologies from 10 years ago, when there were less frameworks out there to help you with cross-browser capabilities. It has different challenges, such as more rapidly shifting requirements, but really there is a massive quality difference between the work I've seen the average backend vs front end developer do. Even at first impression, the UI guy is more likely to be fashionable, young, and a hipster...more conspicuous tattoos, wild cr
Re: (Score:2)
It's hard work. The bar constantly changes with advances in form factors and paradigms, and the quality bar also constantly advances. The underlying technologies tend to have rapid churn, requiring large amounts of maintenance time just to stay alive, never mind adding new features or improvements. Inherited applications often contain far less than adequate separation of concerns (e.g., SQL in the UI layer and vice versa). Doing Web front ends means either writing tons of JS, or using a framework-of-the
Re: (Score:1)
GWT is slow to compile and limited to an old version of Java source code.
TeaVM, by contrast, starts with Java bytecode, making it far more flexible, adapting easily to new versions of Java and other JVM-based languages.
TeaVM ( http://teavm.org/ [teavm.org] ) takes the premise of GWT (wouldn't it be great if we could write browser-based apps in a JVM langauge?) and makes it reality. .
* Fast build times
* Small compiled JS size
* Excellent Lighthouse scores
* HTML/CSS-friendly toolkit (Flavour)
Re: (Score:1)
GWT intended to kill Java in the browser, and it succeeded.
No framework did more to kill Java in the browser than GWT. Unnecessarily complex, incompatible with anything on the market by the late 00's, lots of undelivered promises and way too slow to compile... it cemented the idea that anything Java related on the browser was a bad idea to begin with, and it spawned a lot of children frameworks and languages that just ran away from it.
It even managed to deprecate the previous Java technology stack of Swing,
"Java is in a war for the browser" (Score:2)
AirHog is assuming the wrong thing. Java lost its place in the browser about a decade ago. It's not in a war at all and will not regain the place it (badly) held in its heyday. I'm not sure what rosy view AirHog has about the web from a decade or two ago, but Java was the bane of older websites, with the fucking JVM slowing down the browser, slowing down navigation o
Re:"Java is in a war for the browser" (Score:5, Insightful)
Re: (Score:1)
TeaVM does away with the need for a JVM in the browser, so it neatly avoids the problems with startup time and "gray rectangles" that caused pobelms back in the applet days.
It compiles Java bytecode into compact, quick-downloading JavaScript. No JRE, JVM, or Java Plugin required. Just a standard browser with JavaScript enabled.
Re: (Score:2)
So the big question is, when is Java no longer Java? If people keep compiling other languages into Javascript, doesn't it all just become Javascript?
Java lost because the Java ecosystem is terrible (Score:2)
Yes, you can still make websites using Java technology. There are plenty of 'official' technologies like JSP and JSF. Unfortunately, these technologies are entirely server-side.
And most people aren't doing that any more. You know why? Because the Java tools to do so are terrible.
JSP is built on top of Java Servlets, which are this weird API that's designed to be protocol agnostic. That is, it's designed so that instead of just HTTP it could also support protocols like Gopher or FTP or SMB. JSPs are also sort of file type agnostic, instead of generating HTML they're designed so that they could generate any text file. (I think in theory they could also generate binary data but I'm n
Re: (Score:2)
Re: (Score:2)
I'm not gonna claim that Java is going anywhere on the frontend soon, but you're tremendously wrong about Java on the backend. No-one has been doing JSP for 10 years or more, but Java remains a force for implementing services.
And having worked with npm, nvm, python and Visual Studio downloads, yarn, webpack, grunt, gulp, less, sass, bower, mocha, jest, wallaby, karma....
to be honest, maven seems like a simpler and more consistent solution.
Managing Java is not a pain at all. Just use the right tool for the
Re: (Score:1)
For the millions of developers still using Java and maven to develop services, TeaVM fills a vital need -- a Java-friendly front-end tool for developing modern browser apps.
* Share models (POJOs) between front- and back-ends.
* Refactorings apply top-to-bottom. No more having to remind the front-end team you just changed the service interface Refactor the POJO, and the references client-side get updated too, automatically!
* TeaVM's Flavour toolkit includes automatic marshaling and unmarshaling to/from JSON,
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
The tool to use it (Maven) is massively overcomplicated and it's best to use an IDE to abstract most of the details.
I was with you until this point. Maven isn't complicated unless you make it so.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
I actrually worked at a company once where Oracle wanted to "Audit" us,, despite the fact to the best of our understanding there where no oracle products being used.
Boss told them if they stepped foot on the premise they would be "torn apart by hungry dogs" lol. Never heard back. Boss had a theory they thought we where another company.
Well damn... (Score:1)
TeaVM is for has-beens. (Score:1)
Re: (Score:2)
Did you forget Android? That alone will keep it both alive, and relevant, until such time as it is eclipsed (see what I did there?) with Kotlin, Xamarin, and the like. Which may or may not happen, although I certainly do hope that it will.
Having said that, though, I avoid Java for many of the reasons you stated, plus one that IMO is bigger than all of them combined: Oracle. A company with no redeeming values, and one that has demonstrated itself to be hostile, unpredictable, and dangerous, toward even i
Java doesn't want the browser (Score:2)
Re: (Score:2)
Oracle . . . my #1 reason for avoiding Java, though by no means the only one.
I used to be a strong Java advocate, back in the Sun days. I thought at that time its problems were fixable.
But then Oracle bought Sun.
There is no fixing Oracle.
And then Microsoft . . . . the Microsoft of 15 years ago . . . started to evolve C# toward what it is today: a cross-platform and open source language, more than competitive with Java in every important respect. Also transforming the Microsoft of 15 years ago into the fa
Java isn't winning battles (and there's no war) (Score:2)
Not sure why this was all smashed together. The first article was just looking at the state of module adoption in Java, which seems to be slow and it raised a question about how well the module standard works. Fine.
The second article is just a random opinion that tries to argue that Java needs to be relevant in a space in where it has never been more irrelevant and does so badly. It's just a plea to use a project (a transpiler for Java classes to JavaScript. Not even WebAssembly).
Java is just not a good cho
As someone who does IT MIS Support ... (Score:2)
... FOR THE LOVE OF GOD PLEASE KILL JAVA ON IE.
I have spent hundreds of hours going on 13 year old workstations to manually click on IE internet options to NOT PROMPT TO UPDATE JAVA on our 2008 era Oracle application. I have lost sleep, weekends, and got a poor performance review as I am going around working around an issue where the Java Indian developer put a instead of a = when checking a java version which throws an an exception. These PCs take 10 minutes to boot up as they are 10 years old so I have t
Re: (Score:2)
TeaVM doesn't require Java to be installed on any user's system. It turns Java into JavaScript so it runs in browsers without any Java plugin or JRE!
Even better, the JavaScript it produces is often smaller that that produced by other tools (like GWT or React). So it's even faster to start up and execute -- an improved experience for users over most web technologies.
So if you want to avoid Java deployment headaches, and make fast-starting, user-pleasing apps, definitely switch from legacy Java tech to TeaV
Re: (Score:2)
Re: (Score:2)
I'm sorry for your experience. In a past life, I was part of a team that had to endure something similar, although on a smaller scale.
Unless my family were starving, I would not take a job today involving hardcoded requirement for IE or for client-side Java.
While there remains tons of Java on the server side in most larger companies, I won't do that either, because Oracle.
I might do Java on Android, but only reluctantly, and only because, on that platform, there aren't a lot of other choices (though there
Re: (Score:1)
Crappy products are IT job security. Expecting everything to be logical and factored is a fool's dream. It's Dilbert-world out there.
And young users don't?
Java is an antiquated has-been. (Score:1)
Simply put, because it's a shit language? Front-end developers have better options, if you're the kind of person who thinks Java has any place in the front-end you need to get out more. Its type system is all at once too strict and not strict enough. The improvements we're seeing just now in Java 14 and java 15 have been in other languages for over a DECADE and so are almost rendered irrelevant, not just by the age factor but also by the fact that most companies are just now getting on Java 8 (which is a
Replace Java with Something Open (Score:2)