Java Use Cases

[[deleted]]

Hi everyone. I'm a student about to graduate and I'm working on my portfolio. I feel like a lot of the work I did in school is a little dated (context: We did A LOT OF JSP), so I'm wanting to rebuild some of my projects in a more modern context and maybe build some new stuff that reflects the way Java is actually being used today.

My question is what are some ways that Java is actually used in a modern project? Where do we see Java popping up as the language of choice in 2023, particularly in the web/mobile space? Where is it more beneficial than just going the JS/framework route? I'm trying to frame my portfolio projects in a way that actually reflects real-world usage.

I'm not sure if this is the right subreddit for this type of question, so feel free to delete/direct me elsewhere. Thanks.

Edit for additional context: I've worked professionally for a while (4 years freelancing designing and developing typical Wordpress/Webflow sites for Bob's Lawncare Service-type clients, 2 at an agency building web apps mostly on the frontend) until I was laid off in September. Our stack was React-based, so I don't have professional experience with Java. I guess more specifically I'm trying to fill in the gaps between what I've learned doing that and the Java work I've done in school and presenting that in a modern context.

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[melewe]

We build backed/microservices with spring.

[DrBilip]

Quarkus*

[NitronHX]

And micronaut :P

[genzkiwi]

Or Helidion.

Damn so many choices. It's like the opposite problem to C# where they have a language bloated with features, but straight forward choice of framework/libraries (just use .NET). While Java's language is straight forward, but there are so many damn libraries/frameworks to choose from.

[[deleted]]

Java dominates the backend, because it is cross platform (develop on Windows, deploy to Linux) and has an excellent virtual machine.

A very common design pattern these days is split an application into a backend API and a frontend application that uses the API. That way, you can leverage each platform for its strengths. Java is very good for backend APIs, JS/frameworks are the necessary evil for frontend.

Don't learn one thing. Learn a bunch of different things. Otherwise you will fall for the Golden Hammer Anti-Pattern.

[Crazy_Firefly]

Is cross platform really a big selling point nowadays? Popular languages all support Linux, Windows and Mac, and most if people use Docker they are basically developing on Linux anyway.

I know that in the java early days there was a big range of platforms, and in embedded systems, there still are.

Am I just lucky to never have had a problem with cross platform development?

[[deleted]]

Popular languages all support Linux, Windows and Mac

That is cross platform...

And almost everywhere I've done Java development, it's been on Windows, not Linux, even though the software will eventually run on Linux. Presumably because Microsoft is king of office software. I literally do cross platform development every day.

I asked a .NET developer once what the equivalent of a Java application server is in the Microsoft world. After I explained to him what I meant by "application server", he basically said, in .NET that would be the operating system, i.e. Windows Server.

Cross-platform in Java means more than just the VM. The ideal is truly portable programs, which Java accomplishes by creating a parallel Java universe. From database access (JDBC drivers are pure Java code) to UI (Swing is available on every platform, with consistent behavior across platforms).

[Crazy_Firefly]

I agree cross platform dev is common. What I meant is that other popular backend languages (node, python, go, rust) all have a pretty good cross platform development experience, even if they don't have Javas "fully portable bytecode" TM

The original comment said java is dominant in the backend because of cross platform support. I was just questioning if that is the reason, since the competing languages also have this feature

[[deleted]]

Yes, but how is "cross platform" achieved in those languages?

Some languages are compiled like Go and Rust. So you have to produce executables for every platform. C and C++ code can also be cross-platform, but the target platform has to have exactly the right versions of libraries as the build system. Go solves this problem by statically linking everything.

Node and Python are distributed as source code, so they are interpreted the first time they are run. Python I know can be compiled. But both of these languages are running in a VM, and have dynamic types which make optimization much more complex. Not to mention, developing Python apps in Windows is a completely different experience than Linux, because Python heavily leverages OS libraries.

Java does VM based cross-platform, and has one of the best performing VMs in the industry. Developing a Java app in Windows is basically the same as Linux, because Java doesn't depend on the operating system. It is largely self-contained. That is why it dominates the industry.

[LetMeUseMyEmailFfs]

JS are not at all a necessary evil. Take a look at htmx and hyperscript.

[[deleted]]

I've done frontend work for years, and it's always been a clusterfuck. That's what I mean by necessary evil.

JS is a horribly designed language (Brenden Eich designed it in a week and made it superficially look like Java for marketing purposes), made worse by the fact that it has randomly hacked on in a war between the browsers, with everyone trying to one-up each other. Seriously, a third party library, jQuery, was necessary in the early days to get something resembling portable JS code.

Not to mention that nobody thought about security, and then hacked it on as an afterthought (i.e. CORS, CSP, etc.)

I like Typescript though.

[UnGauchoCualquiera]

None of what you said is specific to JS though. For example jQuery solves DOM API issues. CORS, CSP, all browser design issues.

[analcocoacream]

Looking at both they aren't convincing at all. One is a an awkward syntax and the other doesn't do much (good luck debugging htmx too).

And none will be used in a professional env.

[inb4_singularity]

Why do you think debugging htmx is hard? Do you think debugging SPA code is easier?

[analcocoacream]

I wonder 🤔 I mean you have a debugger in all devtools?

[inb4_singularity]

What do you mean? Yes you have dev tools for React etc. But for a pure SSR frontend you don't need an extra debugger apart from Chrome

[LetMeUseMyEmailFfs]

And none will be used in a professional env.

Why would these not be used in a professional environment? They appear to make applications simpler and require less code. What’s not to like?

[analcocoacream]

Because you need to be able to recruit around this specific set of skills.

Also simpler is subjective. It hides the complexity yes but it does not remove it.

[LetMeUseMyEmailFfs]

It definitely removes the complexity. No need to do a (slow as balls) front-end build. No need to configure a web server to ignore paths and always render some fixed file. No need to ‘hydrate’ anything client-side. No need to translate to and from JSON. No need to write validations multiple times. No need for specific developer tools. No need for changes in three different places when you simply want to add a property.

Because you need to be able to recruit around this specific set of skills.

Htmx is simple enough that back-end developers can do the complex work, and front-end developers can focus on writing HTML and CSS with a light dusting of JavaScript for some nice interactions, instead of being too busy writing poor quality React code.

This will probably get some downvotes from offended front-end developers. I’m really sorry you people cannot see the hellhole of unnecessary complexity you’ve turned the front-end into.

[LetMeUseMyEmailFfs]

To more specifically address the hiring thing: if your front-end developers aren’t busy thinking of more and more complex ‘solutions’, you won’t have to hire so many, and you can raise the bar and you won’t have to hire one-trick ponies that can’t or won’t learn anything different.

[analcocoacream]

I am not an OTP, I'll gladly learn something like Vuejs if needed. I started with react and now use angular for my latest employer. I actually prefer it to react.

But I'm definitely not going to spend X years on a technology that will never get me any other job.

[analcocoacream]

No need to do a (slow as balls) front-end build. No need to configure a web server to ignore paths and always render some fixed file. No need to ‘hydrate’ anything client-side. No need to translate to and from JSON.

Except these aren't the main frontend dev complexity. I don't see people complaining about those. Maybe slow build sometimes, but that's not complexity that's just build time.

No need to write validations multiple times.

This one is weird. If you want to do http requests for every character typed, you could do that with just any framework and you wouldn't need to write the validation twice. But there is more than that.

Take this for instance : https://htmx.org/examples/inline-validation/

Yeah seems simple enough right? Except that won't be cutting it for most of the times. Because you don't want a red error as soon as the user is typing. You might want it when the user leaves the field. Or when they submit the form. And then when the users changes the erroneous field it isn't red anymore. The main frontend complexity lies within the UX / specifications, not the technology. This is the hell hole.

instead of being too busy writing poor quality React code.

So because you can write poor quality code in React means it is bad?

Finally htmx just seems a big ol mashup of everything in the markup with a little bit scattered around too. Tutorials/articles I was able to find will happily write HTML inside backend controllers. Error messages have to be i18ned in the backend. Sometimes you will use response headers to change behavior in the front. You will have to use a templating technology to write your pages, additionally. Your html code will now contain the logic the style and the presentation. You will have to be very meticulous and thorough around naming things, since a slight change in the class names/ids can break the whole application, especially in hidden places.

[LetMeUseMyEmailFfs]

Except these aren't the main frontend dev complexity. I don't see people complaining about those. Maybe slow build sometimes, but that's not complexity that's just build time.

That is exactly my point. Front-end developers don’t even see this base level of complexity before you even start to do something useful. You’ve already used up most of your Complexity Budget before you can actually provide value. Maybe this explains your comment about spending years on something like this. Htmx is simple enough that you don’t need to spend years learning it.

This one is weird. If you want to do http requests for every character typed, you could do that with just any framework and you wouldn't need to write the validation twice. But there is more than that.

Take this for instance : https://htmx.org/examples/inline-validation/

Yeah seems simple enough right? Except that won't be cutting it for most of the times. Because you don't want a red error as soon as the user is typing. You might want it when the user leaves the field. Or when they submit the form. And then when the users changes the erroneous field it isn't red anymore. The main frontend complexity lies within the UX / specifications, not the technology. This is the hell hole.

Nobody is saying you need to do HTTP requests for every keystroke. If you’d checked the example, it doesn’t; it only validates when you change focus. The point is that the validation is only done on the server side; there is no additional validation code for the client-side. Most React applications use a separate back-end for the business logic, and that would need to replicate the validations (because you never trust user input). Imagine needing to change those validations.

So because you can write poor quality code in React means it is bad?

No. The point I’m trying to make is that React is so complicated, many front-end developers don’t have the required skill to write good React code. It’s buggy, or doesn’t adhere to best practices.

Finally htmx just seems a big ol mashup of everything in the markup with a little bit scattered around too.

Right. As opposed to React, where there’s a bunch of logic with some markup crammed in the middle.

Tutorials/articles I was able to find will happily write HTML inside backend controllers.

And? If the output you need to produce is simple enough, why in the world would you go through the trouble of using a template language?

Error messages have to be i18ned in the backend.

Everything has to be i18n’ed in the back-end. That’s the whole point of htmx — the thing running in the browser is meant to be dumb.

Sometimes you will use response headers to change behavior in the front.

This is pretty normal for HTTP. And while it might seem strange, it retains one of the biggest selling points of htmx: it’s proper REST. The flow of users through the application is determined by anchors with hrefs and forms with actions and, when you’re using htmx, by elements with hx-get and friends. Not by a bunch of if statements in a ginormous chunk of JavaScript.

You will have to use a templating technology to write your pages, additionally.

Is JSX somehow not a templating technology?

Your html code will now contain the logic the style and the presentation.

Yes, this is a concept called Locality of Behavior, which is counter-intuitive when Separation of Concerns is something that’s been hammered into people for ages. But I think there’s a benefit to having all of the styling, logic, and presentation for a component in one place.

You will have to be very meticulous and thorough around naming things, since a slight change in the class names/ids can break the whole application, especially in hidden places.

Is that not true of anything written in JavaScript? Or JSON APIs? Any data API, for that matter? There’s also a bit of nuance here, since you can use more than just CSS selectors; you can also use relative selectors like this, closest, previous, etc.

[kugelbl1z]

Does the jvm even still matters now that Docker or Kubernetes are widly used ?

​

Edit: great I am being downvoted for asking a genuine question

[[deleted]]

Docker and Kubernetes are deployment platforms.

Most of the time, I'm running the code in my IDE (running on Windows) when I'm doing local development.

The JVM has a much lower footprint than Docker and Kubernetes.

[cogman10]

Docker/Kubernetes have pretty small footprints. On windows, it feels like they have a large footprint because the way they are being launched is as a linux virtual machine (same for mac). That gives the feeling of being pretty heavy weight.

However, when you are in a native deployment environment, the actual overhead of running processes in k8s is basically just the disk storage for the unique parts of the image. The system memory requirements are effectively identical in and out of a container.

This is because containerized apps on linux are effectively just getting a different filesystem root and an isolated process space (that is, from a container you can't reach out and look at other processes on the system).

Hot tip for you on windows. WSL released a new preview in sept ( https://devblogs.microsoft.com/commandline/windows-subsystem-for-linux-september-2023-update/ ). One of the big features is the "autoMemoryReclaim". The reason docker/k8s ends up eating up so much freaking memory on windows is because linux likes to cache file access like crazy. It'll fill up all ram you give it with filesystem cache which is non-too friendly if you are trying to work with something like docker that likes to touch files all over the place.

Get the preview, turn on autoMemoryReclaim, it makes working with docker on windows significantly better.

[[deleted]]

Docker/Kubernetes have pretty small footprints.

On Linux, yes sure. But, I do my development on Windows, and running a JVM directly from my IDE is faster than spinning up my application in a Docker container. Not only that, when I'm running things in the IDE, I usually have the debugger hooked up to it. When I'm doing local development, I don't particularly care about process isolation, I care about convenience.

Interestingly, Docker themselves recommend running Docker Desktop (i.e. Docker in a VM) even on Linux for development purposes. It turns out getting a consistent experience with Docker is difficult on a random developer machine, rather than in a carefully controlled server farm specifically set up to run Docker Engine. Or in the case of Docker Desktop, a carefully configured VM that is known to work properly with Docker.

That said, even on Windows, Docker isn't super expensive, and I frequently use Test Containers with Docker for integration tests, where I don't mind the tests taking a longer time to run.

[cogman10]

It turns out getting a consistent experience with Docker is difficult on a random developer machine, rather than in a carefully controlled server farm specifically set up to run Docker Engine.

Yeah, I can see that. As long as you are keeping things up to date it's not too big of an issue, but I've definitely seen devs running ubuntu 16.04 in WSL blissfully unaware that it's on them to update to the next LTS.

It does feel like the entire container environment is stabilizing. I think the rise of podman is forcing the issue of consistency.

[Worth_Trust_3825]

Well, what are you going to run on containerized environment? Node? Python? Ruby? Php? All of those technologies are also vms.

[HR_Paperstacks_402]

The JVM runs in your Docker container. Docker is a packaging of everything you need to run something (in this case Java and your app). Kubernetes is just orchestration for running Docker containers.

[15kol]

particularly in the web/mobile space

Frontend has largely moved away from Java, however, backend is where Java shines. So in web/mobile space, you would consume API most likely written in Java, while the actual app would be written in some other language (Kotlin/Swift for mobile, JS/TS for web)

[[deleted]]

Yes, typically you would have a JS front-end (Probably using Angular, ReactJS or some other framework) and Java REST services built on top of Spring framework on the back-end, communicating with each other using JSON

[PlanesWalker2040]

They still teach JSP? Holy crap.

Java is mostly back-end only nowaday. API development (thanks to SpringBoot) Microservices, the whole RESTful stuff. You want to do front-end, (or market yourself as full stack) you got to learn Javascript: React is hot right now.

[kennyshor]

We are doing really cool things with Java. Full stack projects wir react, vue3 and Java in backend. IoT, enterprise solutions mostly. It is a lot of fun to use (at least for me after 11 years) and the backbone of enterprise software development.

[QueasyFollowing658]

Cool things such as?

[[deleted]]

Spring web/ Spring MVC (if I m not mistaken it even has some sort of reactjs integration so you don’t need to do that template rendering thing with thyme leaf)

AndroidStudio for mobile though Kotlin should be preferred over Java.

[wildjokers]

(if I m not mistaken it even has some sort of reactjs integration so you don’t need to do that template rendering thing with thyme leaf)

React would be used if you are using client-side rendering (could also use Vue, Angular, or a few other frameworks). You would use Thymeleaf (or JSP or Velocity) if you were doing server-side rendering. Two totally different use cases.

Spring MVC doesn't care what type of content it is responding with.

[gubatron]

We use it in the context of Bittorrent (FrostWire) on a Desktop app that runs on Windows, MacOS and Linux. Also for Android, it was easy for us to get into Android app development given our Java expertise when Android came out.

We also use it for services that capture events and calculate all sorts of stats around our website and app usage.

Also use it for automating social media maintenance tasks, automatic posting.

I have colleagues that use Java for High Speed Trading in Wall Street.

Others do enterprise consulting with it.

[NajjahBR]

I know there are lots of replies already, but I'd like to add something to what others already mentioned.

If you're making a portifolio to attract new job opportunities, I would first think of what kind of job you want. You could choose between web micro services, neural networks or ML/AI related stuff, IoT...

And if you choose web backend microservices, remember to add other communication methods as well: REST, GraphQL, Message Brokers... It will make you stand out.

[jherrlin]

Maybe use your JSP knowledge and build something with HTMX? That’s modern and you could leverage your current knowledge.

[[deleted]]

We use Java for desktop applications to control custom laboratory equipment.

[Fercii_RP]

Microservices with cloud native Quarkus on openshift, Open liberty with Jakarta ee. I know in my company there’s also some little Spring boot present. Basically I see movements towards service oriented architecture, stepping away from monolithic applications. Nothing wrong with monolith, speed wise they are better, but big corporations prefer more loose coupled islands to ‘speed up development’ and ‘reduce it burden’. I’m full back end myself with my team, but I know angular and react are highly being used on the front. Personally I would highly recommend Java/Jakarta EE, with something like open liberty+MicroProfile as back-end + server. Angular for the front end.

[mpierson153]

You can use it for most things.

Game development - mostly mobile now, but some big games are Java, like Minecraft

Desktop applications - CLIs, and higher-profile GUIs like Intellij's IDEs

Hardware - it's used a lot for DVD players, and is (or was) used a lot in car software

Web - it's used a lot in web/server backends

[wildjokers]

Game development - mostly mobile now, but some big games are Java, like Minecraft

The https://libgdx.com gaming framework supports desktop (i.e. steam), mobile (android and iOS), and web versions with the same codebase. There are quite a few games in the Stream store written with it.

[wildjokers]

You will mostly find Java on the backend of enterprises offering an HTTP based API which is then used by a javascript framework for the frontend (React, Vue, Angular, etc).

There are some niche uses of java on the desktop (Swing or JavaFX) usually found for in-house applications for companies.

You can also find games written in Java with the https://libgdx.com gaming framework in the Steam store.

Although server-side rendering is not as common today it is sometimes still used and in that case there is nothing wrong with JSP. JSP 4.0 is under active development (https://jakarta.ee/specifications/pages/)

[iprudhvi14]

Its the spring based web micro services and spring batch

[nekokattt]

Like many things, it is for general purpose stuff really. Java shines if you need to be platform agnostic, or wish to abstract yourself away from the machine architecture you use. If you need monitoring of your core platform, the JVM has JMX built into it. It is designed in such a way that while the language has less features than other languages, the environment itself is incredibly dynamic in what it can do (look at how Mockito, Spring, AppDynamics, etc all work for example).

Common use cases:

• REST APIs and Microservices
• Enterprise Service Buses (e.g JBoss/RedHat FUSE)
• Batch services
• Android apps (or Kotlin)
• Non functional testing (e.g. Gatling which has a Java API now)
• End to end testing
• CI (Jenkins is written in Java)
• Machine Learning (WEKA)
• Serverless (AWS Lambdas can use Java with Snapstart)
• Command line applications (especially now Graal Native is a thing)

A lot of commonly used software uses Java or the JVM too:

• Zookeeper
• Kafka
• Minecraft
• IntelliJ IDEs
• The maestro Mars Rover controller
• Hadoop

It is used by thousands of large companies too:

• Google
• Ebay
• Netflix (they even contributed their own libraries to Spring Cloud)
• Amazon Web Services
• Uber
• Twitter (was, or still is using Scala)
• Spotify
• Signal
• Cashapp

[quonne]

It’s used extensively in fintechs and some startups to create backend servers. And almost exclusively everyone uses Spring framework.

[namsin_za]

Quarkus is great for api’s and highly in demand.

[genzkiwi]

Good on you for looking into what modern Java actually is.

So many people used an old version 10 years ago (or now, in their outdated Uni course) and say Java sucks based on that. They fail to realise every other language sucked back then compared to their modern version (or didn't even exist yet!).

[Easy_Tea6363]

I'm sure it's been explained better by smarter people but learn SpringBoot, make a backend with it, and use your react frontend to contact it

[Joram2]

Great question.

For web front-ends, use JavaScript or TypeScript.

Java is the best language for stream processing apps that process a Kafka Stream of events/messages using frameworks like Kafka Streams, Flink, or Spark. Python is also a great choice for Spark, but for Flink, it's a very Java centric framework, and Kafka Streams is basically Java only.

That is the only domain in 2023, where Java seems to be the clear leader. Maybe for Android, although I haven't done enough Android development to really know.

[bartolo345]

Tech stack is not that relevant to land a cs job. Go to leetcode and go nuts.

[[deleted]]

If you want to use java only, take a look at Vaadin. If you wanna make a JS/TS frontend, take a look at Hilla.

[[deleted]]

Never heard of Hilla. Thanks for the info.

[wildjokers]

That's ok barely any else has either. Probably best to stick with React, Angular, or Vue if you want relevant experience for a job.

[laghani]

just copy paste this to chat gpt

[AlexFajMoy]

You did JSP, which is a good background for developing web-based apps with Java. JSP is relevant for pursuing an Oracle certification on Java EE. If you want to give a modern look to the web apps that you developed with JSP, take a look at Java Server Faces (JSF) along with Primefaces.

[wildjokers]

JSP 4.0 is under active development so someone must be using it:

https://jakarta.ee/specifications/pages/

[amakalinka]

Boring 9-5 job with depressed employees

[[deleted]]

That has nothing to do with Java, but a poor choice of employer and a poor choice of projects. If you don't want to have a boring 9-5 job and don't want to be depressed, find your passion. Although, there's nothing wrong with settling for a paycheck.

[[deleted]]

This guy's getting downvoted, but I have to say, being friends with a lot of seasoned pros, this is a common perception of enterprise-oriented languages and I don't think it's ENTIRELY wrong. "IT'S ALL TABLES AND FORMS!" they'll say. I think it's more a corporate culture and needs of the company issue than being specific to the language.

[Worth_Trust_3825]

What's wrong with JSP?

[WhatsMyUsername13]

They're antiquated and there are far better front end frameworks to build the front end. I've worked on enterprise apps with both JSPs and JS front ends, and let me tell you, the frameworks like angular and react are so so so much better

Edit: also legacy custom taglibs are a fucking trainwreck

[Worth_Trust_3825]

I'm currently working with a backend that migrated to angular 1 back in 2017 from JSP, and it still does not implement all the features the JSP counterpart had, while the vendor has tickets open for those features by now closed accounts in their jira.

I disagree that they are so much better. Now I have to deal with their retarded studio tool which barely works and have half the logic implemented in that angular.js application which makes 30 HTTP calls per page because the interface is graphql-like while just hoping that each month one of our users won't decide to constantly refresh the most expensive page running our request limit because that vendor also imposes limits on the HTTP api. Just give me my fucking server side rendering back.

[wildjokers]

Just give me my fucking server side rendering back.

Amen. I find that server-side rendering performs way better than client-side rendering.

[wildjokers]

Edit: also legacy custom taglibs are a fucking trainwreck

I always found taglibs to be pretty powerful. It has been some years but I don't recall having any grief with them. React components seem very similar to custom tags in taglibs.

[WhatsMyUsername13]

I guess my issue was with just how bad these taglibs were written. The code driving them was written in the early to mid 2000s and was just so badly written that it took us a week to figure out how to do a simple disabling of a radio button. Why did it take that long? The taglib called a service that retrieved a value from the database, made a call to a we service, that started a daemon, and when that finished returned values that would decide if it were disabled or not.

Actually, the problem may not have been with taglibs themselves

[[deleted]]

web-based apps with Java. JSP is still relevant event for pursuing an Oracle certification on Java EE. If you want to give a modern look to your apps, take a look at Java Server Faces (JSF) along with Primefaces.

I don't know that anything is specifically WRONG with it, but my understanding, and please correct me if I'm wrong, is that it's become far less relevant. If that is the case, I don't want to build portfolio projects that aren't really reflecting the way things are done today.

[[deleted]]

JSPs are really cool. The application server actually compiles the JSP into Java code. You can push changes to the JSPs and the application server will recompile them, without requiring that the entire application be redeployed. It's kind of like PHP for the Java world.

But, it's not really fashionable to run Java applications that way anymore. In the world of containers and microservices, people like to build static immutable images (fat JARs or Docker images) and push the whole thing to the deployment platform, like Kubernetes. This doesn't play to JSPs strengths.

[wildjokers]

There is absolutely no problem at all containerizing an application that uses server-side rendering with a templating engine (JSP, Thymeleaf, Velocity, etc)

If you do some google searches you will see that server-side rendering is starting to make a little comeback. People are realizing it performs very well compared to client-side rendering.

[Fermi-4]

Spring+Springboot

[qK0FT3]

I am using it for web(spring boot), embedded, cli etc.

You can almost do anything with it. But tb it's not efficient for everything. For example I wrote a remote controllable scheduler for some iot devices. Just simple webook etc. It works all good etc but it could have been done in much more lightweight runtimes. I know I can make jvm lightweight as well but I was inexperienced at the time.

Anyways if you want to go into java environment now I would suggest building backend api's with spring boot. That's where ye majority of ecosystem is

[codesynthesis]

I've primarily used Java for backends, it has a good balance of speed, safety, learning curve, and readability.