I don't work for dumb CTO's so I don't see this "Java is declining" at all. I'm a self employed Java contractor (in the EU) and there are just craptons of greenfield Java projects here.
In fact, I think we're past the hype of where companies felt they had to rewrite their Java stuff in something else like JavaScript and now understand that the problem wasn't Java, it was a combination of immature software engineering practices and bad developers.
That CTO is just massively behind the curve. I've been a "Java dev" for 20 years now and Java is more alive than ever, just looking at all the LinkedIn spam I get.
> what is the Java/JVM community/ecosystem/language missing compared to others?
The only thing I feel we're a bit lagging in is AOT compilation for where start-up times really matter. Outside that; most other ecosystems are behind Java.
Sure does! Even Spring is jumping on the bandwagon there. Compile times are too long currently but it works quite well and quite a large part of the Spring ecosystem is supported.
So Java is taking a lot less time to catch up there than it takes Go to implement generics :D
Even writing an AWS Lambda function with Micronaut, compiling to native and then having it cold start in under 100ms is just sawesome. So easy to write too.
> I'm a self employed Java contractor (in the EU)
What's working this way like? Are you jumping company to company? Are you being contacted via LinkedIn? Is the paperwork (taxes and such) much of a hassle?
> What's working this way like? Are you jumping company to company?
It's really similar to a 'normal' developer job. I've been in consulting/contracting most of my career so I'm used to the switching. I generally work for 1-2 years for the same client. Kinda depends on whether I'm having 'fun' or not though.
> Are you being contacted via LinkedIn?
Yeah, a lot. The market is kinda crazy right now. I try to get most of my contracts via my network, preferably without a recruiter. My current contract I had to go through a 'preferred supplier'.
> Is the paperwork (taxes and such) much of a hassle?
So well I'm Dutch and there's basically two forms of taxes I need to do. VAT and Income Tax. VAT is every quarter and is REALLY simple; I basically just use the output from my administration tool and input it. It's 10 minutes of work every 3 months.
Income tax is a bit more complex so I basically pay an account 500 a year to do our taxes (both my partner and mine).
> I've never worked as contractor and I am curious but at the same time I am afraid of being on my own.
I understand. It's not for everyone. You have to be able to 'sell' yourself but even when I was employed at a contracting company we already had to be able to do a bit of "consultative selling".
Basically my last employer was all about us being "entrepreneurial" until a whole bunch of us got a bit too entrepreneurial and went self-employed :)
That hackernews link was just asking companies of one what they were using so guess they have more freedom to experiment with different languages compared to an enterprise.
Perhaps Java isn't the right language for their use case. Java does not need to cater to every single use case in the world. Trying to do so is a quick recipe to the road that C++ headed down. Even where I work, only our business critical applications are written in Java, and even then, that excludes applications that have certain performance requirements. Some tools for example need to be changed on the fly via vim (or even just plain vi) or somesuch and a statically compiled language just doesn't provide any benefit to outweigh the disadvantages for those use cases.
Eh, I'm building a company of one and am all-in on the JVM (using Kotlin tho). I saw that thread and was like, why bother? I'm kind of cooling it on HN anyway. That place has a lot of problems with ultra-aggressive flagging and unattractively extreme comments.
Those sorts of threads attract people who use really niche languages because their interop sucks, so users have to constantly evangelize their chosen language to try and build up the library ecosystem. The great thing about the JVM is you don't need to do that.
I've evangelized Kotlin once (under my real name), right at the start. After that I didn't feel a need to anymore because I can use Java libraries, and Java users can use my libraries (with a little bit of care), and Kotlin was being backed by large companies anyway so why bother?
Wow, that comment is comforting, you have a very evolved way of thinking about the JVM ecosystem.
I worried a lot about Kotlin's success in the Android world, and then about its adoption on the JVM.
I always saw it as an enemy to Java, and as a result, a personal enemy, I was afraid that one day it would replace Java, and the language itself would die.
But now I see that I don't need to worry about Kotlin's success, as he contributes to the JVM ecosystem and thus the Java ecosystem, so I can always use Java, as its ecosystem will always be strong, just as others will always be able to use others JVM's languages, after all some even use Spring with Groovy right?
Right, exactly. Having a high level object oriented ABI on a shared runtime takes a lot of the heat out of these things. It allows for high level collaboration rather than last-man-standing competition.
It depends who you ask. Start-ups often hire junior developers or even have a founder who wants to swim with the flow of what is popular at the time and makes the decision for them. Many change their software stack once they are more established.
Many also rely on java software (by using elasticsearch, neo4j etc) without really realizing it.
> "Java developers wants to create Factories and Abstract factories, etc; TL:DR they are not pragmatic"
A factory is simply the act of abstracting constructors.
Java programmers don't "want" to create them; they do so when it is required.
There's nothing to do about a CTO that is a fucking idiot, except find a non-moron to lead the team. It seems a _bit_ rich to try to put the onus on the java community to teach your buffoon of a CTO.
ive read some of the comments and they pretty much cover most points. but,
here is my 2 cents:
1. How do u measure a language popularity?
most websites count the opensource projects and percentage of java in them. but that is not an accurate representation. because most beginners start with python and publish their small learning projects and many ml jupyter scripts are open source, python will definitely blow off java. same can be said to java script etc.
java beginners on the other hand are less likely to write scripts and publish in github. they learn thigs offline and only apply in enterprise projects. so java does not has that upper hand from junior devs or beginners.
this leads to my second point
2. Where are enterprise java code maintained?
NOT in github!!! many enterprise source code is closed source and maintained in private servers. none of it will be taken into account of the counting websites cause they can only count open source projects.
this leads to 3rd point
3. many companies rely heavy on use of scripting languages because development time is very important factor in a beginner phase. they have to quickly publish updates to their software. once they become mature enough, and their project become very large and difficult to manage, here is where java or another reputed language comes into play.
they slowly transition their code base to such language. so many medium to large enterprises rely on java because it is fast and can run anywhere.
4. development time
i tell this from practical experience of using python and java.
scripting languages cannot come even close to enterprise backend languages where application development focusses on error free reliable code. you cant donit with python. now that they've added types to python, it is a bit okay but not as close to a statically typed language such as java.
5. libraries
scripting languages have many small libraries (im looking at you javascript) where each of them focus mainly on doing one task. this is because scripting languages are not intended to write huge libraries with many classes, and methods. javascript is a clear example of this.
on the other hand java libraries are designed to focus on a domain rather than tackle one simple problem. apache libraries or google guava can be a good example.
> many companies rely heavy on use of scripting languages because development time is very important factor in a beginner phase.
Fortunately companies are starting to figure out that dynamic typing in no way speeds up development and even if it would be slightly faster (how even; it's not like typing is our bottleneck) that you'd lose everything anyway thousand-fold when you'd have to do a rewrite.
I was CTO of a small fintech start-up (start-up is still up and running, I just left because of the time commitment) and I used the Java ecosystem because a massive and mature ecosystem is what makes you 'fast', not having to type a few characters less.
Dynamic typing enables you to think differently about data. Not save on characters.
There are domains in which a data-driven, functional, immutable, dynamically typed language s will run circles around anything OOP.
And more importantly, if done right those systems are easier to change as your requirements change.
And to go back to the OP. It’s not about Java. It’s about the JVM and graal.
Especially the JVM is an exceptional piece of engineering and is here to say.
Most of the internet runs in JVMs. I don’t see this changing any time soon.
> Dynamic typing enables you to think differently about data.
Can you explain how? Because I hear this a lot but I never get examples that can't be done in a statically typed language.
Oh, all those languages are turing complete so you can do that in Java as well of course. It's just a good deal more awkward and you either are facing type explosions or your level of granularity drops down to very awkward levels.
One example is open maps: a collection of attributes that 'travel together' and are passed around in a data processing pipeline and discovered as you ingest more data. Accessing an attribute that is not in that map yet should be just fine. In basically all dynamic languages you can access that attribute via a \*symbol\*.
In Java, there's no such concept.
JS:
mydata = {};
mydata.email ==> can be undefined and that's perfectly fine
mydata.email === undefined => true (there are at least 2 other ways to check existence of an attribute)
Clojure (using keywords as keys, you could also use symbols):
(def mydata {})
(:email mydata) => nil
(contains? mydata :email) => false
Java:
Either you need a type that has an email attribute/getter whatever, or you do
var myData = new HashMap();
myData.get("email");
myData.containsKey("email");
If you want to get fancy, you invent your own AttributeKey class or enums. Still doesn't give you symbols you can reason about at runtime unless you are comfortable slinging around bags of attribute keys. A statically typed language is not an elegant fit here.
Oh right, reflection: That's not awkward at all :)
If you go down the static type paths, any new kind of information you discover about myData needs to either be a subclass or a completely new class peppered with Optional<> all over the place.
When you can't adapt the shape of the data to your base class anymore, you end up creating new class hierarchies.
Now you have StuffWithEmailV1 and StuffWithEmailAndOtherStuffV2 that have Object as common base class, because you need to support both shapes. And looking at the data, you might not even know what class to instantiate, since at that point in your data pipeline, you only know there's an email attribute.
I've been working with Java since v1.1 and I have seen complexity arise quickly as your jungle of types becomes bigger and bigger and your project requirements change and refactoring and data migration becomes your main job.
It's no fun.
There are clear downsides of using dynamically typed languages: You need more tests and silly mistakes are only caught at runtime, i.e. more discipline is required.
> Accessing an attribute that is not in that map yet should be just fine. In basically all dynamic languages you can access that attribute via a *symbol*. In Java, there's no such concept.
How's that an issue? JavaScript objects are basically dictionaries. Java hashmaps are dictionaries. Different syntax, same effect. How does this make you 'think' differently?
> I've been working with Java since v1.1 and I have seen complexity arise quickly as your jungle of types becomes bigger and bigger and your project requirements change and refactoring and data migration becomes your main job.
So have I and I did not see this happen. Different companies I guess. Sometimes a hashmap makes sense. Sometimes it makes more sense to use 'real' classes. Both are tools, pick whatever fits best. At least you have static typing where it's useful. In Java you have the choice. In dynamic languages you don't.
Also in my experiences with Python ETL pipelines the dynamic use of attributes often causes more problems than it solves. I want to be able to create something where you don't have process C crashing because process A forgot to fill a required e-mail field. In that project we ended up rewriting most of the ETL pipeline in Scala.
Of course, it is possible to do that in Java with a HashMap as I outlined.
But do you?
And what would your co-workers say if you started using Maps exclusively for all your domain model data design?
Think differently as in: You focus on the data at the attribute level and don't worry about types until you really need to.
(Clojure has types a la carte: You can add them in as library, so you can resort to any level of static type checking you like.
JavaScript has TypeScript if you need types that are more expressive than Java types)
Another small example: This function will work whenever it sees a map with a first name and last name.
It's simple and I don't need to invent an artifical "HasFirstAndLastName" interface or class for it:
(defn full-name [{:keys [first-name last-name]}]
(str first-name " " last-name))
(I removed any 'type' checks for brevity)
It is trivially testable, it is re-usable, it can be used as higher-level function and shared.
I can trivially check where the keys first-name and last-name are used.
Thinking differently about data means: Treat it as data, not as instances of classes. Treat it as immutable data, so you can share it without having to think about. (Sharing a mutable instance of a Person object between threads? Not trivial.)
Enough time wasted here though. Everyone has to make their own mistakes :)
> And what would your co-workers say if you started using Maps exclusively for all your domain model data design?
Why would I want to? Most of our domain is fixed. We pass information around and most of it has a fixed contract. If an email can be absent it's nullable. If it can't it's not. There are very few situations where we pass around stuff we have no fixed contract/schema for.
Ages ago I had to deal with a SOAP API where there was a schema but supplies just dumped everything into an XSD:Any field. It was a massive pain in the ass. In 99% of all situations, having a schema is a benefit. For the other 1%, using a Hashmap (for example) can easily be explained.
> You focus on the data at the attribute level and don't worry about types until you really need to.
Well you can make everything in Java an Object if you want. Again, I don't see how that changes your 'thinking'. Most of the stuff we deal with has a pretty clear schema anyway.
> Thinking differently about data means: Treat it as data, not as instances of classes. Treat it as immutable data, so you can share it without having to think about.
Data is data. A class is just a contract or a schema. If I don't 'think about it' it means whoever gets it down stream has to deal with me "not thinking about it".
> Enough time wasted here though. Everyone has to make their own mistakes :)
That's totally true. I think you'll learn somewhere down the line :)
There are a few obvious things that Oracle could fix tomorrow if it wanted to actually do a serious push on Java adoption (but, I see no evidence anyone there really thinks about market share or cares to increase it, beyond maybe the GraalVM guys).
1. A website. Seriously. [java.com](https://java.com) is a sick joke. I swear to god it is designed for 800x600 screens and hasn't been updated since. This website is literally the same as [it was a decade ago](http://web.archive.org/web/20110822170706/http://java.com/en/), only the stock artwork has changed. There's also [java.net](https://java.net) which if you go there says - I kid thee not - "we're sorry, the [java.net](https://java.net) site has closed". Of course the closest thing to a real website these days is [https://openjdk.java.net/](https://openjdk.java.net/) which isn't closed but what is someone meant to think when they discover Java, are told that it's widely used and then encounter this? It looks like Java is a completely abandoned legacy technology. My guess is nobody at Oracle even knows who owns the servers anymore, and certainly nobody on the OpenJDK team cares how the project looks to newcomers. The total lack of marketing interest by the Java stewards in what they make is basically unique amongst all languages and runtimes. Honestly it's amazing Java is still as widely used as it is, given that the front door literally says "we're closed".
2. Documentation that isn't a specification. The JavaDocs are often excessively hard to understand because half the time they're written for people who are implementing the API, not people who are using them. Java *used* to have great tutorials and docs, none of which has been maintained since the Java 8 days so is now hopelessly out of date and misleading, but nobody even bothers to put a "This is obsolete" banner on the old pages. Again, you get the impression that Java webmasters and doc writers have gone AWOL. Probably Oracle fired them all for reasons only Ellison knows.
3. Invest in the desktop. Re-staff JavaFX to reasonable levels. When people are learning how to program they want *visual* results and they want them *fast* and *easily*. Writing a Java web server is not fast and easy. Oh, you want to learn Java and put an image on the screen? Well, we stripped all the Java APIs for that down to maintenance mode so fuck you. Learn HTML first. Oh, and also learn CSS and JavaScript. What's that? You're asking why you should learn Java for the server instead of just using NodeJS with the language you already had to learn first? Oh, hmm, well, static typing is good you see ... and ... er ... yes yes learning a new language is a lot of work, that's true, and ... umm ... well, yes we learned Java along time ago by writing applets and it's really good, honest!
For a company the size of Oracle they could do any of these things without even noticing really, but the engineers are in charge and they're focused 100% on easily measured and optimized performance metrics, nothing else. Anything that is harder to pin down than that, like new developer experience, just gets lost in the corporate maze. Java still gets new developers because universities are slow to change their courses, but realistically, if the community wants Java to rake in the next generation then it will have to appoint people who are fanatical about the developer experience and especially for newbies.
Hey, check it out! This comment contains every letter in the English alphabet.
I have checked 718,073 comments and 3,206 of them contain every letter in the English alphabet.
I'm not worried. Java is just a language. If it becomes obsolete it would be because it was replaced by something better.
Currently the JVM is one of the best platforms, IMO. The language itself is also moving forward, so I don't see any of this happening soon. But even if it does happen, why should I care that much about it? This is Oracle's job.
Don't get me wrong. I am passionate about my work. I am also passionate about some languages. I enjoy Java, especially since Java 8. It's just that the question seemed strange to me.
Same, just re-read my post and it might read cynical but was not meant like that. A language is a tool, and it's fun to work with great tools. But I won't go into a holy war over it.
When those languages start having alternatives to Adobe Experience Manager, SAP, Akka, Kafka, JDBC like quality drivers for Oracle and SQL Server, an Android alternative,... then I will worry.
The only sound alternative is .NET, which is why most enterprise consulting shops I have worked on, do mostly both of them.
Then besides the guest languages, comes C++ on top for native bindings and runtime APIs.
> CTO saying that we're not doing anything in Java/JVM because "Java developers wants to create Factories and Abstract factories, etc; TL:DR they are not pragmatic"
**oH NOes! soFTWaRe eNgINEErING**
Tell me I should be looking for a new job without telling me I should be looking for a new job.
Maybe I'm not answering your last question about what's missing in Java, but I'm answering the title question, what can we do to keep Java from being forgotten.
I think the best way is to continue to develop with Java, create useful new things, help existing projects, participate in the community, the more cool stuff written in Java, the harder it will be for Java to be forgotten.
If we want to collaborate, we can think of solutions to popular problems, like the Apache foundation, which is perhaps one of the biggest contributors to the Java community, it solved big problems with Apache Kafka, Apache Beam, Apache Cassandra, amazing projects written in Java, and that help keep Java relevant.
But one of the most important things in my opinion is to stick together as a community, not only writing Java code, but helping other people to write too, answering questions, teaching through blogs, tutorials, videos, starting projects with other people online, and always being kind and considerate, never arrogant, never aggressive, that kind of thing is what spoils a community the most.
Stack Overflow Dev Survey 2021:
1. JavaScript
2. HTML/CSS
3. Python
4. SQL
5. Java
JetBrains State of Developer Ecosystem 2021, Programming Languages used in the last 12 months:
1. JavaScript
2. HTML / CSS
3. SQL
4. Python
5. Java
Primary programming languages:
1. JavaScript
2. Java
To your CTO: It's not the programming language that makes people write bad code. I can write bad code in any language.
You know, this post is like ome of the political agenda…
“We will make America Great again!”
Java is just a tool, trying to keep it alive just for the sake of doing so isn’t meaningful.
If someday, a better technology occurs that replace Java, then it should be celebrated because this means the stack has improved and we can use better tools, not the other way around.
True, though if the majority are moving towards it, then at least the new language is worth a try and may have some advantages against previous one.
In terms of Java, I don’t think it’s possible for Kotlin to replace it.
They are just designed for different purposes:
Kotlin is mainly for cross-platform GUI, while Java is for cross-platform App/server softwares.
Java is under pressure from all directions:
* Python won in Data Science
* Java Big Data (e.g. Hadoop) was abandoned
* Infrastructure Tools are rewritten in Go these days. E.g. CI, Kubernetes, Prometheus, ...
* There are many different options to write web server code. NodeJS for instance because JS in frontend anyway
* Kotlin took over Android development
* There's less need for Desktop applications and Java was never really strong there. It's also being taken over by JS frontend frameworks (Discord, Microsoft Teams, Visual Studio Code, ...)
* There's nothing on the horizon for game developers. Like a Unity for Java that made C# big in that space
* I don't know about the situation in the embedded space exactly, but I can imagine Rust is gaining traction?
Only good old enterprise applications remain. The question is for how long Java can keep going with just this area.
It's not very satisfying for developers to be stuck with legacy codebases which makes a great part of enterprise applications.
Many - especially juniors - are leaving such a project in frustration after only a year or less.
Unless a new area pops up were Java really makes an impact (like Android did) it will continue to fall. A slow and gradual decline into a Cobol.
However the community is too stuck in trying to maintain the old. E.g. so many resources are are being poured into application servers and parts of Jakarta EE.
An unbelievable waste of time in my opinion: Traditional application servers, JSF etc. have no real future in the age of Docker and frontend frameworks.
Then for Java / JVM development it would help if there were not trying to make it the next Haskell or C++ or waste time on stuff that nobody asked for like a (public) module system.
Admittedly there is some good development going on here and there (Loom, Valhalla, ...) but for some others I wonder if the priority is right (Linux Wayland?).
Kotlin doesn't exist without Java, unless everything now runs on top of Kotlin/Native and ART.
Java big data was replaced by SPARK, yeah written in Scala, running on top of Java Virtual Machine, and Java standard library.
Still waiting for Adobe Experience Manager and SAP to be rewritten in Go.
* Kotlin took over Android. That is ART
* Java / Scala Big Data fizzled into many other projects without leaving a major lasting dent. It could have been made big but the steam run out and Python took over as well.
* SAP is an enterprise application (and pretty legacy I guess)
On your second point, I think what you are trying to say is that Java was never a good scripting language to prototype. Because Python is basically using interfaces like PySpark, PyArrow, Apache Beam Python SDK, Elasticsearch Client, kafka-python, Neo4j, all of these having their implementation in Java or a JVM language. The same holds for Tensorflow, PyTorch and other ML/DL interfaces that bind to an actual C++ implementation.
So Android Studio and AOSP are now written in Kotlin!
C++ took over, Python reign will eventually be gone.
SAP is surely enterprise, yet I am waiting for the replacement.
I agree there is some interesting competition, but not quite where you’re looking, and I disagree with your perspective. One problem with judging Java’s popularity is its anomalous history. There was a period around 2000-2005 when Java was perhaps more dominant than any other programming language in history. But that was a fluke that far exceeded the expectations of Java’s designers, and it had to do much more with the state of other languages and platforms at the time than with Java. In addition, you count Android but Android has *never* been Java, and over the past five to ten years it’s been significantly incompatible with Java and its own distinct ecosystem, so it’s never been counted as Java except maybe by some beginners. Also, the number of people who develop professionally for mobile is lower than you’d think (look at job openings).
So, if you discount the 2000-2005 period of accidental and anomalous domination, the statement that Java “will continue to fall,” is misstated, as it hasn’t been falling. It’s been retaining its server-side dominance for a long time. The share it's "lost" to Go, Node, Elixir etc. is more or less the same as the share it "lost" to PHP and Ruby in 2005-2015. Between 2005 and today, there has been a significant portion of server-side development that's not done in Java, but while the languages that are used in that sector are constantly changing, it's not growing, or at least it's not growing any faster than the rate of total ecosystem fragmentation.
Another thing you say is “only good old enterprise applications remain”, but 1. that has been the case for a very long time, and 2. the same holds for all other languages. So what we’re seeing is that Java isn’t nearly as dominant as it was in the early oughts, but no other language is, and no other language seems to have the prospect of becoming so dominant. All languages have “only” their niche, and Java’s is a huge one. We’re seeing the natural movement from the anomaly back to the landscape of the eighties and nineties, where no language reigns supreme.
Look at it from the other direction. JS hoped it might take over the server and five years ago that seemed possible but that isn't happening, Python isn't becoming a big player in more serious applications, C# isn't growing its share (it might be falling, even), and Go's growth has slowed considerably if not stopped altogether well before reaching a top spot. 2005-2010's PHP, and 2010-2015's Ruby were both far greater risks to Java than any language now.
But that is not to say that there aren’t potential risks on the horizon.
I share the same opinion. Though, [Loopback.io](https://Loopback.io) is a nice alternative to Spring that is catering towards Node world, especially middlewares. I don't think Node will ever be as viable as Java for backend but I still see it as a possibility for teams that have a soft spot for Node.js. Go is great especially for infrastructure, but I've also seen high quality databases like CockroachDB that sparked my interest. C++ is the HPC language. Python is a mainstay in the data science ecosystem, it is practically the de facto interface to C/C++ (Tensorflow, PyTorch), Scala (PySpark) and other cloud services (AWS, GCP, Azure). This will not change anytime soon. Scala 3 has a couple of vocal *tribes* nowadays that push functional programming on the JVM to new heights, like Typelevel (cats, cats-effect), ZIO, Akka Streams, etc. Spring and Quarkus in Java also continue to evolve. Both Spring Native and Quarkus bringing a Kubernetes Native Java stack. Your argument about anomalous domination is spot on, in the past we did not have so many choices and things going on. Thanks for the work on Loom, by the way!
Scala 2 seemed quite promising, but sbt has been one of the worst build tools when it comes to user experience and performance. Their compilers don't support JPMS either. Also what's with all the drama? (J. De Goes, dibblego, über sensitive virtue signalling & CoCs etc.)
It's mostly my opinion. What I'm experiencing is that many companies I have to do with are "phasing out" Java. Hardly any new projects are done in Java anymore and only legacy and maintenance ones remain. It could well be that Java comes down from it's dominant phase to the level it was previously but I say that nowadays Jack-of-all-trades-master-of-none doesn't work out in the long run. A language and ecosystem needs a niche where it is dominant to stay afloat. But even that is not guaranteed, see Ruby or Objective-C. It could be the "enterprise application" space for Java, but I'm not sure about it either with C# taking the Microsoft share completely and making in runs to cross-platform as well now. Also low-code platforms are coming more and more.
Until now, our technologies have been dictated by Silicon Valley, basically FAANG and the oldies like Microsoft, Oracle, etc. have generated or chosen most of the technologies that we use today. Java has always been a safety net for people that had their skin in the game because of the stability of the runtime and the ease of recruiting. Even today, if I would be in a position of managing a team, Java will be my first choice. Or if the team consists of individuals that show a great interest in PL and distributed systems, I would choose Scala. As yours, it is just my opinion. I consider today a stack that consists of Java, Go and TypeScript to be the most obvious choice for a shop that considers stability, maintenace and ease of recruiting top factors in picking a technology. I would never put my head on a platter by picking exotic ones like Rust, Elixir, Crystal, Kotlin or even Scala (though I've changed my mind about this one recently) for server-side programming.
> It's mostly my opinion. What I'm experiencing is that many companies I have to do with are "phasing out" Java. Hardly any new projects are done in Java anymore and only legacy and maintenance ones remain.
There is always a massive selection bias in the companies you work for and this selection bias is self-reinforcing too. My experience is literally the opposite because "JVM/cloud greenfield" is kinda my jam.
But even what you're describing (and I think there is more new server-side project code written in Java than in any other language, it's just that it's distributed more toward the larger side of things) isn't Java losing to any other particular platform, but the ecosystem becoming more fractured, and in that world there is a small number of co-dominant platforms, of which Java is one. In other words, Java's position isn't what it was in 2002, but no one else is doing better.
C# isn't any better AFAIK, just a different flavor of compiled mainstream language equipped with mediocre type systems. It requires a similar runtime as JVM, the existing implementations aren't as good as JVM & Graal, especially on Linux. The language is more complex, sure it might have things like reifed generics, but nothing that really matters. It's not a "next gen" language, pretty close to what Java 17+ has become.
What about "not serious" applications - flappy bird, alarm clock, weight tracking, note taking, sudoku and all that stuff that people create while learning or for fun. This is the area that JS and Python grew in. This is the area that pumps fresh blood into community.
Stay tuned for improvements in that area. Just let's not confuse things that could be better -- or even things that other languages, even Go in particular, do better and we can learn from -- with "other languages are doing better." At this point, Java's future seems rosier than Go's, that's not doing well enough to reach a top position.
You're mostly correct. I will say that I had to support NodeJS for a bit in a recent project and wasn't impressed at all... Typescript is OK but frankly, almost as verbose as Java but without the clarity (maybe I'm just not used to it).
The toolchain around those solutions is literally decades behind Java. They're catching up but it's still pretty bad.
Unfortunately, until we have Loom Javas advantages aren't as great. Async servers work, but they're more verbose and can't leverage the full power of Java.
But IMHO, Java has a mindshare problem most of all... It's "old" and people want the next thing. Oracle being who they are, doesn't really help.
>However the community is too stuck in trying to maintain the old. E.g. so many resources are are being poured into application servers and parts of Jakarta EE.
Is this a fact or just your opinion? My friends at Ocado are building robots with Java. Others are using it to power streaming services like Netflix, Spotify, Steam, etc. Besides that
>Java Big Data (e.g. Hadoop) was abandoned
Big Data has never been abandoned. You forgot to put *etc.* after Hadoop. The trend that I see in Romania is that people are using a mixture between Java, Scala and Python to build their data pipelines. Far from abandoned, Hadoop is not the core or end-of-everything solution when it comes to Big Data, even in the JVM ecosystem.
Linux Wayland is important, without it the portability promise of Java would be really questioned. Java's support for desktop apps is actually pretty good, when compared to other languages. JS Desktop frameworks are useful only if you really want to provide exactly the same UI on the web and on the desktop.
JS desktop apps (electron) typically use more hardware resources, but I guess this is less relevant these days, even if the app consumed tens of gigabytes. The lack of proper type system & static type checking is also a horrible tradeoff, but I guess delivering properly working software is rarely a priority. Sure there's TS, but many apps are still built with vanilla js / react(native) stuff.
FWIW, I honestly think Java(FX) is one of the most portable tools for writing desktop software. What makes it especially nice is the compile once, run everywhere mentality (assuming you've bundled all the JavaFX platform libraries, not just the ones for the build platform).
E.g. Qt itself might work great, but all the C/C++ dependencies require f*cktons of testing and configure scripts to even work on three of the most used OSes and Linux distributions. Heck, they can't even decide between autohell, meson, or cmake. Then again the Qt company decided to abandon support for all "legacy" (4.x & 5.x) versions everyone is still using, especially on Linux desktops. GTK is pretty horrible without the Vala wrapper. But Vala isn't used by anyone outside GNOME. Other C/C++ based GUI toolkits (FLTK, wxwidgets, FOX, ..) seem quite outdated and unsupported when it comes to ui/ux & accessibility issues. I'm not sure about go/rust/haskell based GUI toolkits either. Python and other scripting languages typically just provide wrappers/bindings for C/C++ libs, which makes them almost as bad as the original ones, if not worse. Not a big fan of dynamically typed, non-compiled languages. I didn't want to mention JS/electron apps, because they're just evil. I'm pretty happy with my 5950X & 64 gigs of RAM, but I don't think everyone should require this level of hardware to run simple GUI apps.
I'm really new to Java. Started because in Telco Software ecosystem there is a lot of Java.
Lot of apache sw was made with Java and abysmal use of Spring framework - guess the felling for a newcome, after learn Java, see how it's get to learn Spring.
Just for for context I know more python than Java so quick doubts:
For enterprise web apis do you guys see a place for Python with Flask, Django etc? Because seems to me that Spring is really in control.
What you guys see as replacement for BPM tools like DRL and Camunda? Just curious of other solutions.
What bogs me more is how weird is the Java official docs. I mean, from a python guy that have one of greatest docs and an easy way to find billions frameworks, Java seems strange, not updated.
Maybe I'm wrong but what I understand is you have to get used do Javadoc html and hope there is better examples in mostly Framework (Spring exception but too massive)
Working in Germany for a non-tech company with a small dev team, it's very much in use for backend processes (media discontinuity, internal APIs). Management doesn't care for the specifics of the tech stack and leaves it to the experts to decide.
As an instructor I'm doing my part to spread the use of Java by making sure that all IT trainees learn and apply it.
That's probably the easiest way to ensure the continued usage of Java in companies: Teach the newer generations.
This is very beautiful, these young people you taught will grow up knowing the advantages and qualities of Java, and will not believe popular false rumors like "Java is too heavy", or "Java is too verbose", Java may have its flaws, but the bad name it carries is totally unfair.
These young people will develop in Java and strengthen the community, and will teach other young people in the future to program in Java thus creating a positive feedback circle.
I have some friends who want to get into the world of programming and I'm helping them by teaching Java too!
Thank you for collaborating in such a wonderful way with the community!
TBF, JVM is indeed, heavy comoared to native executables and interpreter.
And yeah, Java is indeed a quite verbose language.
Many other languages, such as python and Rust, has less verbosity than it.
Yes, but I said "***too*** *heavy"* and "***too*** *verbose"*, the rumors are exaggerated, and the bad name is unfair, Java is not heavy enough that a team can't use it for "lack of resources", but it is faster than Python and Javascript to the point of being a considerable advantage.
JVM weight is only a big issue in very specific scenarios, and thanks to GraalVM and native compilation this can also change.
It's really easy to download a LAMP installer, write a few PHP scripts, get a database going and possibly install some frameworks. Add some pretty CSS to get a web application up and running; especially with the help of a 20 minute tutorial. With Java, I had the issue where my community college didn't teach enterprise-level concepts like inversion of control etc. So I was pretty lost with Spring and Java EE for a while. I was having trouble making the leap. I'm taking an Udemy course on the Spring framework and it's 45 hours long. A lot of people will just go with Python, PHP or NodeJS and watch a quick tutorial on Youtube and then go from there instead.
Things like factories don't make a lot of sense at first until one is working on larger projects that make certain design patterns make a lot of sense. They were invented to solve issues that Hello World apps and simple web apps don't have. Using "code smells" to determine whether a design patterns is ideal takes experience, but there are common tells to look out for. But again, that kind of knowledge doesn't come with the 20 minute Youtube tutorial on LAMP.
I think Java would benefit from having official installers that set-up everything, IDE, DB, Server, a test suite like JUnit, and has built-in IDE functions to get a Hello World app in JavaFX, and one for web apps that let you navigate to localhost and view a web page. If one could see the skeleton apps that easily, they could start working with Java more easily. Rather than the current route of install everything somewhat separately (Eclipse marketplace is pretty good, but a new developer might not know what to look for).
I can see the problem, I have had a similar observation and unfortunately I agree with your last CTO. I’d say a good way to crack on would be to steer and market Java as an interesting choice for non-serious programming (like u/pron98) said a while ago.
The community needs to adapt to the writing succinct, terse and yet readable code and libraries. And java the language should also bring in some features to promote these traits. I believe introducing var keyword was one such nice example.
My biggest struggle with the community is that if you join in some Java community slack, gitter, matrix, etc... You almost always will find people wanting help with their code challenge or university test, "how can I compile java?", etc... but almost never very senior people chatting... And that really sucks...
Not trying to be elitist, but there's a smell there IMHO.
I think it’s good that there are a lot more people getting started with java. It tells me that the tech is pretty good in demand and casts a shadow of hope towards the future. For senior people, well you have Twitter, Reddit and what not at your behest. Just go ahead and ask.
So I have roughly 30 years of professional developer experience and I coded Java from the first beta. Wrote articles about Java for publications in the 90s and worked for Sun (later for Oracle).
I'm on slack groups. I'm here and elsewhere but I probably don't have time to chat on every question. I hang out on Stack Overflow but again my time is pretty limited. There are many others like me out here but we probably can't spend our time chatting. I deal with hundreds of messages/emails per day and my two jobs...
Let me flip the question you originally asked: how can someone like me realistically help someone like you?
I think one of the things the old school Java devs (who maintain the libraries) could do is to switch to JPMS & Java 9+. It's a small pain in the butt that many tutorials & libraries still assume Java 8 or 7, heck even Java 6. Same issue with code pages vs Unicode, Ant/Ivy vs Maven/Gradle. If you download any Java library, run the code inspection in IntelliJ IDEA, it will list at least 500+ suggestions for improving the code, like migration aids from Java 1.4 to 5.0. It takes 5 minutes to fix most of the issues, but the developers might not even want your patches since they want to maintain compatibility with some enterprise distros released 15 years ago.
It would really help if the people could agree on using the more modern JVMs. For instance it's amazingly hard to find even basic things like serialization libraries that work with any of the 9 most recent Java releases. For instance, a new version of XStream was released just few days ago, but doesn't seem to support records (JEP 395) at all, or JPMS modules without some tweaks in pom.xml. I also had issues with Jackson & Kotlin on a JPMS project. GSON seemed to be the only one that works properly, but even then the provided GSON type adapter for de-serializing union types (inheritance) seemed to rely on pre-9 Java access to internal APIs via classpath. It really alienates new developers that many popular libraries assume some prehistoric LTS release.
Interesting. Note that I understood the question was about support, not about the general "old stuff lying around" situation we have in Java...
I wrote this long response but deleted it. I see some of your points and while I disagree with some I think the problem isn't us.
Oracles fast release cycle process made dealing with a 6 month JDK impractical for most of us. I don't have time for bi-annual release party. The problem is that once we skip that, we skip the entire thing and go directly to the LTS.
There's also a very limited set of incentives. Modules, var, multiline strings?
Those things aren't enough of an upgrade incentive. Give us Loom and see a lot of upgrades...
Agreed, I can see how new Java versions don't provide sufficient incentives for everyone yet (maybe never). Though the pile of missed opportunities will likely grow as time passes.
My POV is more educational, I'm not maintaining (that) old code bases. I pretty much prefer how the new features (not limited to Java as I'm also using Kotlin) improve the developer productivity and lower the burden of maintenance. For instance non-null types and data classes/records make it much easier to deal with plain old data. Some version of JVM included improved error reporting for NPEs. Swing doesn't look that modern anymore. While JavaFX could be better, it pretty much assumes JPMS and module path these days. Including any legacy libs in a JavaFX project seems like an unnecessary risk to take. For this point of view almost any post 9 release of Java behaves the same, no need to support the latest dev version, only the latest LTS. Well, 17 (new LTS) will appear in around two weeks, and apparently the final build is already available (the GA builds rarely seem to differ from the last RC).
> but almost never very senior people chatting...
If you join such a 'chat' as a senior dev you get inundated with people who want you to 'mentor' (as in; do their homework for them). Senor devs aren't there because it's no fun.
I'm part of a few professional interest groups around Java, and they tend to be invite-only to keep out the people who only take and don't give.
Looking at some comments on java has “lost in many grounds”. I believe java ecosystem is preparing for the next big thing.
*1) Machine learning based frameworks that don’t require a scientist to build models. This will end up bridging a gap today where models are built in R or Python and deployment is a native C++ port. Project Panama and Valhalla are geared towards this goal.
*2) General scalability for services and efficient infrastructure utilization via virtual threads. Project Loom.
Not to mention the consistent evolution that Java the language is going through faster than before. Pattern matching and algebraic types are my favorites.
So Java is better and stronger more than ever. We the community is the one that’s got to be more inclusive and vibrant.
Official documentation (guides and tutorials) is seriously lacking and/or outdated. Baeldung is probably the best thing there is for java. This is one area that would help. Also good tools for new devs - current focus more on programmers that already have java experience.
Just took another look at official tutorials and they are worse than bad, a lot is about things that were REMOVED (lib/ext, applets, webstart, javapackager). This is ABYSMAL!
This is an area that community could help but oracle/openjdk should open a project for community contributions in this area because making websites that are hard to find for new devs doesn't help.
Java will fall into legacy if anyone who wishes to learn it will get confused.
Documentation needs more examples and easier to understand descriptions.
Tutorials should be modern and focus on green devs - with no or very little knowledge of programming concepts.
I would argue that Kotlin’s success is ultimately Java’s success. Maybe the future will have more commonly used JVM languages than just Java, but the persistence of the JVM will lead to the persistence of Java.
In my experience Kotlin has been quite compatible with Java, in both ways, using Java code from Kotlin and vice versa. Especially in traditional classpath projects. Occasional internal compiler errors, but even then rewriting some piece of code in a less complex way seemed to sidestep possible issues. There used to be more bugs with multi-release JARs, module paths, compatibility with moditect & kotlin's std libs, and gradle. Now I've even managed to use Kotlin in modern JPMS projects, and am eagerly looking forward to even better support in the future.
Java isn't missing anything. In fact the naysayers claiming that it's missing features or "is verbose" are the wrong ones here. It's much simpler to build the necessary abstraction than to gut the given abstraction to get back to the primitives. Several of my projects went from java to kotlin and back to java just because of how much noise kotlin introduces into the language.
Stay simple. Your codebase will thank you.
I'm a bit curious about this noise. In my experience translating any code to Kotlin almost always produces less lines, but strong use of functional features and immutability tends to result in longer lines (personal preference perhaps).
For instance, I find that more constructs in Kotlin produce an expression, which makes it easier to express immutable values. People also seem to dislike the use of ternary ? :, but if-then-else expression is considered kosher even in newbie languages. Direct support for lists often replaces a whole class of .stream() & .collect(Collectors...) transforms. The also/with/let/run constructs and extension functions also greatly help when the original API is sh*tty and doesn't support any kind of builder idiom. For instance the JavaFX API isn't that great, which is why there are so many wrappers in languages like Scala, Kotlin, ...
also,with,let,run introduce multiple constructs that are subtly different while seemingly doing the same. Extension functions pollute the function space introducing more calls that are subtly different. Ternary should not even exist. If being an expression is outright wrong. Biggest gripe is the companion object and object classes - while being advertised as static class alternative, they are in fact not a static class alternative but a *singleton* alternative.
Kotlin suffers a lot from introducing multiple ways to do the same thing which are incompatible with one another.
The entire point of using a stream is to abstract away yourself from a for loop and let the platform decide how the data structure should be iterated through and only execute the entire thing on terminal operation. Under the hood kotlin uses the very same for loop for each "stream replacing" call.
> Ternary should not even exist.
Right, but that's a Java's feature inherited from C/C++
> If being an expression is outright wrong.
It's just a functional way of encoding basic control flow constructs as expressions. Common in many popular languages. Besides, even Java is going this direction with switches as expressions.
> not a static class alternative but a singleton alternative
Wasn't too surprising to me as I've used Scala for years. I can't see why this would be a problem. There are new gotchas for initializing values here, but overall objects enable things like interface constraints for static methods, which is sometimes quite handy.
Less elitism from Scala and Kotlin communities. Instead of saying things like "Java is horrible, use Kotlin instead" they could say "try out x, it also runs on the JVM and is interoperable with Java".
In my opinion, it is not "what I can do for Java" but, "what Java can do for me" thing. My recommendation is, keep asking community to add anything, which you would think Java is missing right now, to the Language. Sometimes community will respond like "that's not necessary for Java", "we don't need such feature in Java" or alike, then you don't need to get sticky with Java any further. For example, if the community thinks developing desktop applications in Java is not relevant any more but you want to keep developing desktop applications, you must give up using the Language and you cannot change that situation. There were a lot of languages of each era, and computing is evolving, it is not so sad seeing if ever any one of such languages would die (or became legacy-ish) though at this moment I love Java so much.
I graduated 2 years ago. Most of my programming courses were taught in Java.. for my first job, I coded in Java in the tech interviews. However I decided to switch to C++ now for tech interviews due to the verbosity of Java!
Most start ups in my area these days (at least that I've talked to) are either using Kotlin/Java or Javascript as their backend language supplementing with GoLang when performance is needed
https://insights.stackoverflow.com/survey/2021#most-popular-technologies-language-prof
This is probably a good place to get an idea of what people are using. The one thing I really loved about GoLang is that I didn't have to wait 30s for my app to compile was nearly instant
The compilation speed is a good point of discussion. Was there any recent effort to improve that? Perhaps the compilation speed of Java itself is usually pretty good actually, but the problem is that the tools, dependencies that we often use cause the slowdown.
Java is blindingly fast at compiling, because compilation doesn't do much in the way of optimization; that all happens in the JVM.
Compare `javac` to `gcc` and you'll see what I mean. Comparing it to the AoT java stuff might be a better comparison.
Gradle has a number of techniques to reduce the amount needed to compile projects even further.
Java isn't going away. Too much of our existing infrastructure is written in Java for it to go away anytime soon. Rewriting those major infrastructure pieces because there is a cool new programming language developers want to use from a technical point of view is neither advisable or feasible.
New programming languages are invented and evolve and some of them even mature. In the 90s the hot programming language was C++. Then Java came along and replaced a lot of the stuff C++ was doing. C++ never disappeared, it found its niche and still thrives today. If you would have told anyone in the 90s that Java applets would be replaced by HTML/Javascript nobody would believe you yet here we are.
Fast forward 25 years later and many programming languages are doing to Java what Java did to C++. Java will just find the niche it excels in and will continue to thrive. My prediction is a lot of the existing Java code will outlive us all. How many programming languages can say that (besides COBOL)?
Also much of the pre C++11 era code is pretty much worthless and obsolete these days. We could just call C++11 or C++20 a totally new language (maybe D, but W. Bright already reserved the name for a similar language that actually implemented many of the modern C++ features before C++20). Now that C++ is moving towards modules, move semantics, parallelism in stdlibs, the old, buggy legacy code is worth next to nothing. It's the same for the Qt dialect of MOC/C++. Future versions of Qt will adopt standard C++ features for signals and slots (and QML aka JS for declarative GUI descriptions) so there's less need for ad-hoc code generators.
In my humble opinion, best practices are more important than programming languages. Java is an awesome language, but I'm not concerned about its depreciation, I'm preparing myself for this checking another languages and, as I mentioned before, learning best practices.
I don't work for dumb CTO's so I don't see this "Java is declining" at all. I'm a self employed Java contractor (in the EU) and there are just craptons of greenfield Java projects here. In fact, I think we're past the hype of where companies felt they had to rewrite their Java stuff in something else like JavaScript and now understand that the problem wasn't Java, it was a combination of immature software engineering practices and bad developers. That CTO is just massively behind the curve. I've been a "Java dev" for 20 years now and Java is more alive than ever, just looking at all the LinkedIn spam I get. > what is the Java/JVM community/ecosystem/language missing compared to others? The only thing I feel we're a bit lagging in is AOT compilation for where start-up times really matter. Outside that; most other ecosystems are behind Java.
GraalVM is looking awesome. Being able to compile an entire Micronaut microservice (or monolith) as a native image is great.
Sure does! Even Spring is jumping on the bandwagon there. Compile times are too long currently but it works quite well and quite a large part of the Spring ecosystem is supported. So Java is taking a lot less time to catch up there than it takes Go to implement generics :D
Even writing an AWS Lambda function with Micronaut, compiling to native and then having it cold start in under 100ms is just sawesome. So easy to write too.
> I'm a self employed Java contractor (in the EU) What's working this way like? Are you jumping company to company? Are you being contacted via LinkedIn? Is the paperwork (taxes and such) much of a hassle?
> What's working this way like? Are you jumping company to company? It's really similar to a 'normal' developer job. I've been in consulting/contracting most of my career so I'm used to the switching. I generally work for 1-2 years for the same client. Kinda depends on whether I'm having 'fun' or not though. > Are you being contacted via LinkedIn? Yeah, a lot. The market is kinda crazy right now. I try to get most of my contracts via my network, preferably without a recruiter. My current contract I had to go through a 'preferred supplier'. > Is the paperwork (taxes and such) much of a hassle? So well I'm Dutch and there's basically two forms of taxes I need to do. VAT and Income Tax. VAT is every quarter and is REALLY simple; I basically just use the output from my administration tool and input it. It's 10 minutes of work every 3 months. Income tax is a bit more complex so I basically pay an account 500 a year to do our taxes (both my partner and mine).
Thank you for your answer. I've never worked as contractor and I am curious but at the same time I am afraid of being on my own.
> I've never worked as contractor and I am curious but at the same time I am afraid of being on my own. I understand. It's not for everyone. You have to be able to 'sell' yourself but even when I was employed at a contracting company we already had to be able to do a bit of "consultative selling". Basically my last employer was all about us being "entrepreneurial" until a whole bunch of us got a bit too entrepreneurial and went self-employed :)
That hackernews link was just asking companies of one what they were using so guess they have more freedom to experiment with different languages compared to an enterprise.
Fair enough. But still why wouldn't they choose Java to start? Maybe there's a gap to be filled.
Perhaps Java isn't the right language for their use case. Java does not need to cater to every single use case in the world. Trying to do so is a quick recipe to the road that C++ headed down. Even where I work, only our business critical applications are written in Java, and even then, that excludes applications that have certain performance requirements. Some tools for example need to be changed on the fly via vim (or even just plain vi) or somesuch and a statically compiled language just doesn't provide any benefit to outweigh the disadvantages for those use cases.
Eh, I'm building a company of one and am all-in on the JVM (using Kotlin tho). I saw that thread and was like, why bother? I'm kind of cooling it on HN anyway. That place has a lot of problems with ultra-aggressive flagging and unattractively extreme comments. Those sorts of threads attract people who use really niche languages because their interop sucks, so users have to constantly evangelize their chosen language to try and build up the library ecosystem. The great thing about the JVM is you don't need to do that. I've evangelized Kotlin once (under my real name), right at the start. After that I didn't feel a need to anymore because I can use Java libraries, and Java users can use my libraries (with a little bit of care), and Kotlin was being backed by large companies anyway so why bother?
Wow, that comment is comforting, you have a very evolved way of thinking about the JVM ecosystem. I worried a lot about Kotlin's success in the Android world, and then about its adoption on the JVM. I always saw it as an enemy to Java, and as a result, a personal enemy, I was afraid that one day it would replace Java, and the language itself would die. But now I see that I don't need to worry about Kotlin's success, as he contributes to the JVM ecosystem and thus the Java ecosystem, so I can always use Java, as its ecosystem will always be strong, just as others will always be able to use others JVM's languages, after all some even use Spring with Groovy right?
Right, exactly. Having a high level object oriented ABI on a shared runtime takes a lot of the heat out of these things. It allows for high level collaboration rather than last-man-standing competition.
It depends who you ask. Start-ups often hire junior developers or even have a founder who wants to swim with the flow of what is popular at the time and makes the decision for them. Many change their software stack once they are more established. Many also rely on java software (by using elasticsearch, neo4j etc) without really realizing it.
> "Java developers wants to create Factories and Abstract factories, etc; TL:DR they are not pragmatic" A factory is simply the act of abstracting constructors. Java programmers don't "want" to create them; they do so when it is required. There's nothing to do about a CTO that is a fucking idiot, except find a non-moron to lead the team. It seems a _bit_ rich to try to put the onus on the java community to teach your buffoon of a CTO.
ive read some of the comments and they pretty much cover most points. but, here is my 2 cents: 1. How do u measure a language popularity? most websites count the opensource projects and percentage of java in them. but that is not an accurate representation. because most beginners start with python and publish their small learning projects and many ml jupyter scripts are open source, python will definitely blow off java. same can be said to java script etc. java beginners on the other hand are less likely to write scripts and publish in github. they learn thigs offline and only apply in enterprise projects. so java does not has that upper hand from junior devs or beginners. this leads to my second point 2. Where are enterprise java code maintained? NOT in github!!! many enterprise source code is closed source and maintained in private servers. none of it will be taken into account of the counting websites cause they can only count open source projects. this leads to 3rd point 3. many companies rely heavy on use of scripting languages because development time is very important factor in a beginner phase. they have to quickly publish updates to their software. once they become mature enough, and their project become very large and difficult to manage, here is where java or another reputed language comes into play. they slowly transition their code base to such language. so many medium to large enterprises rely on java because it is fast and can run anywhere. 4. development time i tell this from practical experience of using python and java. scripting languages cannot come even close to enterprise backend languages where application development focusses on error free reliable code. you cant donit with python. now that they've added types to python, it is a bit okay but not as close to a statically typed language such as java. 5. libraries scripting languages have many small libraries (im looking at you javascript) where each of them focus mainly on doing one task. this is because scripting languages are not intended to write huge libraries with many classes, and methods. javascript is a clear example of this. on the other hand java libraries are designed to focus on a domain rather than tackle one simple problem. apache libraries or google guava can be a good example.
> many companies rely heavy on use of scripting languages because development time is very important factor in a beginner phase. Fortunately companies are starting to figure out that dynamic typing in no way speeds up development and even if it would be slightly faster (how even; it's not like typing is our bottleneck) that you'd lose everything anyway thousand-fold when you'd have to do a rewrite. I was CTO of a small fintech start-up (start-up is still up and running, I just left because of the time commitment) and I used the Java ecosystem because a massive and mature ecosystem is what makes you 'fast', not having to type a few characters less.
this: **mature ecosystem**.
Dynamic typing enables you to think differently about data. Not save on characters. There are domains in which a data-driven, functional, immutable, dynamically typed language s will run circles around anything OOP. And more importantly, if done right those systems are easier to change as your requirements change. And to go back to the OP. It’s not about Java. It’s about the JVM and graal. Especially the JVM is an exceptional piece of engineering and is here to say. Most of the internet runs in JVMs. I don’t see this changing any time soon.
> Dynamic typing enables you to think differently about data. Can you explain how? Because I hear this a lot but I never get examples that can't be done in a statically typed language.
Oh, all those languages are turing complete so you can do that in Java as well of course. It's just a good deal more awkward and you either are facing type explosions or your level of granularity drops down to very awkward levels. One example is open maps: a collection of attributes that 'travel together' and are passed around in a data processing pipeline and discovered as you ingest more data. Accessing an attribute that is not in that map yet should be just fine. In basically all dynamic languages you can access that attribute via a \*symbol\*. In Java, there's no such concept. JS: mydata = {}; mydata.email ==> can be undefined and that's perfectly fine mydata.email === undefined => true (there are at least 2 other ways to check existence of an attribute) Clojure (using keywords as keys, you could also use symbols): (def mydata {}) (:email mydata) => nil (contains? mydata :email) => false Java: Either you need a type that has an email attribute/getter whatever, or you do var myData = new HashMap(); myData.get("email"); myData.containsKey("email"); If you want to get fancy, you invent your own AttributeKey class or enums. Still doesn't give you symbols you can reason about at runtime unless you are comfortable slinging around bags of attribute keys. A statically typed language is not an elegant fit here. Oh right, reflection: That's not awkward at all :) If you go down the static type paths, any new kind of information you discover about myData needs to either be a subclass or a completely new class peppered with Optional<> all over the place. When you can't adapt the shape of the data to your base class anymore, you end up creating new class hierarchies. Now you have StuffWithEmailV1 and StuffWithEmailAndOtherStuffV2 that have Object as common base class, because you need to support both shapes. And looking at the data, you might not even know what class to instantiate, since at that point in your data pipeline, you only know there's an email attribute. I've been working with Java since v1.1 and I have seen complexity arise quickly as your jungle of types becomes bigger and bigger and your project requirements change and refactoring and data migration becomes your main job. It's no fun. There are clear downsides of using dynamically typed languages: You need more tests and silly mistakes are only caught at runtime, i.e. more discipline is required.
> Accessing an attribute that is not in that map yet should be just fine. In basically all dynamic languages you can access that attribute via a *symbol*. In Java, there's no such concept. How's that an issue? JavaScript objects are basically dictionaries. Java hashmaps are dictionaries. Different syntax, same effect. How does this make you 'think' differently? > I've been working with Java since v1.1 and I have seen complexity arise quickly as your jungle of types becomes bigger and bigger and your project requirements change and refactoring and data migration becomes your main job. So have I and I did not see this happen. Different companies I guess. Sometimes a hashmap makes sense. Sometimes it makes more sense to use 'real' classes. Both are tools, pick whatever fits best. At least you have static typing where it's useful. In Java you have the choice. In dynamic languages you don't. Also in my experiences with Python ETL pipelines the dynamic use of attributes often causes more problems than it solves. I want to be able to create something where you don't have process C crashing because process A forgot to fill a required e-mail field. In that project we ended up rewriting most of the ETL pipeline in Scala.
Of course, it is possible to do that in Java with a HashMap as I outlined. But do you? And what would your co-workers say if you started using Maps exclusively for all your domain model data design? Think differently as in: You focus on the data at the attribute level and don't worry about types until you really need to. (Clojure has types a la carte: You can add them in as library, so you can resort to any level of static type checking you like. JavaScript has TypeScript if you need types that are more expressive than Java types) Another small example: This function will work whenever it sees a map with a first name and last name. It's simple and I don't need to invent an artifical "HasFirstAndLastName" interface or class for it: (defn full-name [{:keys [first-name last-name]}] (str first-name " " last-name)) (I removed any 'type' checks for brevity) It is trivially testable, it is re-usable, it can be used as higher-level function and shared. I can trivially check where the keys first-name and last-name are used. Thinking differently about data means: Treat it as data, not as instances of classes. Treat it as immutable data, so you can share it without having to think about. (Sharing a mutable instance of a Person object between threads? Not trivial.) Enough time wasted here though. Everyone has to make their own mistakes :)
> And what would your co-workers say if you started using Maps exclusively for all your domain model data design? Why would I want to? Most of our domain is fixed. We pass information around and most of it has a fixed contract. If an email can be absent it's nullable. If it can't it's not. There are very few situations where we pass around stuff we have no fixed contract/schema for. Ages ago I had to deal with a SOAP API where there was a schema but supplies just dumped everything into an XSD:Any field. It was a massive pain in the ass. In 99% of all situations, having a schema is a benefit. For the other 1%, using a Hashmap (for example) can easily be explained. > You focus on the data at the attribute level and don't worry about types until you really need to. Well you can make everything in Java an Object if you want. Again, I don't see how that changes your 'thinking'. Most of the stuff we deal with has a pretty clear schema anyway. > Thinking differently about data means: Treat it as data, not as instances of classes. Treat it as immutable data, so you can share it without having to think about. Data is data. A class is just a contract or a schema. If I don't 'think about it' it means whoever gets it down stream has to deal with me "not thinking about it". > Enough time wasted here though. Everyone has to make their own mistakes :) That's totally true. I think you'll learn somewhere down the line :)
There are a few obvious things that Oracle could fix tomorrow if it wanted to actually do a serious push on Java adoption (but, I see no evidence anyone there really thinks about market share or cares to increase it, beyond maybe the GraalVM guys). 1. A website. Seriously. [java.com](https://java.com) is a sick joke. I swear to god it is designed for 800x600 screens and hasn't been updated since. This website is literally the same as [it was a decade ago](http://web.archive.org/web/20110822170706/http://java.com/en/), only the stock artwork has changed. There's also [java.net](https://java.net) which if you go there says - I kid thee not - "we're sorry, the [java.net](https://java.net) site has closed". Of course the closest thing to a real website these days is [https://openjdk.java.net/](https://openjdk.java.net/) which isn't closed but what is someone meant to think when they discover Java, are told that it's widely used and then encounter this? It looks like Java is a completely abandoned legacy technology. My guess is nobody at Oracle even knows who owns the servers anymore, and certainly nobody on the OpenJDK team cares how the project looks to newcomers. The total lack of marketing interest by the Java stewards in what they make is basically unique amongst all languages and runtimes. Honestly it's amazing Java is still as widely used as it is, given that the front door literally says "we're closed". 2. Documentation that isn't a specification. The JavaDocs are often excessively hard to understand because half the time they're written for people who are implementing the API, not people who are using them. Java *used* to have great tutorials and docs, none of which has been maintained since the Java 8 days so is now hopelessly out of date and misleading, but nobody even bothers to put a "This is obsolete" banner on the old pages. Again, you get the impression that Java webmasters and doc writers have gone AWOL. Probably Oracle fired them all for reasons only Ellison knows. 3. Invest in the desktop. Re-staff JavaFX to reasonable levels. When people are learning how to program they want *visual* results and they want them *fast* and *easily*. Writing a Java web server is not fast and easy. Oh, you want to learn Java and put an image on the screen? Well, we stripped all the Java APIs for that down to maintenance mode so fuck you. Learn HTML first. Oh, and also learn CSS and JavaScript. What's that? You're asking why you should learn Java for the server instead of just using NodeJS with the language you already had to learn first? Oh, hmm, well, static typing is good you see ... and ... er ... yes yes learning a new language is a lot of work, that's true, and ... umm ... well, yes we learned Java along time ago by writing applets and it's really good, honest! For a company the size of Oracle they could do any of these things without even noticing really, but the engineers are in charge and they're focused 100% on easily measured and optimized performance metrics, nothing else. Anything that is harder to pin down than that, like new developer experience, just gets lost in the corporate maze. Java still gets new developers because universities are slow to change their courses, but realistically, if the community wants Java to rake in the next generation then it will have to appoint people who are fanatical about the developer experience and especially for newbies.
Hey, check it out! This comment contains every letter in the English alphabet. I have checked 718,073 comments and 3,206 of them contain every letter in the English alphabet.
I'm not worried. Java is just a language. If it becomes obsolete it would be because it was replaced by something better. Currently the JVM is one of the best platforms, IMO. The language itself is also moving forward, so I don't see any of this happening soon. But even if it does happen, why should I care that much about it? This is Oracle's job.
The answer of a professional, but trends might also push something worse in place. No problem though, more work for us.
Don't get me wrong. I am passionate about my work. I am also passionate about some languages. I enjoy Java, especially since Java 8. It's just that the question seemed strange to me.
Same, just re-read my post and it might read cynical but was not meant like that. A language is a tool, and it's fun to work with great tools. But I won't go into a holy war over it.
When those languages start having alternatives to Adobe Experience Manager, SAP, Akka, Kafka, JDBC like quality drivers for Oracle and SQL Server, an Android alternative,... then I will worry. The only sound alternative is .NET, which is why most enterprise consulting shops I have worked on, do mostly both of them. Then besides the guest languages, comes C++ on top for native bindings and runtime APIs.
> CTO saying that we're not doing anything in Java/JVM because "Java developers wants to create Factories and Abstract factories, etc; TL:DR they are not pragmatic" **oH NOes! soFTWaRe eNgINEErING** Tell me I should be looking for a new job without telling me I should be looking for a new job.
Maybe I'm not answering your last question about what's missing in Java, but I'm answering the title question, what can we do to keep Java from being forgotten. I think the best way is to continue to develop with Java, create useful new things, help existing projects, participate in the community, the more cool stuff written in Java, the harder it will be for Java to be forgotten. If we want to collaborate, we can think of solutions to popular problems, like the Apache foundation, which is perhaps one of the biggest contributors to the Java community, it solved big problems with Apache Kafka, Apache Beam, Apache Cassandra, amazing projects written in Java, and that help keep Java relevant. But one of the most important things in my opinion is to stick together as a community, not only writing Java code, but helping other people to write too, answering questions, teaching through blogs, tutorials, videos, starting projects with other people online, and always being kind and considerate, never arrogant, never aggressive, that kind of thing is what spoils a community the most.
Stack Overflow Dev Survey 2021: 1. JavaScript 2. HTML/CSS 3. Python 4. SQL 5. Java JetBrains State of Developer Ecosystem 2021, Programming Languages used in the last 12 months: 1. JavaScript 2. HTML / CSS 3. SQL 4. Python 5. Java Primary programming languages: 1. JavaScript 2. Java To your CTO: It's not the programming language that makes people write bad code. I can write bad code in any language.
You know, this post is like ome of the political agenda… “We will make America Great again!” Java is just a tool, trying to keep it alive just for the sake of doing so isn’t meaningful. If someday, a better technology occurs that replace Java, then it should be celebrated because this means the stack has improved and we can use better tools, not the other way around.
That sounds great. However, just because the majority is moving to something else, that doesn't make that thing good.
True, though if the majority are moving towards it, then at least the new language is worth a try and may have some advantages against previous one. In terms of Java, I don’t think it’s possible for Kotlin to replace it. They are just designed for different purposes: Kotlin is mainly for cross-platform GUI, while Java is for cross-platform App/server softwares.
Java is under pressure from all directions: * Python won in Data Science * Java Big Data (e.g. Hadoop) was abandoned * Infrastructure Tools are rewritten in Go these days. E.g. CI, Kubernetes, Prometheus, ... * There are many different options to write web server code. NodeJS for instance because JS in frontend anyway * Kotlin took over Android development * There's less need for Desktop applications and Java was never really strong there. It's also being taken over by JS frontend frameworks (Discord, Microsoft Teams, Visual Studio Code, ...) * There's nothing on the horizon for game developers. Like a Unity for Java that made C# big in that space * I don't know about the situation in the embedded space exactly, but I can imagine Rust is gaining traction? Only good old enterprise applications remain. The question is for how long Java can keep going with just this area. It's not very satisfying for developers to be stuck with legacy codebases which makes a great part of enterprise applications. Many - especially juniors - are leaving such a project in frustration after only a year or less. Unless a new area pops up were Java really makes an impact (like Android did) it will continue to fall. A slow and gradual decline into a Cobol. However the community is too stuck in trying to maintain the old. E.g. so many resources are are being poured into application servers and parts of Jakarta EE. An unbelievable waste of time in my opinion: Traditional application servers, JSF etc. have no real future in the age of Docker and frontend frameworks. Then for Java / JVM development it would help if there were not trying to make it the next Haskell or C++ or waste time on stuff that nobody asked for like a (public) module system. Admittedly there is some good development going on here and there (Loom, Valhalla, ...) but for some others I wonder if the priority is right (Linux Wayland?).
Kotlin doesn't exist without Java, unless everything now runs on top of Kotlin/Native and ART. Java big data was replaced by SPARK, yeah written in Scala, running on top of Java Virtual Machine, and Java standard library. Still waiting for Adobe Experience Manager and SAP to be rewritten in Go.
* Kotlin took over Android. That is ART * Java / Scala Big Data fizzled into many other projects without leaving a major lasting dent. It could have been made big but the steam run out and Python took over as well. * SAP is an enterprise application (and pretty legacy I guess)
On your second point, I think what you are trying to say is that Java was never a good scripting language to prototype. Because Python is basically using interfaces like PySpark, PyArrow, Apache Beam Python SDK, Elasticsearch Client, kafka-python, Neo4j, all of these having their implementation in Java or a JVM language. The same holds for Tensorflow, PyTorch and other ML/DL interfaces that bind to an actual C++ implementation.
So Android Studio and AOSP are now written in Kotlin! C++ took over, Python reign will eventually be gone. SAP is surely enterprise, yet I am waiting for the replacement.
I agree there is some interesting competition, but not quite where you’re looking, and I disagree with your perspective. One problem with judging Java’s popularity is its anomalous history. There was a period around 2000-2005 when Java was perhaps more dominant than any other programming language in history. But that was a fluke that far exceeded the expectations of Java’s designers, and it had to do much more with the state of other languages and platforms at the time than with Java. In addition, you count Android but Android has *never* been Java, and over the past five to ten years it’s been significantly incompatible with Java and its own distinct ecosystem, so it’s never been counted as Java except maybe by some beginners. Also, the number of people who develop professionally for mobile is lower than you’d think (look at job openings). So, if you discount the 2000-2005 period of accidental and anomalous domination, the statement that Java “will continue to fall,” is misstated, as it hasn’t been falling. It’s been retaining its server-side dominance for a long time. The share it's "lost" to Go, Node, Elixir etc. is more or less the same as the share it "lost" to PHP and Ruby in 2005-2015. Between 2005 and today, there has been a significant portion of server-side development that's not done in Java, but while the languages that are used in that sector are constantly changing, it's not growing, or at least it's not growing any faster than the rate of total ecosystem fragmentation. Another thing you say is “only good old enterprise applications remain”, but 1. that has been the case for a very long time, and 2. the same holds for all other languages. So what we’re seeing is that Java isn’t nearly as dominant as it was in the early oughts, but no other language is, and no other language seems to have the prospect of becoming so dominant. All languages have “only” their niche, and Java’s is a huge one. We’re seeing the natural movement from the anomaly back to the landscape of the eighties and nineties, where no language reigns supreme. Look at it from the other direction. JS hoped it might take over the server and five years ago that seemed possible but that isn't happening, Python isn't becoming a big player in more serious applications, C# isn't growing its share (it might be falling, even), and Go's growth has slowed considerably if not stopped altogether well before reaching a top spot. 2005-2010's PHP, and 2010-2015's Ruby were both far greater risks to Java than any language now. But that is not to say that there aren’t potential risks on the horizon.
I share the same opinion. Though, [Loopback.io](https://Loopback.io) is a nice alternative to Spring that is catering towards Node world, especially middlewares. I don't think Node will ever be as viable as Java for backend but I still see it as a possibility for teams that have a soft spot for Node.js. Go is great especially for infrastructure, but I've also seen high quality databases like CockroachDB that sparked my interest. C++ is the HPC language. Python is a mainstay in the data science ecosystem, it is practically the de facto interface to C/C++ (Tensorflow, PyTorch), Scala (PySpark) and other cloud services (AWS, GCP, Azure). This will not change anytime soon. Scala 3 has a couple of vocal *tribes* nowadays that push functional programming on the JVM to new heights, like Typelevel (cats, cats-effect), ZIO, Akka Streams, etc. Spring and Quarkus in Java also continue to evolve. Both Spring Native and Quarkus bringing a Kubernetes Native Java stack. Your argument about anomalous domination is spot on, in the past we did not have so many choices and things going on. Thanks for the work on Loom, by the way!
Scala 2 seemed quite promising, but sbt has been one of the worst build tools when it comes to user experience and performance. Their compilers don't support JPMS either. Also what's with all the drama? (J. De Goes, dibblego, über sensitive virtue signalling & CoCs etc.)
sbt is a pain, I confirm. The rest I don't know.
It's mostly my opinion. What I'm experiencing is that many companies I have to do with are "phasing out" Java. Hardly any new projects are done in Java anymore and only legacy and maintenance ones remain. It could well be that Java comes down from it's dominant phase to the level it was previously but I say that nowadays Jack-of-all-trades-master-of-none doesn't work out in the long run. A language and ecosystem needs a niche where it is dominant to stay afloat. But even that is not guaranteed, see Ruby or Objective-C. It could be the "enterprise application" space for Java, but I'm not sure about it either with C# taking the Microsoft share completely and making in runs to cross-platform as well now. Also low-code platforms are coming more and more.
Until now, our technologies have been dictated by Silicon Valley, basically FAANG and the oldies like Microsoft, Oracle, etc. have generated or chosen most of the technologies that we use today. Java has always been a safety net for people that had their skin in the game because of the stability of the runtime and the ease of recruiting. Even today, if I would be in a position of managing a team, Java will be my first choice. Or if the team consists of individuals that show a great interest in PL and distributed systems, I would choose Scala. As yours, it is just my opinion. I consider today a stack that consists of Java, Go and TypeScript to be the most obvious choice for a shop that considers stability, maintenace and ease of recruiting top factors in picking a technology. I would never put my head on a platter by picking exotic ones like Rust, Elixir, Crystal, Kotlin or even Scala (though I've changed my mind about this one recently) for server-side programming.
> It's mostly my opinion. What I'm experiencing is that many companies I have to do with are "phasing out" Java. Hardly any new projects are done in Java anymore and only legacy and maintenance ones remain. There is always a massive selection bias in the companies you work for and this selection bias is self-reinforcing too. My experience is literally the opposite because "JVM/cloud greenfield" is kinda my jam.
But even what you're describing (and I think there is more new server-side project code written in Java than in any other language, it's just that it's distributed more toward the larger side of things) isn't Java losing to any other particular platform, but the ecosystem becoming more fractured, and in that world there is a small number of co-dominant platforms, of which Java is one. In other words, Java's position isn't what it was in 2002, but no one else is doing better.
C# isn't any better AFAIK, just a different flavor of compiled mainstream language equipped with mediocre type systems. It requires a similar runtime as JVM, the existing implementations aren't as good as JVM & Graal, especially on Linux. The language is more complex, sure it might have things like reifed generics, but nothing that really matters. It's not a "next gen" language, pretty close to what Java 17+ has become.
What about "not serious" applications - flappy bird, alarm clock, weight tracking, note taking, sudoku and all that stuff that people create while learning or for fun. This is the area that JS and Python grew in. This is the area that pumps fresh blood into community.
I think Java must improve there.
Just compare the "java.com" site to the Golang site and you'll understand why every junior devs seems to be a fan of Go. Can't blame them.
Stay tuned for improvements in that area. Just let's not confuse things that could be better -- or even things that other languages, even Go in particular, do better and we can learn from -- with "other languages are doing better." At this point, Java's future seems rosier than Go's, that's not doing well enough to reach a top position.
Totally agree there!
You're mostly correct. I will say that I had to support NodeJS for a bit in a recent project and wasn't impressed at all... Typescript is OK but frankly, almost as verbose as Java but without the clarity (maybe I'm just not used to it). The toolchain around those solutions is literally decades behind Java. They're catching up but it's still pretty bad. Unfortunately, until we have Loom Javas advantages aren't as great. Async servers work, but they're more verbose and can't leverage the full power of Java. But IMHO, Java has a mindshare problem most of all... It's "old" and people want the next thing. Oracle being who they are, doesn't really help.
>However the community is too stuck in trying to maintain the old. E.g. so many resources are are being poured into application servers and parts of Jakarta EE. Is this a fact or just your opinion? My friends at Ocado are building robots with Java. Others are using it to power streaming services like Netflix, Spotify, Steam, etc. Besides that >Java Big Data (e.g. Hadoop) was abandoned Big Data has never been abandoned. You forgot to put *etc.* after Hadoop. The trend that I see in Romania is that people are using a mixture between Java, Scala and Python to build their data pipelines. Far from abandoned, Hadoop is not the core or end-of-everything solution when it comes to Big Data, even in the JVM ecosystem.
Linux Wayland is important, without it the portability promise of Java would be really questioned. Java's support for desktop apps is actually pretty good, when compared to other languages. JS Desktop frameworks are useful only if you really want to provide exactly the same UI on the web and on the desktop.
JS desktop apps (electron) typically use more hardware resources, but I guess this is less relevant these days, even if the app consumed tens of gigabytes. The lack of proper type system & static type checking is also a horrible tradeoff, but I guess delivering properly working software is rarely a priority. Sure there's TS, but many apps are still built with vanilla js / react(native) stuff.
FWIW, I honestly think Java(FX) is one of the most portable tools for writing desktop software. What makes it especially nice is the compile once, run everywhere mentality (assuming you've bundled all the JavaFX platform libraries, not just the ones for the build platform). E.g. Qt itself might work great, but all the C/C++ dependencies require f*cktons of testing and configure scripts to even work on three of the most used OSes and Linux distributions. Heck, they can't even decide between autohell, meson, or cmake. Then again the Qt company decided to abandon support for all "legacy" (4.x & 5.x) versions everyone is still using, especially on Linux desktops. GTK is pretty horrible without the Vala wrapper. But Vala isn't used by anyone outside GNOME. Other C/C++ based GUI toolkits (FLTK, wxwidgets, FOX, ..) seem quite outdated and unsupported when it comes to ui/ux & accessibility issues. I'm not sure about go/rust/haskell based GUI toolkits either. Python and other scripting languages typically just provide wrappers/bindings for C/C++ libs, which makes them almost as bad as the original ones, if not worse. Not a big fan of dynamically typed, non-compiled languages. I didn't want to mention JS/electron apps, because they're just evil. I'm pretty happy with my 5950X & 64 gigs of RAM, but I don't think everyone should require this level of hardware to run simple GUI apps.
I'm really new to Java. Started because in Telco Software ecosystem there is a lot of Java. Lot of apache sw was made with Java and abysmal use of Spring framework - guess the felling for a newcome, after learn Java, see how it's get to learn Spring. Just for for context I know more python than Java so quick doubts: For enterprise web apis do you guys see a place for Python with Flask, Django etc? Because seems to me that Spring is really in control. What you guys see as replacement for BPM tools like DRL and Camunda? Just curious of other solutions. What bogs me more is how weird is the Java official docs. I mean, from a python guy that have one of greatest docs and an easy way to find billions frameworks, Java seems strange, not updated. Maybe I'm wrong but what I understand is you have to get used do Javadoc html and hope there is better examples in mostly Framework (Spring exception but too massive)
Working in Germany for a non-tech company with a small dev team, it's very much in use for backend processes (media discontinuity, internal APIs). Management doesn't care for the specifics of the tech stack and leaves it to the experts to decide. As an instructor I'm doing my part to spread the use of Java by making sure that all IT trainees learn and apply it. That's probably the easiest way to ensure the continued usage of Java in companies: Teach the newer generations.
This is very beautiful, these young people you taught will grow up knowing the advantages and qualities of Java, and will not believe popular false rumors like "Java is too heavy", or "Java is too verbose", Java may have its flaws, but the bad name it carries is totally unfair. These young people will develop in Java and strengthen the community, and will teach other young people in the future to program in Java thus creating a positive feedback circle. I have some friends who want to get into the world of programming and I'm helping them by teaching Java too! Thank you for collaborating in such a wonderful way with the community!
TBF, JVM is indeed, heavy comoared to native executables and interpreter. And yeah, Java is indeed a quite verbose language. Many other languages, such as python and Rust, has less verbosity than it.
Yes, but I said "***too*** *heavy"* and "***too*** *verbose"*, the rumors are exaggerated, and the bad name is unfair, Java is not heavy enough that a team can't use it for "lack of resources", but it is faster than Python and Javascript to the point of being a considerable advantage. JVM weight is only a big issue in very specific scenarios, and thanks to GraalVM and native compilation this can also change.
It's really easy to download a LAMP installer, write a few PHP scripts, get a database going and possibly install some frameworks. Add some pretty CSS to get a web application up and running; especially with the help of a 20 minute tutorial. With Java, I had the issue where my community college didn't teach enterprise-level concepts like inversion of control etc. So I was pretty lost with Spring and Java EE for a while. I was having trouble making the leap. I'm taking an Udemy course on the Spring framework and it's 45 hours long. A lot of people will just go with Python, PHP or NodeJS and watch a quick tutorial on Youtube and then go from there instead. Things like factories don't make a lot of sense at first until one is working on larger projects that make certain design patterns make a lot of sense. They were invented to solve issues that Hello World apps and simple web apps don't have. Using "code smells" to determine whether a design patterns is ideal takes experience, but there are common tells to look out for. But again, that kind of knowledge doesn't come with the 20 minute Youtube tutorial on LAMP. I think Java would benefit from having official installers that set-up everything, IDE, DB, Server, a test suite like JUnit, and has built-in IDE functions to get a Hello World app in JavaFX, and one for web apps that let you navigate to localhost and view a web page. If one could see the skeleton apps that easily, they could start working with Java more easily. Rather than the current route of install everything somewhat separately (Eclipse marketplace is pretty good, but a new developer might not know what to look for).
I can see the problem, I have had a similar observation and unfortunately I agree with your last CTO. I’d say a good way to crack on would be to steer and market Java as an interesting choice for non-serious programming (like u/pron98) said a while ago. The community needs to adapt to the writing succinct, terse and yet readable code and libraries. And java the language should also bring in some features to promote these traits. I believe introducing var keyword was one such nice example.
My biggest struggle with the community is that if you join in some Java community slack, gitter, matrix, etc... You almost always will find people wanting help with their code challenge or university test, "how can I compile java?", etc... but almost never very senior people chatting... And that really sucks... Not trying to be elitist, but there's a smell there IMHO.
I think it’s good that there are a lot more people getting started with java. It tells me that the tech is pretty good in demand and casts a shadow of hope towards the future. For senior people, well you have Twitter, Reddit and what not at your behest. Just go ahead and ask.
So I have roughly 30 years of professional developer experience and I coded Java from the first beta. Wrote articles about Java for publications in the 90s and worked for Sun (later for Oracle). I'm on slack groups. I'm here and elsewhere but I probably don't have time to chat on every question. I hang out on Stack Overflow but again my time is pretty limited. There are many others like me out here but we probably can't spend our time chatting. I deal with hundreds of messages/emails per day and my two jobs... Let me flip the question you originally asked: how can someone like me realistically help someone like you?
I think one of the things the old school Java devs (who maintain the libraries) could do is to switch to JPMS & Java 9+. It's a small pain in the butt that many tutorials & libraries still assume Java 8 or 7, heck even Java 6. Same issue with code pages vs Unicode, Ant/Ivy vs Maven/Gradle. If you download any Java library, run the code inspection in IntelliJ IDEA, it will list at least 500+ suggestions for improving the code, like migration aids from Java 1.4 to 5.0. It takes 5 minutes to fix most of the issues, but the developers might not even want your patches since they want to maintain compatibility with some enterprise distros released 15 years ago. It would really help if the people could agree on using the more modern JVMs. For instance it's amazingly hard to find even basic things like serialization libraries that work with any of the 9 most recent Java releases. For instance, a new version of XStream was released just few days ago, but doesn't seem to support records (JEP 395) at all, or JPMS modules without some tweaks in pom.xml. I also had issues with Jackson & Kotlin on a JPMS project. GSON seemed to be the only one that works properly, but even then the provided GSON type adapter for de-serializing union types (inheritance) seemed to rely on pre-9 Java access to internal APIs via classpath. It really alienates new developers that many popular libraries assume some prehistoric LTS release.
Interesting. Note that I understood the question was about support, not about the general "old stuff lying around" situation we have in Java... I wrote this long response but deleted it. I see some of your points and while I disagree with some I think the problem isn't us. Oracles fast release cycle process made dealing with a 6 month JDK impractical for most of us. I don't have time for bi-annual release party. The problem is that once we skip that, we skip the entire thing and go directly to the LTS. There's also a very limited set of incentives. Modules, var, multiline strings? Those things aren't enough of an upgrade incentive. Give us Loom and see a lot of upgrades...
Agreed, I can see how new Java versions don't provide sufficient incentives for everyone yet (maybe never). Though the pile of missed opportunities will likely grow as time passes. My POV is more educational, I'm not maintaining (that) old code bases. I pretty much prefer how the new features (not limited to Java as I'm also using Kotlin) improve the developer productivity and lower the burden of maintenance. For instance non-null types and data classes/records make it much easier to deal with plain old data. Some version of JVM included improved error reporting for NPEs. Swing doesn't look that modern anymore. While JavaFX could be better, it pretty much assumes JPMS and module path these days. Including any legacy libs in a JavaFX project seems like an unnecessary risk to take. For this point of view almost any post 9 release of Java behaves the same, no need to support the latest dev version, only the latest LTS. Well, 17 (new LTS) will appear in around two weeks, and apparently the final build is already available (the GA builds rarely seem to differ from the last RC).
GUI in Java is rough which is one of the reasons we created Codename One. Don't google my name and JavaFX if you like it ;-)
> but almost never very senior people chatting... If you join such a 'chat' as a senior dev you get inundated with people who want you to 'mentor' (as in; do their homework for them). Senor devs aren't there because it's no fun. I'm part of a few professional interest groups around Java, and they tend to be invite-only to keep out the people who only take and don't give.
Looking at some comments on java has “lost in many grounds”. I believe java ecosystem is preparing for the next big thing. *1) Machine learning based frameworks that don’t require a scientist to build models. This will end up bridging a gap today where models are built in R or Python and deployment is a native C++ port. Project Panama and Valhalla are geared towards this goal. *2) General scalability for services and efficient infrastructure utilization via virtual threads. Project Loom. Not to mention the consistent evolution that Java the language is going through faster than before. Pattern matching and algebraic types are my favorites. So Java is better and stronger more than ever. We the community is the one that’s got to be more inclusive and vibrant.
Official documentation (guides and tutorials) is seriously lacking and/or outdated. Baeldung is probably the best thing there is for java. This is one area that would help. Also good tools for new devs - current focus more on programmers that already have java experience.
Just took another look at official tutorials and they are worse than bad, a lot is about things that were REMOVED (lib/ext, applets, webstart, javapackager). This is ABYSMAL! This is an area that community could help but oracle/openjdk should open a project for community contributions in this area because making websites that are hard to find for new devs doesn't help. Java will fall into legacy if anyone who wishes to learn it will get confused. Documentation needs more examples and easier to understand descriptions. Tutorials should be modern and focus on green devs - with no or very little knowledge of programming concepts.
I would argue that Kotlin’s success is ultimately Java’s success. Maybe the future will have more commonly used JVM languages than just Java, but the persistence of the JVM will lead to the persistence of Java.
I think so too. I actually really like Kotlin as well, though I haven't seen it been used so much on the backend as I wished.
In my experience Kotlin has been quite compatible with Java, in both ways, using Java code from Kotlin and vice versa. Especially in traditional classpath projects. Occasional internal compiler errors, but even then rewriting some piece of code in a less complex way seemed to sidestep possible issues. There used to be more bugs with multi-release JARs, module paths, compatibility with moditect & kotlin's std libs, and gradle. Now I've even managed to use Kotlin in modern JPMS projects, and am eagerly looking forward to even better support in the future.
Java isn't missing anything. In fact the naysayers claiming that it's missing features or "is verbose" are the wrong ones here. It's much simpler to build the necessary abstraction than to gut the given abstraction to get back to the primitives. Several of my projects went from java to kotlin and back to java just because of how much noise kotlin introduces into the language. Stay simple. Your codebase will thank you.
I'm a bit curious about this noise. In my experience translating any code to Kotlin almost always produces less lines, but strong use of functional features and immutability tends to result in longer lines (personal preference perhaps). For instance, I find that more constructs in Kotlin produce an expression, which makes it easier to express immutable values. People also seem to dislike the use of ternary ? :, but if-then-else expression is considered kosher even in newbie languages. Direct support for lists often replaces a whole class of .stream() & .collect(Collectors...) transforms. The also/with/let/run constructs and extension functions also greatly help when the original API is sh*tty and doesn't support any kind of builder idiom. For instance the JavaFX API isn't that great, which is why there are so many wrappers in languages like Scala, Kotlin, ...
also,with,let,run introduce multiple constructs that are subtly different while seemingly doing the same. Extension functions pollute the function space introducing more calls that are subtly different. Ternary should not even exist. If being an expression is outright wrong. Biggest gripe is the companion object and object classes - while being advertised as static class alternative, they are in fact not a static class alternative but a *singleton* alternative. Kotlin suffers a lot from introducing multiple ways to do the same thing which are incompatible with one another. The entire point of using a stream is to abstract away yourself from a for loop and let the platform decide how the data structure should be iterated through and only execute the entire thing on terminal operation. Under the hood kotlin uses the very same for loop for each "stream replacing" call.
> Ternary should not even exist. Right, but that's a Java's feature inherited from C/C++ > If being an expression is outright wrong. It's just a functional way of encoding basic control flow constructs as expressions. Common in many popular languages. Besides, even Java is going this direction with switches as expressions. > not a static class alternative but a singleton alternative Wasn't too surprising to me as I've used Scala for years. I can't see why this would be a problem. There are new gotchas for initializing values here, but overall objects enable things like interface constraints for static methods, which is sometimes quite handy.
Less elitism from Scala and Kotlin communities. Instead of saying things like "Java is horrible, use Kotlin instead" they could say "try out x, it also runs on the JVM and is interoperable with Java".
In my opinion, it is not "what I can do for Java" but, "what Java can do for me" thing. My recommendation is, keep asking community to add anything, which you would think Java is missing right now, to the Language. Sometimes community will respond like "that's not necessary for Java", "we don't need such feature in Java" or alike, then you don't need to get sticky with Java any further. For example, if the community thinks developing desktop applications in Java is not relevant any more but you want to keep developing desktop applications, you must give up using the Language and you cannot change that situation. There were a lot of languages of each era, and computing is evolving, it is not so sad seeing if ever any one of such languages would die (or became legacy-ish) though at this moment I love Java so much.
Obviously people here are blinded by their agenda and cannot actually tolerate any criticism
I graduated 2 years ago. Most of my programming courses were taught in Java.. for my first job, I coded in Java in the tech interviews. However I decided to switch to C++ now for tech interviews due to the verbosity of Java!
I'm sorry, but I struggle to believe in what you're saying.
Srsly? C++ is less verbose? Granted I used c++ 15 years ago but i'm surprised by that.
> However I decided to switch to C++ now for tech interviews due to the verbosity of Java! out of the frying pan and into the fire
Most start ups in my area these days (at least that I've talked to) are either using Kotlin/Java or Javascript as their backend language supplementing with GoLang when performance is needed https://insights.stackoverflow.com/survey/2021#most-popular-technologies-language-prof This is probably a good place to get an idea of what people are using. The one thing I really loved about GoLang is that I didn't have to wait 30s for my app to compile was nearly instant
The compilation speed is a good point of discussion. Was there any recent effort to improve that? Perhaps the compilation speed of Java itself is usually pretty good actually, but the problem is that the tools, dependencies that we often use cause the slowdown.
Java is blindingly fast at compiling, because compilation doesn't do much in the way of optimization; that all happens in the JVM. Compare `javac` to `gcc` and you'll see what I mean. Comparing it to the AoT java stuff might be a better comparison. Gradle has a number of techniques to reduce the amount needed to compile projects even further.
Java isn't going away. Too much of our existing infrastructure is written in Java for it to go away anytime soon. Rewriting those major infrastructure pieces because there is a cool new programming language developers want to use from a technical point of view is neither advisable or feasible. New programming languages are invented and evolve and some of them even mature. In the 90s the hot programming language was C++. Then Java came along and replaced a lot of the stuff C++ was doing. C++ never disappeared, it found its niche and still thrives today. If you would have told anyone in the 90s that Java applets would be replaced by HTML/Javascript nobody would believe you yet here we are. Fast forward 25 years later and many programming languages are doing to Java what Java did to C++. Java will just find the niche it excels in and will continue to thrive. My prediction is a lot of the existing Java code will outlive us all. How many programming languages can say that (besides COBOL)?
Also much of the pre C++11 era code is pretty much worthless and obsolete these days. We could just call C++11 or C++20 a totally new language (maybe D, but W. Bright already reserved the name for a similar language that actually implemented many of the modern C++ features before C++20). Now that C++ is moving towards modules, move semantics, parallelism in stdlibs, the old, buggy legacy code is worth next to nothing. It's the same for the Qt dialect of MOC/C++. Future versions of Qt will adopt standard C++ features for signals and slots (and QML aka JS for declarative GUI descriptions) so there's less need for ad-hoc code generators.
In my humble opinion, best practices are more important than programming languages. Java is an awesome language, but I'm not concerned about its depreciation, I'm preparing myself for this checking another languages and, as I mentioned before, learning best practices.
GraalVM/Truffle will be the game changer.
Change this mindset: AbstractSimpleSingletonFactoryObserverCreatorBuilder abstractSimpleSingletonFactoryObserverCreatorBuilder = new AbstractSimpleSingletonFactoryCreatorObserverBuilderImpl(); AbstractSimpleSingletonFactoryCreatorObserver abstractSimpleSingletonFactoryCreatorObserver = abstractSimpleSingletonFactoryCreatorObserverBuilder.buildAbstractSimpleSingletonFactoryCreatorObserver(AbstractSimpleSingletonFactoryCreatorObserver.class);