r/java 10d ago

Usage of Java in non-web development domains, and Greenfield projects.

Greetings.

(I will beat around the bush a bit before getting to the point, you can scroll down a bit to save time)

Java currently shines at enterprise backend applications, being led by the big players like Spring and Quarkus. However Java seems more than capable for other domains, yet no one talks about it, or even considers Java for normal non-web projects.

Take desktop development for example. JavaFX is one of the BEST GUI frameworks I have ever used. It is feature packed, doesn't require cryptic symbols, no fancy way of nesting code blocks to create simple UI. It is very simple to use, yet powerful and robust.

Game Development is a bit weak, but we still have libGDX and LWJGL. They are packed with features, even 3D. Contrary to popular belief that libGDX is a 2D only framework, libGDX has some great 3D support like GLTF rendering, bullet physics, PBR rendering and skeletal animations.

Big data processing and simulation systems, Java's OOP nature really helps to solve certain problem statement that requires the problem to be broken down into multiple pieces.

And finally web development, there is no doubt Java has one of the best ecosystems for the web.

And yet despite all this, Even as modern Java has come a long way, Java continues to have a negative reputation of being slow, boilerplate, RAM consuming memory hog. (The same people will use electron to make a desktop app btw) and as a result not considered for newer projects.

When I look at other communities like JavaScript, Rust, python, C#, Zig. These languages are often considered first options for any Greenfield projects. The open source communities in these languages are very active, you will see some amazing work being put out by the community.

Java seems to lack that "community" nowadays. I am active in a lot of subreddits and forums, and I see very less of Java projects in the wild. Java is being used in production out there, but modern greenfield projects are leaning more towards Go and C#.

So getting to the point of the post

Is Java seeing a decline? This is not a "Java dead" post but a genuine concern. The community for Java just seems.... dull. And I was wondering what could be done about this. Amongst new and modern programmers, Java and C++ seem to be considered "old", "dead" and "traditional"

Perhaps project Valhalla could help, but I wonder how much would it help restore Java's PR. Oracle is definetly NOT helping with this.

Why does this matter in the first place?

You may think "it doesn't matter what others think, companies still want Java" and while it holds some truth, more and more of Open source development seems to be moving towards other languages. A lot of Java libraries and frameworks have seen some decline, the community seems to be becoming more inactive. Other programming languages and frameworks have active discord servers, forums, documentation, and participation while Java seems a bit slow there.

I dont know, I really love Java as a language. And I wish it had more adoption in non-enterprise domains. I would genuinely like to know, what we as a community can do to make Java more "loved" and preferred

90 Upvotes

129 comments sorted by

View all comments

Show parent comments

1

u/repeating_bears 9d ago

Maven and Jackson are both good enough, but they're not insurmountably good.

Cargo is slow by nature of the Rust language, rather than because it's badly designed. I think the design is a big improvement on Maven. Lockfiles, toolchain management, TOML instead of XML (and IMO a better "model"), a more functional CLI

1

u/davidalayachew 9d ago

Cargo is slow by nature of the Rust language, rather than because it's badly designed. I think the design is a big improvement on Maven. Lockfiles, toolchain management, TOML instead of XML (and IMO a better "model"), a more functional CLI

Sure, but that there is the point -- a tradeoff forced by being part of a different language. You get ergonomics and all sorts of cool features, but you trade off build time.

That's kind of my point -- Maven has good enough ergonomics and good enough performance, so where is the major work going to be in? Compare that to Rust, where the performance is a serious problem, so a lot of people and effort is being thrown into improving that.

When you don't have many problems, there is less need for work to be done. Not to say Maven doesn't have many problems, but I would argue that Maven 4 doesn't have many pressing ones.

1

u/repeating_bears 9d ago

You get ergonomics and all sorts of cool features, but you trade off build time.

No that's not the trade-off. Cargo isn't slow because it has lockfiles, uses TOML, has a better model, or has a better CLI.

Cargo is slow because compiling Rust is hard. There's macro expansion and more sophisticated type inference. You need to recompile every dependency. Maven doesn't even do compilation. It just calls javac. Maven isn't faster because they made the decision to be feature-light. The thing it delegates to is just fast.

Maven 4 doesn't have many pressing ones

Version 4 isn't addressing any of those issues I mentioned.

1

u/davidalayachew 9d ago

Cargo isn't slow because it has lockfiles, uses TOML, has a better model, or has a better CLI.

I said that the tradeoff is forced by being part of a different language. Meaning, the attributes of the language will decide (in part) the tradeoffs of the tools in its ecosystem.

Java compiles (comparatively) quickly, and thus, performance of Maven takes significantly less time than it does for Rust/Cargo. But Java is old, so the ideas of the time are rooted deeply, and hard to uproot.

Rust is (comparatively) young, and thus, can take advantage of newer discoveries that were either non-existent or unproven at the time (TOML, Lockfiles being better, dev experience, etc.). But by taking on a massive effort in the type system, they also increased their compile times significantly.

That is what I mean by tradeoff.

Version 4 isn't addressing any of those issues I mentioned.

Sure, but how often are those deal breakers? Because at the end of the day, the real problem is if something is a blocker -- preventing people from getting actual work done. Build times absolutely could be a blocker. Dislike of XML rarely is.

That's my bar for pressing issues. I've talked with and even worked with many Java maintainers for libraries. That is roughly their bar too.

1

u/repeating_bears 9d ago edited 9d ago

Rust is (comparatively) young, and thus, can take advantage of newer discoveries that were either non-existent or unproven at the time

Yes, I agree. I'm not saying Cargo is good because the authors are geniuses and Maven is bad because the authors are idiots.

I said that an open source developer could build a better build system for Java. You somewhat pushed back on that and said that Maven is one of the best. You said "everything's been built", but now you are admitting that there have been advances in the state-of-the-art for build tools which are not reflected in Maven.

That's my bar for pressing issues. I've talked with and even worked with many Java maintainers for libraries. That is roughly their bar too.

If you're saying that Java devs only work on new solutions when the others are physically unworkable, then that just proves my point. Rust and Typescript as an ecosystem are continually innovating. Maybe to a fault. They are willing to try replacing something that already exists, with a far lower bar than "prevented from getting work done"

1

u/davidalayachew 9d ago

You somewhat pushed back on that and said that Maven is one of the best. You said "everything's been built", but now you are admitting that there have been advances in the state-of-the-art for build tools which are not reflected in Maven.

My intention was not to say that Maven surpasses all other build tools in all categories. My intention was to say that Maven is the best all-rounder, and I can't think of another build tool that surpasses it by that measure.

That's why I pointed at Cargo -- it absolutely has better ergonomics than Maven, but the build time is atrocious, and that's a deal breaker for a lot of projects. You really can't call yourself an excellent build tool if building a million lines of code is measured in hours. That's really bad.

That's been my point from the beginning -- a lot of the Java ecosystem has warts in places, but most of those are not deal-breakers. Most of it works great, and is just not up-to-date with the latest stuff, or has a less-than-stellar dev experience.

1

u/repeating_bears 9d ago

You really can't call yourself an excellent build tool if building a million lines of code is measured in hours. 

Absolutely you can. Imagine a language that inherently takes an hour to compile any program. I build a build tool that executes in 1h0.00001s. You can call the language terrible, but not the build tool. It's building near-optimally and adding almost no overhead of its own. It's just building something inherently slow.

Cargo is very good at doing something hard, and Maven is decent at doing something much less hard. That doesn't make Maven a better build tool.

If you extended Maven to support Rust (which with some effort you could do - Maven supports Kotlin etc), it wouldn't be faster than Cargo.

a lot of the Java ecosystem has warts in places

I editted my prev post to add a section but you wouldn't have had time to see it.

This conversation started by me saying that open source in Java has less activity than other ecosystems. You asked whether that could be because "everything's been built". If you agree there are warts, then there is lots of potential work that could be done to remove or reduce the warts.

I think it's actually exactly as you already described: many Java devs have a high bar to want to fix something in open source. They're willing to accept some "warts". Devs in other ecosystems don't accept the status quo so readily.

1

u/davidalayachew 9d ago

Absolutely you can.

Then I fundamentally disagree.

You can claim that that build tool is good by rust standards, but it doesn't change the fact that my million line codebase takes an hour to build, and that is not good. That is a dealbreaker for many projects, and can outright kill them over time.

Cargo is very good at doing something hard, and Maven is decent at doing something much less hard. That doesn't make Maven a better build tool.

Then that just means that the team behind Cargo signed themselves up for something very difficult, which is extremely admirable from an engineering perspective, but it does not change the end result.

At the end of the day, a build tool is evaluated by how effectively it facilitates getting work done right. Everything else is secondary. And if it takes me an hour to build my codebase, that is not very effective. Plain and simple. We can appreciate the engineering effort under the hood all we want, but the end result is the lion's share of the final score.

This conversation started by me saying that open source in Java has less activity than other ecosystems. You asked whether that could be because "everything's been built". If you agree there are warts, then there is lots of potential work that could be done to remove or reduce the warts.

But that was my point from the very beginning -- if the actual tools have been built, are fully functional, and the biggest outstanding things are they have warts, then that demands passive development effort, not the active one that communities like Rust must exert to get Cargo to build in less than an hour.

Hence my point -- because everything is already built, only passive effort is being exerted to take care of warts.

I think it's actually exactly as you already described: many Java devs have a high bar to want to fix something in open source. They're willing to accept some "warts". Devs in other ecosystems don't accept the status quo so readily.

Then it sounds like you and I have reached a point of agreement -- other languages consider things like warts to be a higher priority than the general Java community does. So, the Java community will switch gears to finding other work to do, rather than focus on dealing with warts. That's why the Java community has less activity -- because there is less that they deem worth doing, at least urgently. They already did the important stuff, like I said. The other languages are still in the middle of doing their important stuff, let alone the warts.

1

u/repeating_bears 9d ago

That's why the Java community has less activity -- because there is less that they deem worth doing

Again, there is not only one reason why.

My original claim was only that Java does have less activity. We would both only be speculating about the reason.

When you suggested "could it be because everything has been built?", the answer is no. Not because I can psychically predict people's motivations as you apparently can, but because not everything has been built.

We got onto this because I said that a built tool better than Maven hasn't been built, which we now both agree could be. There are infinite other things which haven't been built. You could write a native Java API for any REST API that doesn't have one. You could write an SDK for generating knitting patterns.

Could it be because Java devs mistakenly think everything's been built? Yes, it might be that there is something common to Java devs that mean they lack imagination.

1

u/davidalayachew 9d ago

Again, there is not only one reason why.

Sure, I am not claiming, unquestionably, that this is the sole reason why. I just believe that it is the dominant reason, based on what I mentioned in my previous comments.

We would both only be speculating about the reason.

Correct, but there is value in comparing our shared experiences to see if our speculations match up with each others shared experiences. At the end of the day, that's the only thing speculation is good for -- comparing against lived experience. For everything else, it's just an assumption.

When you suggested "could it be because everything has been built?", the answer is no. Not because I can psychically predict people's motivations as you apparently can, but because not everything has been built.

Obviously I am being hyperbolic. My point was that the majority of what is being built in these other communities has already been built in Java.

We got onto this because I said that a built tool better than Maven hasn't been built, which we now both agree could be.

I still don't think that there exists a better build tool. At best, I think there are certain build tools that do certain things better than Maven, but the all-around best is still Maven. Happy to hear reasons why you disagree.

Could it be because Java devs mistakenly think everything's been built? Yes, it might be that there is something common to Java devs that mean they lack imagination.

Well, what you call a mistake, others might call pragmatism.

A lot of us are in this to solve problems, and if it solves the problem, then for a lot of us, it really truly is good enough, and doesn't need anything more than passive effort.

Others obviously can disagree, but that doesn't change the fact that in the Java community, there are still plenty who feel that this is good enough.

→ More replies (0)

1

u/davidalayachew 9d ago

Oh, you edited your comment after I had already replied.

If you're saying that Java devs only work on new solutions when the others are physically unworkable, then that just proves my point. Rust and Typescript as an ecosystem are continually innovating. Maybe to a fault. They are willing to try replacing something that already exists, with a far lower bar than "prevented from getting work done"

That's not what I said.

But even putting that aside, my original point of disagreement with you was that the Java ecosystem doesn't have much activity. Sure, it is less, but I claim that that is more to do with these other ecosystems trying to solve fundamental problems that the Java ecosystem either doesn't have, or can't have. For example, there are a flurry of libraries that have come out in the past few years for Python that take advantage of the new type hints to improve the validation and checking. That's something that Java gives you out of the box, so that's a solid reason why Java isn't building libraries like that.

And since Maven effectively solves so many of the build problems people have (either by itself or through plugins), why exert the effort to solve things like dev experience when it really isn't a big enough issue for most teams? And that's ignoring that there are far more pressing issues (CVE's) that need to be solved?

That's been my point from the beginning -- these other communities are solving problems that Java doesn't have -- either no more, or never before. Compare the activity in Java 1999 to Rust now, and I think we would say that Java has the same, if not more, activity than Rust.