16 ms·

The Java ecosystem has been slowly dying for years, it's already the new Cobol at this stage. I have the impression that a lot of the mindshare has switched to

by vfc1 7y ago

The Java ecosystem has been slowly dying for years, it's already the new Cobol at this stage. I have the impression that a lot of the mindshare has switched to the Node and Javascript ecosystem, especially the frontend devs, via the Typescript / Angular path, which is a natural path to Java developers due to the comfort given by familiar concepts like static types, classes, etc. When I used to do Java, I always found that Spring was a much better framework than Java EE, and have used it in most projects I've worked. Oracle did not take a note from the Microsoft book and is really behaving that an evil corporate overlord. It's clear at this stage that they bought Sun in order to slowly turn Java proprietary, and charge billions to the companies that are now fully Java-based for the next few decades. I'm glad I saw the writing on the wall and switched, but the problem is that Java is still being taught a lot at schools, and school programs especially universities are hard to adapt and only change every 4-5 years or so.

walkingolof 7y ago
Working in the JVM world I'm always surprised to hear that its dying, the JVM and Java moves faster forward than ever, Graal is about to go 1.0, a bunch of very interesting (very) low latency GCs are in the pipe (for example ZGC and Shenandoah) and lots of other interesting projects like Valhalla promise to keep the JVM relevant for the next 20 years. Oracle have made some moves to monetize on parts of its investment, but the situation is largely misrepresented. Ref: - https://openjdk.java.net/projects/valhalla/ https://openjdk.java.net/projects/valhalla/ - https://www.graalvm.org https://www.graalvm.org - https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main - https://wiki.openjdk.java.net/display/shenandoah/Main https://wiki.openjdk.java.net/display/shenandoah/Main
- acqq 7y ago
  > Working in the JVM world I'm always surprised to hear that its dying So how is this "JVM world" escaping the grip of Oracle? E.g. graalvm is directly Oracle's, or am I missing something? Specifically, what is preventing any of the Java-related things people use now (including those that you mention) to end like the OP is describing? Asking as somebody outside of that world, but interested "how much it's worth considering" under the given circumstances (Oracle being Oracle, demanding a lot of money for everything Oracle's that some company could use, and owning a lot of that "world"). Where are the boundaries? What is safe and outside of reach of Oracle? E.g. what is safe for a small company to use?
  - walkingolof 7y ago
    Graal Community Edition is licensed under GPL, there is a Enterprise Edition that has additional features that is licensed differently. OpenJDK does not need commercial licensing, but Oracle JDK which is built from OpenJDK needs. Then there are plenty of other vendors to chose from if you absolutely does not want to interact with Oracle. IBM and now Eclipse foundation OpenJ9 is a very interesting TCK compliant JVM, then you have Azul Systems that innovates a lot with Zulu/Zing.
    - acqq 7y ago
      GPL is not usable for any small company which doesn't want to publish its own sources. What can be used only using BSD, MIT, Apache licenses? And what from the GPL-licensed products is safe to use to produce and sell own closed source products (e.g. where the exception to GPL exists for just linking the libraries or similar)? Edit1: Long term dangers/costs of depending on the technologies that need commercial licenses like Oracle’s are also important. Edit2: And additionally, just as an old example, once I’ve considered using Berkeley DB in the closed source product (before some of the current alternatives were available), and my interaction with Oracle proved that only a bigger corporation could fund that. For a library which was already open source, but owned by Oracle. It's not that I'm in the "I don't want to pay for anything" camp -- I'm simply having a perspective of a small player. And about small players Oracle couldn't care less. However, the significant changes very often come at that level of cheapness and overhead, most of technologies would be still not widely accepted otherwise.
      - walkingolof 7y ago
        You probably use Linux today, that fact does not require you to publish the source for your program running on Linux.
      - mateuszf 7y ago
        > GPL is not usable for any small company which doesn't want to publish its own sources. Maybe I'm missing something, but AFAIU you have to publish any changes to that library, not your sources.
- bborud 7y ago
  Reality is subjective and local. At any given time most developers will neither have much real choice when it comes to technology nor have a longer term perspective. Hence most developers will stick to what they know and what organizational inertia seems the path of least resistance. The comparison to COBOL is good for several reasons.
  - heelix 7y ago
    My first bit of production Java code was an applet that used cobra to talk with COBOL in the Java 1.0 days. When I'm bridging new languages to Java codebases, I always wonder if this is the 'new hotness' I'll be driving next.
    - ngcc_hk 7y ago
      Similar position. Corba overhead too high and we use a middleware to handle it. But the aim is to migrate away those we can from mainframe. And use java in lieu of cobol.
    - sorokod 7y ago
      CORBA?
- dtech 7y ago
  Too little too late, and I highly doubt that (5-year-old) Valhalla will deliver even one of the promised features (value types) in the next 3 years. Remember that the original plan was to have all Valhalla features in Java 10. Java/JVM was in the ideal position to dominate the software world for the whole 21th century 15 years ago. Instead they did an IE6 and stagnated for so long that their competitors became plain better. I'd say Java/JVM is now where IE was in 2008. Still massive majority market share, but in decline because people are switching to competitors. LLVM and webassembly are eating JVM's cake, and a multitude of languages like Kotlin, C#, Go, Rust and even Javascript and Python are chipping away at Java's market share.
  - walkingolof 7y ago
    Kotlin is a JVM language, sold as a better Java, and the JVM is really the thing that is the echo system gathers around, not necessarily the language Java. Other interesting languages you have on the JVM is Scala (multi-paradigm), Clojure (Lisp), EtaLang (Haskell) - https://eta-lang.org https://eta-lang.org - https://www.scala-lang.org https://www.scala-lang.org - https://kotlinlang.org https://kotlinlang.org - https://clojure.org https://clojure.org
    - dtech 7y ago
      Notice how I separately addressed JVM and Java. Java is already losing market share to JVM competitor languages. JVM is in a stronger position than Java, but imagine a world were 15-10 years ago native compilation for JVM bytecode became available instead of 1 year ago. LLVM wouldn't have stood a chance. Kotlin and Scala (I'm not too familiar with Clojure and others) are hedging their bets and making JS/Webassembly and LLVM versions.
      - pjmlp 7y ago
        JVM native compilation exists since 2000 for anyone willing to pay for it.
        aphexairlines 7y ago
- djvu9 7y ago
  Java the language is slightly different than JVM but nevertheless the future is not very bright IMO. So far there are a few areas Java/JVM still holds a strong position but if you take a look at GitHub trending there is little or now new blood coming in. - Android. No serious competitor to Java yet (JVM is irrelevant). But the Google lawsuit could have some complication. - Spring stuff. I won't be surprised if they will be replaced by golang and nodejs (along with react/angular/vue etc). Same path for RoR. - Data processing: Spark stuff, PrestoDB, Flink, Kafka, Hive, HBase, Lucene/Elastic etc. Java/JVM is still dominant but golang could be a future contender. A few new application databases/KV stores are implemented in golang. The problem for Java is that the last category is mostly services (instead of libraries/frameworks) so you can potentially use any language to work with them, and the industry probably won't create many jobs for building generic services especially in the cloud era. So having the dominance doesn't provide a lot of protection.
  - bubblewrap 7y ago
    I've hated Java for years, but recently I think it has become usable again. I've looked at GoLang and Node, but I've kind of given up on them, too. GoLang I would consider for specific use cases. NodeJS just seems to insecure and "wild". Was hoping that Kotlin+Spring could be a good alternative to GoLang for realtime apps, but haven't tried it yet.
  - stickfigure 7y ago
    Golang, at least in its current incarnation, has no chance of replacing Java in its core use case - business processing. Golang is replacing infrastructure that used to be written in C, which makes sense considering that's what it was designed for. It's weird that you put Spring and react/angular/vue in the same sentence, because there is no overlap in these problem domains.
    - djvu9 7y ago
      Just take a look around to check out new enterprise MIS projects being implemented with a simple golang backend + reactjs etc frontend. The adoption of intereactive/responsive and single page web UI, and the more iterative development practices are certainly driving to a different direction compared to Spring (and RoR etc). I think the main force is from the frontend tech here and that is why you see them in the same sentence.
lars_francke 7y ago
Please remember that such viewpoints tend to be very subjective and depend a lot on your environment. Where I am (geographically, company wise and ecosystem) Java and the Java ecosystem are very much thriving.
- tyingq 7y ago
  I wouldn't say that for Java EE.
  - lars_francke 7y ago
    That's true for me as well. There are a few select components from EE that I see but other than that it's of no relevance for me either.
ivan_gammel 7y ago
Java is not even close to be pronounced dead and it’s still the best ecosystem and platform on the market.
realusername 7y ago
I would not go as far to say it's dying but it's heavily slowing down for sure. First because of the big move out of the "entreprise" software and secondly because of Oracle legal team. It's definitely due to the licensing that Android is switching to Kotlin for example.
- pjmlp 7y ago
  Except that Kotlin still lags behind Java compiler speed and it is heavily dependent on Java libraries.
  - erik_seaberg 7y ago
    Compiler speed is a fantastic tradeoff. I'm made of meat that runs at maybe 0.0001 MHz after coffee, so I want to offload anything I can to the compiler!
    - dunefox 7y ago
      That's a very sensible standpoint.
    - pjmlp 7y ago
      I rather bet in platform languages, without extra layers to debug, FFI and additional tooling not available to all IDEs for the respective platform.
  - realusername 7y ago
    All of these are technical issues which will be solved by Google eventually, I'm not worrying much about that, they definitely have the resources to make it work.
    - pjmlp 7y ago
      I bet that in 5 years Kotlin will have as much market as other alternative JVMs languages have today. And regarding Google, Kotlin is not among the beloved ChromeOS and Fuchsia languages. So it depends very much on their internal politics.
smoyer 7y ago
Spring is compliant with and reliant on many of the JavaEE specifications - JDBC, Servlet, JAX-RS, etc. It provides DI that is not JavaEEs CDI. I'd consider Spring as more of a non-JavaEE application server. Pick either Spring or Wildfly/Glassfish/Websphere/etc and you're either using part of the JavaEE specification with the former or the full specification with the latter. Avoiding JavaEE for micro-services requires moving to something like DropWizard. Instead of a 200MB application server you end up with a 20MB application. Unfortunately, running that application in a Docker container will spin up a 180MB JVM. So the main reason we're moving away from JavaEE is actually more related to our move to container orchestration and that was originally driven by our adoption of micro-services. If you write a micro-service with a single end-point why should it use 500MB of memory?
roca 7y ago
Nothing wrong with being the new COBOL. We need a new COBOL is Java is pretty good for that. At least it would be if Oracle wasn't trying to squeeze it dry.
wbl 7y ago
Good luck doing that when OpenJDK exists.
jillesvangurp 7y ago
I've spend quite a bit of time doing javascript and typescript lately. Typescript definitely patches up a lot of the ugliness of javascript but you still deal with the same messy ecosystem of tools, libraries, and other cruft. It's been slowly getting better over the years but it's still not that great. I see typescript more as a gateway drug for people who seem to think that Javascript is all there is and then discover that actually having a type system unlocks all these amazing new tools that the rest of our industry has been enjoying for a few decades. Guess what, if you like typescript, you'll love Kotlin. It's a much cleaner language, just as expressive, and it has a whole range of things that typescript simply can't do or that it simply does better/more elegantly because typescript is stuck preserving compatibility with javascript and all it's weirdness. MS has done a wonderful job of shoving a lot of that under the carpet with typescript but fundamentally types are optional because all javascript has to be valid typescript and therefore it has to also allow all the silly hacks, misguided features, and other cruft that javascript people have been coming up with for the past decades. You might also like C#, Rust, Elixir, and several other languages that each offer their own tools, libraries, and features. I'm seeing a pattern with many frontend developers in the last few years that they at some point become full stack developers and shortly after start adding more languages to their repertoire. I know former node.js developers doing Rust, Go, Elixir, Kotlin, Rust, etc. now. Most of them are not very eager to move back to doing node.js projects. Like Kotlin all these languages are all coming to the node.js/browser ecosystem through WASM. Full stack in 2020 is going to be a very different beast than just a few years ago. Right now WASM already allows lots of languages to be used for just about anything that people currently do with javascript and typescript in browsers or in the node.js ecosystem. As this becomes more mature, people are inevitably going to change the ecosystem. This is already happening. E.g. Rust is being used for many low level npms for a few years now. However people have also been developing frameworks and libraries in Rust that work around/replace that ecosystem entirely. For a Rust person dealing with crates is preferable to dealing with npms, webpack and all the other stuff that is used in that ecosystem. So, they are fixing that. The goal there is to run pure rust in wasm in the browser or on v8 with 0 npms pulled in or used during the build process. Likewise, there's an ecoysystem of multi platform kotlin libraries emerging and that allows you to build wasm or native applications and libraries without needing things like webpack, npm, etc (but using gradle instead). Same with C# and blazor. Each of those ecosystems uses browsers and node.js as runtimes but try to minimize/eliminate/replace most of the rest of that ecosystem. In the same way the Kotlin ecosystem is also starting to provide alternatives to stuff from the java EE and Spring ecosystem. E.g. Ktor is a multi platform web application framework that you can use instead of spring boot and run natively or on the jvm. It's also a drop in replacement for anything you might want to do with e.g. express.js. Doing express.js applications in Kotlin is of course also possible, but why would you when you can have ktor instead? In the same way building react applications in Rust is possible, but replacing it with a rust specific framework is much less awkward. So, I agree things are changing but I'd say the node.js/browser landsace is changing as well and will not involve a whole lot of javascript/typescript for people coming from the JVM or other ecosystems. You might make the point that there are all these millions of npms out there that can't be replaced easily. I'd counter that with the point that an awful lot of them seem to have very short shelf lives and are in fact replaced/discarded regularly.
coldtea 7y ago
>The Java ecosystem has been slowly dying for years, it's already the new Cobol at this stage. Not in any industry I know.
hodgesrm 7y ago
Time for another sortie by the COBOL evangelism task force. Java has been the new COBOL since its inception in the 1990s. I programmed quite a bit in COBOL early in my career. It's an extremely efficient language for scanning records especially in an era when a large proportion of data was stored offline on mag tape. Most common business problems of the era could be expressed and solved effectively in COBOL, which is why it became so popular. I programmed in both C++ and Smalltalk in the early 1990s, which were innovative but also difficult to use for large systems. Java hit a happy medium with its C++-like object syntax, built-in libraries, and virtual machine operation with garbage collection. Add in the network effects from wide adoption (leading to tools and libraries) and it became a huge hit. Oracle seems to be going out of its way to submerge the language in confusion. But nobody should mistake this as a reflection on the inherent capabilities of Java or its fitness for use. Edit: correct typo
- DaiPlusPlus 7y ago
  How does one secure a COBOL gig today, and is the supply:demand ratio such to guarantee excellent compensation and working conditions?
  - DonHopkins 7y ago
    Be patient, and talk to your local Alcor representative. https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39 https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39
- int_19h 7y ago
  I think you're missing the point of the COBOL comparison. It is not meant to imply that Java is similar to COBOL as languages go, or that it is as bad as COBOL, or even that COBOL is bad. In fact, you described exactly why it is the new COBOL: because it is also an efficient and popular language for common business problems of our era, that is hugely popular, but mostly in "unexciting" places like large internal enterprise apps, out of sight for many. And just like COBOL, it will keep ticking on like that, probably forever.
tootie 7y ago
JavaScript is practically stone age compared to Java. Debugging is a nightmare. Documentation is a nightmare. Scaling is a nightmare. NPM is a thousand monkeys at a thousand typewriters. Java suffers from having some 20-year old codebases because it's been so popular for so long but I can open up a 2004 WebLogic project in Eclipse or InteeliJ and trace everything it's doing. And modern Java has added all the nice features we expect a modern language to have. Java's slow demise is due to terrible PR and Oracle's endless insistence on JEE when every sane developer is using Spring.
- udkl 7y ago
  This. Sure JavaScript is moving fast .... but it's moving haphazardly.
- exabrial 7y ago
  CDI may be the golden egg though. I enjoy using it as an alternative to Spring, it's just unfortunate it comes with the deadweight of legacy ee.
- iSnow 7y ago
  I am not very sensitive to all those issues, I find the JS/CSS/HTML web stack a bit antiquated (virtual DOM, LOL), but very usable. But the build toolstack is a pure, unadulterated nightmare. I used to think Maven's XML orgies, archetypes and learning curve were bad, but diving into Webpack et al was a new dimension of horror. This time based on JSON, though.
pron 7y ago
> The Java ecosystem has been slowly dying for years, it's already the new Cobol at this stage. This has been said for at least the last ten years. Not only is Java not dying, but companies like Apple and Facebook (not to mention Netflix, Amazon and Google, that are mostly or largely Java already) are increasing their investment in the platform. This was not the case when COBOL was 25. The reason this is so is that Java is by far the most technologically advanced server-side platform in existence. It continuously presents technological breakthroughs in GC, compilation, and low-overhead profiling technology (just in the past few years it did so again in all three -- with ZGC, Graal and JFR). Node, Python, Go, Erlang -- none of them even come close. .NET comes closest, but even it is pretty far behind. This certainly wasn't the case when COBOL was 25. It is true that for a short period of time, somewhere between 2002 and 2005, Java was more dominant than it is today, but that was a fluke. More "scripty" runtimes and languages were usually more successful in the "smallish software" domain. In 1995-2002 that was VB (and others); now it's Python. Also, there has been some decline in all languages due to the ubiquity of JavaScript on the browser, but Java did not suffer more than others. Maybe less so. > Oracle did not take a note from the Microsoft book and is really behaving that an evil corporate overlord. Oracle has just open sourced the entire JDK. Sun didn't do that and even .NET isn't entirely open source. I have no knowledge or involvement with EE, but it seems Oracle simply doesn't have faith in EE, and doesn't want the Java trademark associated with it. (I work at Oracle on the JDK -- i.e. OpenJDK -- but speak only for myself)
- dijit 7y ago
  I think you’ve drunk the kool-aid a little. Outside of complex projects headed by PhD compsci students (who used to learn java in uni but those courses are now taught in python) there isn’t a whole lot of mindshare going towards java these days. At least in regards to new FOSS projects. I can say that my company’s use of java is diminishing rapidly over the last 5 years too. No matter what you think of the technological advancement of the language and ecosystem- it matters not if people are not using it. Oracle itself is a pariah, the vast majority of the tech industry avoid it.
  - pron 7y ago
edwinyzh 7y ago
As a Delphi developer this is the first time I heard about Java is dying, and in a reply the other one said that some is saying so for over a decade :D And I think Java is more alive then Delphi, at least no one is setting up a site like http://www.isdelphidead.com/ http://www.isdelphidead.com/ :D
nullwasamistake 7y ago
Java is much closer to C++ than COBOL. COBOL has been massively obsolete for decades. Java has a lot of historical cruft but the basic syntax is still somewhat modern, mostly based off of C++ and agruable better. Like C++, it's modern features are being slowly added. There's a huge difference between Java 8 and 11, in performance and features. Innovation is hardly dead. Java EE and Spring are both terrible. I recommend trying some of the newer frameworks out there to see how much nicer things have become. DropWizard is my favorite right now. I'm no Oracle fan, but Java is more "open" in many ways than it has been since the beginning. It wasn't till a few years ago we had a feature-complete high performance OSS implementation as the standard. Oracle will try to ruin it, but the GPL JDK and history of projects being forked away from them makes it fairly safe. It's not in the interest of any Java user to have more than one standard. IMO Java isn't going anywhere. It's been top 3 most popular language for over a decade. JS is somewhat promising but will never match Java in performance and multi-threading support due to core design decisions. Go is too verbose to get industry buyin to replace Java in most use cases. WASM is promising in the far future but it will take years to have a full browser and server ABI. The only real contenter to replace Java is C# and so far it's not getting much traction. If anything killed Java it would be C#. Value types, no type Erasure, unsafe code and some native vector support. But it hasn't and probably won't ever dethrone Java. Java has a combination of decent features and an insanely huge amount of library support that makes it the default language of many companies.
- floriol 7y ago
  Why do you think Java EE is terrible?
oselhn 7y ago
Recently started working on Typescript project and it looks to me like java with really poor tooling, C++ like compilation times and huge mess in libraries (i.e. how to determine which version of @types package I need). I think that Typescript is really step back from java.
ksec 7y ago
How can a languages and its ecosystem that is being used actively in many projects within ALL Fortune Global 500 company and most Fortune Global 2000 be dying? When people say Ruby is dying, it would be more accurate to say they are not growing or they are shrinking. But given the size of Ruby marketshare of less than say ~2%. I would not really disagree with their notion. But Java? I mean even from a Web Development prospective, given you mention Node, JS and Spring Framework, it is Far from dead. And this is speaking as someone who likes Ruby and dislike Java.
xorcist 7y ago
On the contrary! They are likely very aware of Microsoft's strategy and probably regard it as being too soft. They intend to milk their technology to the last drop. You and I may regard it as evil, but it's a perfectly valid strategy. Perhaps it's more common outside IT? It's the brutally honest business strategy. I can sort of appreciate that they don't play around. Perhaps not my first choice of technology, but you certainly know where you have them.
fmakunbound 7y ago
> Spring was a much better framework than Java EE You can't compare these frameworks. They're in entirely different spaces, with different requirements and constraints.

by vfc1 7y ago

walkingolof 7y ago

Working in the JVM world I'm always surprised to hear that its dying, the JVM and Java moves faster forward than ever, Graal is about to go 1.0, a bunch of very interesting (very) low latency GCs are in the pipe (for example ZGC and Shenandoah) and lots of other interesting projects like Valhalla promise to keep the JVM relevant for the next 20 years. Oracle have made some moves to monetize on parts of its investment, but the situation is largely misrepresented. Ref: - https://openjdk.java.net/projects/valhalla/ https://openjdk.java.net/projects/valhalla/ - https://www.graalvm.org https://www.graalvm.org - https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main - https://wiki.openjdk.java.net/display/shenandoah/Main https://wiki.openjdk.java.net/display/shenandoah/Main

acqq 7y ago
> Working in the JVM world I'm always surprised to hear that its dying So how is this "JVM world" escaping the grip of Oracle? E.g. graalvm is directly Oracle's, or am I missing something? Specifically, what is preventing any of the Java-related things people use now (including those that you mention) to end like the OP is describing? Asking as somebody outside of that world, but interested "how much it's worth considering" under the given circumstances (Oracle being Oracle, demanding a lot of money for everything Oracle's that some company could use, and owning a lot of that "world"). Where are the boundaries? What is safe and outside of reach of Oracle? E.g. what is safe for a small company to use?
- walkingolof 7y ago
  Graal Community Edition is licensed under GPL, there is a Enterprise Edition that has additional features that is licensed differently. OpenJDK does not need commercial licensing, but Oracle JDK which is built from OpenJDK needs. Then there are plenty of other vendors to chose from if you absolutely does not want to interact with Oracle. IBM and now Eclipse foundation OpenJ9 is a very interesting TCK compliant JVM, then you have Azul Systems that innovates a lot with Zulu/Zing.
  - acqq 7y ago
    GPL is not usable for any small company which doesn't want to publish its own sources. What can be used only using BSD, MIT, Apache licenses? And what from the GPL-licensed products is safe to use to produce and sell own closed source products (e.g. where the exception to GPL exists for just linking the libraries or similar)? Edit1: Long term dangers/costs of depending on the technologies that need commercial licenses like Oracle’s are also important. Edit2: And additionally, just as an old example, once I’ve considered using Berkeley DB in the closed source product (before some of the current alternatives were available), and my interaction with Oracle proved that only a bigger corporation could fund that. For a library which was already open source, but owned by Oracle. It's not that I'm in the "I don't want to pay for anything" camp -- I'm simply having a perspective of a small player. And about small players Oracle couldn't care less. However, the significant changes very often come at that level of cheapness and overhead, most of technologies would be still not widely accepted otherwise.
    - walkingolof 7y ago
      You probably use Linux today, that fact does not require you to publish the source for your program running on Linux.
    - mateuszf 7y ago
      > GPL is not usable for any small company which doesn't want to publish its own sources. Maybe I'm missing something, but AFAIU you have to publish any changes to that library, not your sources.
bborud 7y ago
Reality is subjective and local. At any given time most developers will neither have much real choice when it comes to technology nor have a longer term perspective. Hence most developers will stick to what they know and what organizational inertia seems the path of least resistance. The comparison to COBOL is good for several reasons.
- heelix 7y ago
  My first bit of production Java code was an applet that used cobra to talk with COBOL in the Java 1.0 days. When I'm bridging new languages to Java codebases, I always wonder if this is the 'new hotness' I'll be driving next.
  - ngcc_hk 7y ago
    Similar position. Corba overhead too high and we use a middleware to handle it. But the aim is to migrate away those we can from mainframe. And use java in lieu of cobol.
  - sorokod 7y ago
    CORBA?
dtech 7y ago
Too little too late, and I highly doubt that (5-year-old) Valhalla will deliver even one of the promised features (value types) in the next 3 years. Remember that the original plan was to have all Valhalla features in Java 10. Java/JVM was in the ideal position to dominate the software world for the whole 21th century 15 years ago. Instead they did an IE6 and stagnated for so long that their competitors became plain better. I'd say Java/JVM is now where IE was in 2008. Still massive majority market share, but in decline because people are switching to competitors. LLVM and webassembly are eating JVM's cake, and a multitude of languages like Kotlin, C#, Go, Rust and even Javascript and Python are chipping away at Java's market share.
- walkingolof 7y ago
  Kotlin is a JVM language, sold as a better Java, and the JVM is really the thing that is the echo system gathers around, not necessarily the language Java. Other interesting languages you have on the JVM is Scala (multi-paradigm), Clojure (Lisp), EtaLang (Haskell) - https://eta-lang.org https://eta-lang.org - https://www.scala-lang.org https://www.scala-lang.org - https://kotlinlang.org https://kotlinlang.org - https://clojure.org https://clojure.org
  - dtech 7y ago
    Notice how I separately addressed JVM and Java. Java is already losing market share to JVM competitor languages. JVM is in a stronger position than Java, but imagine a world were 15-10 years ago native compilation for JVM bytecode became available instead of 1 year ago. LLVM wouldn't have stood a chance. Kotlin and Scala (I'm not too familiar with Clojure and others) are hedging their bets and making JS/Webassembly and LLVM versions.
    - pjmlp 7y ago
      JVM native compilation exists since 2000 for anyone willing to pay for it.
      - aphexairlines 7y ago
djvu9 7y ago
Java the language is slightly different than JVM but nevertheless the future is not very bright IMO. So far there are a few areas Java/JVM still holds a strong position but if you take a look at GitHub trending there is little or now new blood coming in. - Android. No serious competitor to Java yet (JVM is irrelevant). But the Google lawsuit could have some complication. - Spring stuff. I won't be surprised if they will be replaced by golang and nodejs (along with react/angular/vue etc). Same path for RoR. - Data processing: Spark stuff, PrestoDB, Flink, Kafka, Hive, HBase, Lucene/Elastic etc. Java/JVM is still dominant but golang could be a future contender. A few new application databases/KV stores are implemented in golang. The problem for Java is that the last category is mostly services (instead of libraries/frameworks) so you can potentially use any language to work with them, and the industry probably won't create many jobs for building generic services especially in the cloud era. So having the dominance doesn't provide a lot of protection.
- bubblewrap 7y ago
  I've hated Java for years, but recently I think it has become usable again. I've looked at GoLang and Node, but I've kind of given up on them, too. GoLang I would consider for specific use cases. NodeJS just seems to insecure and "wild". Was hoping that Kotlin+Spring could be a good alternative to GoLang for realtime apps, but haven't tried it yet.
- stickfigure 7y ago
  Golang, at least in its current incarnation, has no chance of replacing Java in its core use case - business processing. Golang is replacing infrastructure that used to be written in C, which makes sense considering that's what it was designed for. It's weird that you put Spring and react/angular/vue in the same sentence, because there is no overlap in these problem domains.
  - djvu9 7y ago
    Just take a look around to check out new enterprise MIS projects being implemented with a simple golang backend + reactjs etc frontend. The adoption of intereactive/responsive and single page web UI, and the more iterative development practices are certainly driving to a different direction compared to Spring (and RoR etc). I think the main force is from the frontend tech here and that is why you see them in the same sentence.

lars_francke 7y ago

Please remember that such viewpoints tend to be very subjective and depend a lot on your environment. Where I am (geographically, company wise and ecosystem) Java and the Java ecosystem are very much thriving.

tyingq 7y ago
I wouldn't say that for Java EE.
- lars_francke 7y ago
  That's true for me as well. There are a few select components from EE that I see but other than that it's of no relevance for me either.

ivan_gammel 7y ago

Java is not even close to be pronounced dead and it’s still the best ecosystem and platform on the market.

realusername 7y ago

I would not go as far to say it's dying but it's heavily slowing down for sure. First because of the big move out of the "entreprise" software and secondly because of Oracle legal team. It's definitely due to the licensing that Android is switching to Kotlin for example.

pjmlp 7y ago
Except that Kotlin still lags behind Java compiler speed and it is heavily dependent on Java libraries.
- erik_seaberg 7y ago
  Compiler speed is a fantastic tradeoff. I'm made of meat that runs at maybe 0.0001 MHz after coffee, so I want to offload anything I can to the compiler!
  - dunefox 7y ago
    That's a very sensible standpoint.
  - pjmlp 7y ago
    I rather bet in platform languages, without extra layers to debug, FFI and additional tooling not available to all IDEs for the respective platform.
- realusername 7y ago
  All of these are technical issues which will be solved by Google eventually, I'm not worrying much about that, they definitely have the resources to make it work.
  - pjmlp 7y ago
    I bet that in 5 years Kotlin will have as much market as other alternative JVMs languages have today. And regarding Google, Kotlin is not among the beloved ChromeOS and Fuchsia languages. So it depends very much on their internal politics.

smoyer 7y ago

Spring is compliant with and reliant on many of the JavaEE specifications - JDBC, Servlet, JAX-RS, etc. It provides DI that is not JavaEEs CDI. I'd consider Spring as more of a non-JavaEE application server. Pick either Spring or Wildfly/Glassfish/Websphere/etc and you're either using part of the JavaEE specification with the former or the full specification with the latter. Avoiding JavaEE for micro-services requires moving to something like DropWizard. Instead of a 200MB application server you end up with a 20MB application. Unfortunately, running that application in a Docker container will spin up a 180MB JVM. So the main reason we're moving away from JavaEE is actually more related to our move to container orchestration and that was originally driven by our adoption of micro-services. If you write a micro-service with a single end-point why should it use 500MB of memory?

roca 7y ago

Nothing wrong with being the new COBOL. We need a new COBOL is Java is pretty good for that. At least it would be if Oracle wasn't trying to squeeze it dry.

wbl 7y ago

Good luck doing that when OpenJDK exists.

jillesvangurp 7y ago

I've spend quite a bit of time doing javascript and typescript lately. Typescript definitely patches up a lot of the ugliness of javascript but you still deal with the same messy ecosystem of tools, libraries, and other cruft. It's been slowly getting better over the years but it's still not that great. I see typescript more as a gateway drug for people who seem to think that Javascript is all there is and then discover that actually having a type system unlocks all these amazing new tools that the rest of our industry has been enjoying for a few decades. Guess what, if you like typescript, you'll love Kotlin. It's a much cleaner language, just as expressive, and it has a whole range of things that typescript simply can't do or that it simply does better/more elegantly because typescript is stuck preserving compatibility with javascript and all it's weirdness. MS has done a wonderful job of shoving a lot of that under the carpet with typescript but fundamentally types are optional because all javascript has to be valid typescript and therefore it has to also allow all the silly hacks, misguided features, and other cruft that javascript people have been coming up with for the past decades. You might also like C#, Rust, Elixir, and several other languages that each offer their own tools, libraries, and features. I'm seeing a pattern with many frontend developers in the last few years that they at some point become full stack developers and shortly after start adding more languages to their repertoire. I know former node.js developers doing Rust, Go, Elixir, Kotlin, Rust, etc. now. Most of them are not very eager to move back to doing node.js projects. Like Kotlin all these languages are all coming to the node.js/browser ecosystem through WASM. Full stack in 2020 is going to be a very different beast than just a few years ago. Right now WASM already allows lots of languages to be used for just about anything that people currently do with javascript and typescript in browsers or in the node.js ecosystem. As this becomes more mature, people are inevitably going to change the ecosystem. This is already happening. E.g. Rust is being used for many low level npms for a few years now. However people have also been developing frameworks and libraries in Rust that work around/replace that ecosystem entirely. For a Rust person dealing with crates is preferable to dealing with npms, webpack and all the other stuff that is used in that ecosystem. So, they are fixing that. The goal there is to run pure rust in wasm in the browser or on v8 with 0 npms pulled in or used during the build process. Likewise, there's an ecoysystem of multi platform kotlin libraries emerging and that allows you to build wasm or native applications and libraries without needing things like webpack, npm, etc (but using gradle instead). Same with C# and blazor. Each of those ecosystems uses browsers and node.js as runtimes but try to minimize/eliminate/replace most of the rest of that ecosystem. In the same way the Kotlin ecosystem is also starting to provide alternatives to stuff from the java EE and Spring ecosystem. E.g. Ktor is a multi platform web application framework that you can use instead of spring boot and run natively or on the jvm. It's also a drop in replacement for anything you might want to do with e.g. express.js. Doing express.js applications in Kotlin is of course also possible, but why would you when you can have ktor instead? In the same way building react applications in Rust is possible, but replacing it with a rust specific framework is much less awkward. So, I agree things are changing but I'd say the node.js/browser landsace is changing as well and will not involve a whole lot of javascript/typescript for people coming from the JVM or other ecosystems. You might make the point that there are all these millions of npms out there that can't be replaced easily. I'd counter that with the point that an awful lot of them seem to have very short shelf lives and are in fact replaced/discarded regularly.

coldtea 7y ago

>The Java ecosystem has been slowly dying for years, it's already the new Cobol at this stage. Not in any industry I know.

hodgesrm 7y ago

Time for another sortie by the COBOL evangelism task force. Java has been the new COBOL since its inception in the 1990s. I programmed quite a bit in COBOL early in my career. It's an extremely efficient language for scanning records especially in an era when a large proportion of data was stored offline on mag tape. Most common business problems of the era could be expressed and solved effectively in COBOL, which is why it became so popular. I programmed in both C++ and Smalltalk in the early 1990s, which were innovative but also difficult to use for large systems. Java hit a happy medium with its C++-like object syntax, built-in libraries, and virtual machine operation with garbage collection. Add in the network effects from wide adoption (leading to tools and libraries) and it became a huge hit. Oracle seems to be going out of its way to submerge the language in confusion. But nobody should mistake this as a reflection on the inherent capabilities of Java or its fitness for use. Edit: correct typo

DaiPlusPlus 7y ago
How does one secure a COBOL gig today, and is the supply:demand ratio such to guarantee excellent compensation and working conditions?
- DonHopkins 7y ago
  Be patient, and talk to your local Alcor representative. https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39 https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39
int_19h 7y ago
I think you're missing the point of the COBOL comparison. It is not meant to imply that Java is similar to COBOL as languages go, or that it is as bad as COBOL, or even that COBOL is bad. In fact, you described exactly why it is the new COBOL: because it is also an efficient and popular language for common business problems of our era, that is hugely popular, but mostly in "unexciting" places like large internal enterprise apps, out of sight for many. And just like COBOL, it will keep ticking on like that, probably forever.

tootie 7y ago

JavaScript is practically stone age compared to Java. Debugging is a nightmare. Documentation is a nightmare. Scaling is a nightmare. NPM is a thousand monkeys at a thousand typewriters. Java suffers from having some 20-year old codebases because it's been so popular for so long but I can open up a 2004 WebLogic project in Eclipse or InteeliJ and trace everything it's doing. And modern Java has added all the nice features we expect a modern language to have. Java's slow demise is due to terrible PR and Oracle's endless insistence on JEE when every sane developer is using Spring.

udkl 7y ago
This. Sure JavaScript is moving fast .... but it's moving haphazardly.
exabrial 7y ago
CDI may be the golden egg though. I enjoy using it as an alternative to Spring, it's just unfortunate it comes with the deadweight of legacy ee.
iSnow 7y ago
I am not very sensitive to all those issues, I find the JS/CSS/HTML web stack a bit antiquated (virtual DOM, LOL), but very usable. But the build toolstack is a pure, unadulterated nightmare. I used to think Maven's XML orgies, archetypes and learning curve were bad, but diving into Webpack et al was a new dimension of horror. This time based on JSON, though.

pron 7y ago

> The Java ecosystem has been slowly dying for years, it's already the new Cobol at this stage. This has been said for at least the last ten years. Not only is Java not dying, but companies like Apple and Facebook (not to mention Netflix, Amazon and Google, that are mostly or largely Java already) are increasing their investment in the platform. This was not the case when COBOL was 25. The reason this is so is that Java is by far the most technologically advanced server-side platform in existence. It continuously presents technological breakthroughs in GC, compilation, and low-overhead profiling technology (just in the past few years it did so again in all three -- with ZGC, Graal and JFR). Node, Python, Go, Erlang -- none of them even come close. .NET comes closest, but even it is pretty far behind. This certainly wasn't the case when COBOL was 25. It is true that for a short period of time, somewhere between 2002 and 2005, Java was more dominant than it is today, but that was a fluke. More "scripty" runtimes and languages were usually more successful in the "smallish software" domain. In 1995-2002 that was VB (and others); now it's Python. Also, there has been some decline in all languages due to the ubiquity of JavaScript on the browser, but Java did not suffer more than others. Maybe less so. > Oracle did not take a note from the Microsoft book and is really behaving that an evil corporate overlord. Oracle has just open sourced the entire JDK. Sun didn't do that and even .NET isn't entirely open source. I have no knowledge or involvement with EE, but it seems Oracle simply doesn't have faith in EE, and doesn't want the Java trademark associated with it. (I work at Oracle on the JDK -- i.e. OpenJDK -- but speak only for myself)

dijit 7y ago
I think you’ve drunk the kool-aid a little. Outside of complex projects headed by PhD compsci students (who used to learn java in uni but those courses are now taught in python) there isn’t a whole lot of mindshare going towards java these days. At least in regards to new FOSS projects. I can say that my company’s use of java is diminishing rapidly over the last 5 years too. No matter what you think of the technological advancement of the language and ecosystem- it matters not if people are not using it. Oracle itself is a pariah, the vast majority of the tech industry avoid it.
- pron 7y ago

edwinyzh 7y ago

As a Delphi developer this is the first time I heard about Java is dying, and in a reply the other one said that some is saying so for over a decade :D And I think Java is more alive then Delphi, at least no one is setting up a site like http://www.isdelphidead.com/ http://www.isdelphidead.com/ :D

nullwasamistake 7y ago

Java is much closer to C++ than COBOL. COBOL has been massively obsolete for decades. Java has a lot of historical cruft but the basic syntax is still somewhat modern, mostly based off of C++ and agruable better. Like C++, it's modern features are being slowly added. There's a huge difference between Java 8 and 11, in performance and features. Innovation is hardly dead. Java EE and Spring are both terrible. I recommend trying some of the newer frameworks out there to see how much nicer things have become. DropWizard is my favorite right now. I'm no Oracle fan, but Java is more "open" in many ways than it has been since the beginning. It wasn't till a few years ago we had a feature-complete high performance OSS implementation as the standard. Oracle will try to ruin it, but the GPL JDK and history of projects being forked away from them makes it fairly safe. It's not in the interest of any Java user to have more than one standard. IMO Java isn't going anywhere. It's been top 3 most popular language for over a decade. JS is somewhat promising but will never match Java in performance and multi-threading support due to core design decisions. Go is too verbose to get industry buyin to replace Java in most use cases. WASM is promising in the far future but it will take years to have a full browser and server ABI. The only real contenter to replace Java is C# and so far it's not getting much traction. If anything killed Java it would be C#. Value types, no type Erasure, unsafe code and some native vector support. But it hasn't and probably won't ever dethrone Java. Java has a combination of decent features and an insanely huge amount of library support that makes it the default language of many companies.

floriol 7y ago
Why do you think Java EE is terrible?

oselhn 7y ago

Recently started working on Typescript project and it looks to me like java with really poor tooling, C++ like compilation times and huge mess in libraries (i.e. how to determine which version of @types package I need). I think that Typescript is really step back from java.

ksec 7y ago

How can a languages and its ecosystem that is being used actively in many projects within ALL Fortune Global 500 company and most Fortune Global 2000 be dying? When people say Ruby is dying, it would be more accurate to say they are not growing or they are shrinking. But given the size of Ruby marketshare of less than say ~2%. I would not really disagree with their notion. But Java? I mean even from a Web Development prospective, given you mention Node, JS and Spring Framework, it is Far from dead. And this is speaking as someone who likes Ruby and dislike Java.

xorcist 7y ago

On the contrary! They are likely very aware of Microsoft's strategy and probably regard it as being too soft. They intend to milk their technology to the last drop. You and I may regard it as evil, but it's a perfectly valid strategy. Perhaps it's more common outside IT? It's the brutally honest business strategy. I can sort of appreciate that they don't play around. Perhaps not my first choice of technology, but you certainly know where you have them.

fmakunbound 7y ago

> Spring was a much better framework than Java EE You can't compare these frameworks. They're in entirely different spaces, with different requirements and constraints.