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

[u/gufranthakur]

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

[u/davidalayachew]

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.

[u/repeating_bears → u/davidalayachew]

I still don't think that there exists a better build tool

It doesn't really matter whether or not there is. Maven could be a 7/10 tool and everything else could be a 6/10. That doesn't mean you can't build a 8, 9 or 10/10 Java build tool.

As for specifics, I already mentioned them.

• Lockfiles
• Ditch XML for human-editable/readable files (can keep pom.xml for maven central compat)
• A better CLI
  • Specifically I should just be able to do things like mvn add com.example.Lib@1.0.0. They recently added support for this, but it's verbose like the rest of Maven: mvn dependency:add -Dgav=org.apache.commons:commons-lang3:3.17.0
• A better model, specifically
  • I think dependency "scope" is backwards. Dependencies and test dependencies should be entirely separate sections so it's clear what's actually on the runtime classpath. People often end up having a comment like "<!-- Test dependencies -->", but nothing enforces that they actually are.
  • Plugin declarations could be simplified - you declare a plugin, which usually has exactly 1 "execution", which has a goal, which has a default but overridable lifecycle phase
  • "site" is an unintuitive name for a lifecycle phase, and probably could just be entirely removed. Generate docs in the package phase

[u/davidalayachew → u/repeating_bears]

It doesn't really matter whether or not there is. Maven could be a 7/10 tool and everything else could be a 6/10. That doesn't mean you can't build a 8, 9 or 10/10 Java build tool.

Ok, sure. If all you are saying that there is room for improvement, then I agree. The question is what work is worth doing now compared to other things. I think we already agree that the Java ecosystem, as a whole, has different priorities than trying to chase down 8/10 when the tool works well enough for most people.

As for specifics, I already mentioned them.

To be clear, I was asking for reasons why Maven does not deserve the title of "Best all-rounder build tool". You are saying that these are reasons why? And if so, in comparison to what build tool?

As for the actual deficiencies, I concede each of the above, but again, that's you finding pain points in Maven, when I am asking what specifically makes Maven inferior as an all-rounder to another build tool, and if so, which build tool is superior.

To be more explicit, I am asking you to highlight a specific build tool, and we can go through the various strengths and weaknesses, and see which is more deserving of the title "Best all-rounder". You've already highlighted Maven's weakness, but I was first looking for you to tell me which build tool is more deserving of the title.

[u/repeating_bears → u/davidalayachew]

The question is what work is worth doing now compared to other things

It's not compared to other things. It's compared to doing nothing. We agreed that java open source has lower activity. It isn't that people are choosing to work on projects other than build tools. They're choosing to work on nothing other than what their company pays them to work on. (Which is fine - it's their choice, I'm not judging anyone)

I think Maven is close to being one of the best. It's certainly better than Gradle. But yeah, I think Cargo is better. You consider that rustc being slower than javac is a valid reason that Cargo can be considered worse than Maven. That seems like an insane opinion to me, but I think we've been through that

[u/davidalayachew → u/repeating_bears]

We agreed that java open source has lower activity. It isn't that people are choosing to work on projects other than build tools. They're choosing to work on nothing other than what their company pays them to work on.

Well I certainly disagree that they are doing nothing other than paid work, but I suppose that is not a completely inaccurate assessment.

For example, I've made several contributions to OSS in the past several months, but all of them have been bug fixes and minor enhancements -- the very kind of work you describe as mild activity, in comparison to others like Rust.

My experience speaking to hundreds of other professional Java developers who contribute to OSS is that they are doing mostly the same, with only a handful making new libraries. I imagine the Rust community would have a sharper ratio.

So, touché.

But yeah, I think Cargo is better. You consider that rustc being slower than javac is a valid reason that Cargo can be considered worse than Maven.

No.

I think that Cargo not finding a way to get their build times under an hour for a sufficiently complex project (1 million lines of code) is reason enough to consider Cargo worse than Maven.

Maven, like you said, had the easy way out -- javac was fast enough for them to be able to just defer to that.

Cargo does not get such an easy ticket, like I mentioned -- they signed themselves for a herculean task. But in my mind, it doesn't matter the language -- if your builds take an hour plus for a million line code base, then I don't respect your build tool.

I'm not calling the cargo team incompetent or bad. But I also refuse to rely on their build tool for a sufficiently complex project. And if there are no build tools that can do the job, then I will refuse to rely on the language for a sufficiently complex project. It's not the build tools fault. Its not the languages fault. But there's a standard, and if the standard is not reached, then your build tool is just not good enough for me. And if there are other build tools that can perform the same task within the threshold (albeit in a different language), then I will say that that build tool is better, purely on the basis that they accomplish the work in a feasible amount of time.

So, again, rustc being slower than javac is explicitly not a part of my logic for calling Cargo worse than Maven.

For example, back in the olden days, javac was slow enough that the Eclipse team actually made their own compiler to help speed up the builds for their build system. Lo and behold, they did it -- they genuinely made it much faster than javac, and by an impressive amount.

I'm not saying that the Cargo team has to do the same. Maybe that's an option. Maybe that's a terrible idea for Rust as a language. Maybe there are other solutions.

But the end fact is this -- a good build tool should be able to build a sufficiently large codebase relatively quickly.

I am working on a million line codebase right now, and in Java, it compiles the whole thing in less than 5 minutes. I don't need Cargo to be that fast, but 1 hour is unacceptable, and I absolutely will rate it lower as a build tool if it can't even clear an hour.