Java 12
jdk.java.netI'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 years like some flavour-of-the-month Javascript framework.
Even on the client where Java has lost to Javascript, I'm finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javascript+CSS+DOM (+ maybe Electron). Personally I think it's a shame Sun dropped the ball with client Java - if they had chosen SWT over Swing and provided a minimal JVM then maybe Java Web Start would have beaten Javascript web apps. It's also a shame Sun sold Java to Oracle - Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun.
I'm now trying Dart to develop a few Flutter apps. It's no doubt a better language, but not that much better - I think Flutter would have been more successful if it was built on Java.
The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serving APIs (expressjs and core http request API, which expressjs middlewares forwards and decorates) is stable since node.js v0.1 or at least 2015, and infinitely better than Java's servlet, JSP, and taglib APIs (web.xml/jetty-config.xml anyone?).
The flip side of Java's stability is stagnation. On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess.
SWT? I'm glad it works for you. Last I heard, IBM had pulled out of developing Eclipse and SWT/RCP over ten years ago. In the one project where we used it, the app looked like an IDE, and customers hated, then cancelled it. Designed as wrappers for OS-native GUI controls, it has even less of a place in a browser than Swing had. Last I looked, of the Java rich-client frameworks, only Swing has been updated with HIDPI support, whereas JavaFX and SWT haven't. None is using any of those (with the exception of experimental JFX apps) for new apps in this decade.
You can call Spring (boot) over-engineered. I call it feature full and extensible.
Whereas in the modern JS world, you start out with a lean project and then add small libraries from NPM that all work slightly different for every feature you need, in the Spring world where the framework has matured for 10+ years most of the things you will need are in the box or are available as external libraries that all work on the same defined interfaces.
Spring Boot with Java 11 or Kotlin are still my preferred backend stack for that reason. It’s solid, has aged well and makes me super productive.
Actually they just said that Java's server-side stack is overengineered, and that Spring/Spring Boot hides that complexity. I think that is mostly true.
"Spring/Spring Boot hides that complexity"
Until it doesn't, then everything goes to Hell very quickly.
Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it.
Program logic is defined in anything and everything, except actual Java code.
The whole thing is a nightmare ignoring every principle of simplicity, composability, referential transparency, and every other established principle of good software design.
> Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it.
I see a comment like this every week on HN and I've been meaning to write a blogpost or two to address this.
Yes, as you mentioned there is a myriad of ways to configure a Spring(Boot) application, and I think that is one of things that make it such a powerful framework or platform to build a service on. To address a few of your points:
* beans defined in XML : we don't do that anymore since annotations got introduced. I haven't written a beans.xml file in years.
* Program logic is exactly where you expect it: in the Java code. All the property files and annotations are used for configuration to allow for different environments. This setup allows us to run the exact same binary jar or docker image built from CI to run in CI, in dev, in staging and in multiple different production environments.
* configuration settings and property files are the same thing as the configuration values go into property files, you can have multiple property files to group configuration logically by their purpose, and if needed duplicate each property file per environment to group those together. I know my database config for the staging environment is in database-staging.properties. If that is not enough you can easily override any of the values with environment variables
* Debugging : another point where Java gets huge flak here on HN is huge stack traces, well I think those are actually helpful in figuring out exactly what is running and giving you trouble in a specific environment. And because of the separation of configuration from code mentioned above it is trivial to setup a testcase with the exact same configuration that you are having trouble with and use a debugger on that testcase to inspect and debug.
* Simplicity and composability : While the framework can look complex if you don't understand the configuration system, it is actually there to facilitate composability. See my point about running the same binary in all environments. The big idea is that you put all code in the same repo and then compose and configure your application at runtime with the configuration system.
I understand where you come from but for me this is a huge drawback when I have to use Spring. I never know what to expect when working on a new spring project.
> beans defined in XML : we don't do that anymore But you still can do that! Also you still can do DI with Autowired private fields instead of injecting via constructors. You can also create beans based on properties. You can also create beans automatically via a included JAR on your class path. On Spring Boot you can also have beans created based based on some conditional annotation. And now there's yet another new DSL [1] to create your beans programatically on startup time. Tracking down and debugging what's loaded in Spring is super hard compared to Guice for example.
Configuration is another piece of software that I have a really hard time to think why they do that. You can configure via a YAML file, AND via a properties file, AND overriding via environment variables, AND also with a configuration server that store your properties on a separated server, and they are all mixed together in a weird single configuration entry for the specific environment that you have. Probably this made sense some 10 years ago when we loved J2EE but why support this kind of madness nowadays?
What I feel Spring is missing so much is forgetting about all the past and where the framework came from, start from scratch with simple premises around reactor-netty [2], only supporting the functional DSL, no crazy class path scanning, no crazy configuration loading, just a simple DI framework with some batteries included.
[1] https://spring.io/blog/2017/08/01/spring-framework-5-kotlin-... [2] https://github.com/reactor/reactor-netty
Parent said that Spring Boot accomplishes that with more over-engineering and metaprogramming. I wanted to point out that what parent calls over-engineering is actually useful abstractions that make it easy to get started out of the box, and have sane standardized interfaces to replace or integrate components where needed.
Haha! Funny man! I am only doing javascript occasionly. Most of my time i do python and swift.
Even stuff in “core” dependencies like webpack/yarn/npm/npx/nvm/babel changes a few times a year.
Right now doing a react native app and a browser extension. While javascript/typescript is fun to write, the time you have to spend fixing the tools is just horrible. Whiping cache, rebooting, switching package versions.. It makes the overall experience cumbersome.
I would not call something stable if it manages to work 2 whole years.
> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming.
There was definitely an era of that, but over the past decade or so it's been acknowledged as a problem, and there's been a lot of effort put into making things simpler and more vanilla. Modern Spring is much much closer to plain old code. (Of course it's still possible to write in the XML/setter injection/afterPropertiesSet style, and always will be - that's backward compatibility for you - but it's very possible to migrate existing applications to a better style in place, which very few platforms manage).
> Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess.
Maven is pretty close to the perfect build system, it's just taken a while for knowledge and practices to catch up with it. All the stuff people love and praise Cargo for, Maven has been doing for 15+ years.
The basics of maven might be sound (though it could make it easier to work with local dependencies) and npm et al have basically copied it. Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. I've developed Java apps since almost the beginning, and am as much of a markup geek as could be, but still hate maven with a passion, and often times do not understand what tf it wants from me. I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads.
However, I don't want to sound too negative. I can see a perspective for the JVM (Graal/Truffle) as a polyglot runtime where most of the ancient Java stuff is hidden from you, and you're using JavaScript or other non-JVM-only language as a migration strategy to get rid of Java alltogether in the distant future.
> Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc.
Could you be a bit more concrete? I don't recognize any of your descriptions in my experience of maven.
There are probably some bad plugins out there, but as in any system the solution is not to use them.
The complete lifecycle is listed in the documentation, and it's all very common-sense.
pom.xml isn't meant to be Turing-complete, and if you try to use it like a Turing-complete build language you will get yourself in trouble (as many of the early Ant diehards did). You need to treat it as a declarative config file, no different from e.g. Cargo.toml.
> I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads.
It's just the opposite. I don't expect anyone to want to maintain Ant or Gradle builds in the future, since they can have any kind of crap in them. But Maven builds are forced to be kept sensible; the tool just isn't flexible enough to let you put crap in your build definition, by design. (If you really insist on doing crap you can make a crappy plugin, but your plugin is then forced to be versioned, tagged in VCS etc., so stands a better chance of being picked up by your organisation's normal code quality efforts).
I may be biased by doing freelance work (eg. seeing only crap projects), but almost all customers struggle with fckn maven: migrating freaking jetty-maven-plugin, servlet api versioning conflicts, ad-hoc scripting using ant plugin, shading/fatjar plugins, multiple mvn central listings for the same artifact, fragile local dependency resolution, dozens of pointless submodules. A customer of mine even had a solid 3 week outage when they wanted to setup a product for blue/green deployment based on maven. Makes autotools look like a sane build tool.
> migrating freaking jetty-maven-plugin
There's a jetty-maven-plugin? What for? When I use jetty I treat it as a library, embed it in my application, write my own main() and then my application is just a normal application.
> servlet api versioning conflicts
> multiple mvn central listings for the same artifact
These are a genuine problems but they're ones that every mature ecosystem struggles with. Maven has better tooling than most IME - you can use the enforcer plugin to require dependency convergence, and when multiple packages contain the same API you can put exclusions in a common parent. No ecosystem has really solved the problem of package renames nicely, IME.
> ad-hoc scripting using ant plugin
Yeah don't do that. If people will insist on shooting themselves in the foot, there's only so much you can do to stop them.
> shading/fatjar plugin
What went wrong there? IME the shade plugin is very good. There are a couple of inherent JVM-level limitations (having to specify transformers for service locator files etc. because of the way the JVM spec is written) but it's hard to imagine any other build tool could do better.
> fragile local dependency resolution
Not my experience at all - what specifically goes wrong?
> dozens of pointless submodules
Submodules are cheap. IME when coming to work on a new project it's much easier to understand the build/dependency structure if there are lot of submodules rather than a complex build - e.g. rather than trying to have a custom build phase for generating some RPC stubs or whatever, it's fine to just have them in their own submodule and then it's obvious to the reader what the dependency graph looks like. What's the downside?
> A customer of mine even had a solid 3 week outage when they wanted to setup a product for blue/green deployment based on maven.
What? How?
> Makes autotools look like a sane build tool.
Strongly disagree with that one. Autotools has several layers of template/macro expansion that all seem to do much the same thing (so why not just one?) and encourages builds that use arbitrary unversioned command line tools from the host system, meaning you very rarely get reproducible behaviour on a host with a different setup. Maven gives consistent, declarative builds - what's not to like?
"Modern Spring is much much closer to plain old code."
Modern Spring, as far as I can tell, is still very much driven outside of Java code, it's just migrated from XML to annotations and yaml properties files. Seems almost like the typical Spring application has more lines of annotations and properties files than lines of Java code.
I am fond of Maven, though, especially with Gradle (superior to pom files).
> Modern Spring, as far as I can tell, is still very much driven outside of Java code, it's just migrated from XML to annotations and yaml properties files.
Disagree; there's been a shift to using constructor injection over setter injection, which often obviates the need for Spring-specific lifecycle methods. So it's now much more common to have a service class that, while it may have Spring annotations on its constructor, can also be used in a first-class way in plain old Java, and e.g. doesn't use Spring for unit tests. If you're using Spring at all then part of your application wiring lives outside Java code almost by definition, but it's now more common to express wiring logic as e.g. an annotated Java method rather than encoded into XML. It's not a complete departure, and it may not go as far as you or I would like, but I do think there's been a real cultural shift.
> especially with Gradle (superior to pom files).
It really isn't. Arbitrary unmanaged code in the build definition is great for writing but terrible for maintainability.
Bad decisions can be made using any technology. Java has a lot of crufty legacy APIs because, well it has a legacy. I gave up using JSPs years ago for Freemarker. I now use Vert.x rather than servlet contains which gives me a node.js environment but with access to the Java ecosystems and basic things like mature logging frameworks, as well as more advanced features (oh and multithreading in a single process).
Despite Spring being Enterprise it still scales down to simpler apps pretty well due to its modularity.
These can be build into a single jar app that is easy to build and deploy, and combined with a database migration library, maintain their own database schemas. Very, very usable.
Yes, I probably would not use Java on the frontend unless it was for a technical audience.
Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks. Not sure where the 'over-engineered' view comes from. I'd call that 'sane'.
People complain about the verbosity of Java, but how much time do you spend learning a new framework and all of the gotchas? At the end of the day it seems easier to just write the boilerplate. All of that verbose code means you got exactly what you asked for.
JVM projects never surprise me. When there is a problem debugging is a dream.
>Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks.
That. I've used the Servlets API for years in the early to late 00s.
I'm now (for the past 5 years) using Express with Node.
Static typing and cosmetic differences aside, Servlets and Express (or Node's raw handlers) are pretty much the same API.
Request, Response objects, handlers, middleware (iirc we used to call those last "filters" in the Servlet era), etc. It's not like it's some alien convoluted design.
(Java Server Faces now was another thing)
Any app reaching complexity of what’s being done on Java will look the same, no matter what platform do you choose. I haven’t yet seen large nodejs deployments with MLOCs and hundreds of developers, but I’m pretty sure it can easily become much bigger mess - the tools and the libraries are immature, there’s lack of enterprise SDLC patterns etc, which creates a lot of obstacles. Spring is becoming too enterprisey these days, that’s true, but it’s still fit for use in modern architectures - only if you understand how to utilize all of its capabilities.
nodejs isn't a replacement for fat backends for sure, but it's working really well for a frontend-facing light backend where frontend developers can add endpoints as the need arises, such as for autocomplete functionality, and where first-party support for asset pipeline tools is desired. The Spring experience isn't bad for newbies creating "REST" microservice spaghetti to have something to show at the end of their agile day, but it gets seriously in your way if you're a seasoned dev and have a solid understanding of what you want to achieve in terms of network-exposed interfaces and integration with other apps.
I‘m seasoned dev with 20 years of Java programming experience, I see no problems using Spring and I don’t see why anyone with similar experience would have any. It’s sometimes not obvious, how some things work, but it’s open source and the code is quite good to analyze, extend or replace.
"the code is quite good to analyze, extend or replace"
But how do you even know what code to read when so much of the program's logic is in annotations and other kinds of action at a distance?
Exactly. For example, if you're (still) using Spring MVC, what gets called in your backend on a given action attribute in your JSP or Thymeleaf or whatever template, is expressed through your method signature and lots of annotations where the order of arguments matter eg. some magic attributes must come right after others. All you see in your debugger, though, is that your request hangs in some nested and chained handler and reflection monstrosity driven by annotations and who knows what. Took multiple developers a day or two to figure out, each on their own.
It's not that Spring is badly coded or something, I just don't need these surprises and the magical thinking surrounding newbie Spring Boot projects.
Newbie can write bad code on any platform, but it‘s a short period of life of software developer - the problem of beginners is solved not by the tools they use, but through a reasonable composition of the team with sufficient number of experienced developers who can define the architecture and best practices.
From what I can tell, the "bad" Spring code is the code following the recommended Best Practices, at least according to the tutorials that pop up in Google search results.
There’s one “must read” tutorial - documentation on official Spring website. There’s also github account with lots of examples. It’s better to ignore the trash that comes from search results, because either it’s trivial or obsolete.
Another related surprising thing (as I'm currently learning Spring/Hibernate/etc.) is what happens when the Hibernate Validator library is missing at runtime:
Nothing.
All the carefully crafted validation annotations just don't do anything, no validation is performed, and there is no indication whatsoever of this.
It’s not a problem with annotations or Spring - could happen e.g. with SPI and anything that’s discovered in runtime. It’s about how you build your project and configure dependencies (separation of API and implementation in different JARs is typical for Java and implies certain way of thought about build and deployment).
The source code of Spring itself. I know Spring internals - there’s no dark magic there and reference guide describes it well. DI is straightforward, MVC - not perfect, but generally easy, Security - well, it has design problems, but they are not related to annotations.
"but they are not related to annotations"
I had a problem with security that I could only solve by adding an "Order" annotation to my class. Reading the code and stepping through it in the debugger did me absolutely no good.
So, annotation was a solution to a problem (how to define a sequence in which configuration is applied), not a cause, right?
> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming.
Could you elaborate on the overengineering part? There are many modern frameworks that are much lighterweight than Spring/Spring Boot, and with the introduction of lambdas in Java, things are even more straightforward.
Also, gradle doesn't use XML.
In all these years I have used Spring exactly once for an architecture prototype, during one month project.
All our customers doing Java Web projects are either on JEE, or a CMS platform running on top of servlets and JEE related JSRs, like Liferay and AM.
I have no doubt it's working for you and your customers. But JEE and JSRs have been a dead end for many years now. When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it?
In 2006 I played around with Jackrabbit for an architecture concept (for managing airworthiness of airplanes and kit). That was before the Iphone even existed. I was honestly surprised Adobe is still using it in their AEM product. From what I recall, it manages a document tree, based on a 2004-ish, Drupal-like node graph in typical Java enterprise fashion.
I'm no insider, but my guess is Adobe is struggling for some time now to integrate AEM, Magento, and other purchases into a lineup for creating shopping experiences. We'll see how this works out.
>When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it?
Not any more than PEPs are.
Edit: Liferay is a portlets container isn't it? My experience is only with Websfear portal (shudder) but I think managing UI state on the server has had no reason to exist since at least 2008 when Chrome/V8 came out, and the massive JavaScript improvements of the last 10 years following it
Meanwhile JavaScript frameworks are all the hype rediscovering server side rendering to improve performance.
I have learned it pays off longterm to watch caravans pass by.
Pure HTML and CSS with minimal JavaScript rules rendering performance.
One of my Java guilty pleasures is pulling in some 14 year old library and it just works. Absolute gold for a company with a lotta old code sitting around.
I also do a good bit of frontend and holy crap it's exhausting. That's the main reason I push hard for Java backend. Backends tend to stick around about a decade longer than you would like, while front end code is due for a rewrite every 3 years
>Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun.
They didn't and Google didn't want a pay a single dollar to Sun on Java. As James Gosling has mentioned multiple times. I don't understand why people are still painting Google as Saint after all these years.
actually they didn't want to pay a single dollar to sun, because of licensing reasons, not because they didn't wanted to buy java.
currently they recreated the java apis by pulling in apache harmony and they tought that they are in the right or at least in a fair use position (they still think they do). but I agree, I'm not sure if the direction of java would've been better when google would have the stewardship.
They had the opportunity to buy Sun when it went on sale, instead they thought they could get away with it.
just had this conversation with a co-worker today.
java is a stable api but it also doesn't evolve. The tradeoff is you get a program guaranteed to work no matter the upgrade vs being able to build better toolage.
React changes every year or 2. It is exhausting. But you get way better patterns and some things that drastically improve productivity.
Java gives you a flexible object oriented language and an incredible set of libraries. It's got an archiver for artifact and dependency management. It now has lambdas and has FRP style stream programming. I'd say it's kept up pretty well with modern fashion, while it's been doing other things far longer than newer, more popular languages. Take Swift, now my daily driver (which I love so much compared to ObjC, which I moved to after Java)... an example of something Java had way before Swift is "Protocol Oriented Programming". Also, Swing's GridBagLayout predates iOS' AutoLayout and CSS (edit: don't know where I was going with CSS haha...). Everything old is new again, and I'm sure Java reinvented a few wheels of it's own.
Also keep in mind that React is a library, not a language. If you want to compare things, compare Javascript to Java, or the Java stdlibs to React. Maybe that's what you meant when you said Java.
IMO, Java and its libraries are nicer to work with solely due to its static nature and OO design. It is worlds apart from a scripting language when you need to refactor, or even just understand, legacy code. And if you can't even run tests on that legacy code anymore, like a React project over a year or two old?
What are the better patterns and productivity boosts you get from React vs. a Java ecosystem?
In addition to all of these good things, you can also use groovy which has a ton of shorthand syntax and makes writing code super easy. Groovy also makes writing tests short and simple. I love java and all jvm languages honestly.
Kotlin though. Everything you said, but a joy to write instead of a chore.
I am betting Kotlin is the new Groovy.
Lets see where it stands 5 years from now, specially if Fuchsia actually gets released.
Kotlin is different because of the focus on tooling, which is the advantage Java still had over all the dynamically typed JVM languages.
Also, Kotlin/Native is in beta now and could target Fuchsia (compiling AOT to native code using LLVM).
What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans?
Still not able to use several of Android Studio features available to Java, like incremental compilation and slim APKs?
Kotlin advocates seem to forget JVM will never be rewritten in Kotlin, the language is just yet another guest, with the usual syndrome to wrap existing libraries, having to take care about FFI for Java access, not having all features taking advatange of the latest bytecodes, e.g. lambdas implementation.
As for Kotlin/Native, there is nothing to worry about versus what Go, Rust, C++, Dart, D, Nim offer in terms of performance, libraries and in some cases tooling.
Having to buy CLion for a graphical debugger isn't a selling point versus the established alternatives.
Fuchsia is being written in Go, Rust, C++ and Dart, with the team now hiring for node.js support.
https://www.androidpolice.com/2019/03/19/google-working-to-b...
>What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans?
Seeing that both Eclipse and Netbeans are now more or less dead (and speaking as a long time Eclipse user, from the very first version to around 4), yes, first class vendor-direct InteliJ support is more than enough. And more than most languages (including Groovy) ever had.
>As for Kotlin/Native, there is nothing to worry about versus what Go, Rust, C++, Dart, D, Nim offer in terms of performance, libraries and in some cases tooling.
IMHO, Rust will always be kind of niche as hard to tackle, Dart we'll see, D never went anywhere, and Nim will remain niche, it's a little too idiosyncratic to catch on.
Kotlin is already more popular than all of the above except perhaps Go.
>Fuchsia is being written in Go, Rust, C++ and Dart, with the team now hiring for node.js support.
Fuchsia is still vaporware or at least irrelevant. It's not even in the market yet. And the fact that it's written in 4 (and looking for 5th) languages doesn't really bring much confidence.
Groovy had Netbeans and Eclipse support, which was dropped when it started fading away.
We move in different worlds, no InteliJ installations around here.
I remember when Groovy was popular, with every JUG in Germany having weekly talks and Sun talking how the next JEE revision would support Groovy for writing beans.
Popularity doesn't write software.
>Groovy had Netbeans and Eclipse support, which was dropped when it started fading away.
I know, I've used it. What I said is that it did not have the first class IDE attention of a major vendor, those were mostly third party sub-par plugins compared to the Java focus of those IDEs. For Kotlin, however, it was first class IDE support as a primary concern from the start.
>We move in different worlds, no InteliJ installations around here.
Then we indeed move in different worlds.
>Popularity doesn't write software.
No, its just the only thing that matters when it comes to get paid for it.
Delivering working software as per customer's RFP is what matters, everything else is fluff.
I don't understand how Groovy is fading away when it is getting more and more popular. Groovy is also very similar to Java. There is no learning curve, you are immediately creating value.
More popular where?
Had it not been for Google's adoption of Gradle for Android and it would have been left for Grails maintenance projects.
And even then, the pressure for perfomance has been so much that it is being superceded by a Kotlin based DSL.
How to improve Gradle has been a common talk at every Android conference since Android Studio has been introduced.
Everywhere?
Google Trends says Groovy is just as popular as it was 10 years ago. The number of downloads has increased significantly but it is not because of Gradle, as Gradle bundles Groovy. It is also currently placed #16. on TIOBE Index
And last, Groovy with compile static is in most cases, just as fast and memory efficient as Java.
Some people always talk down Groovy, yet the numbers speak for them self. Before Kotlin, Groovy was attacked by Scala developers.
The major thing Groovy has over both Scala and Kotlin is strong similarity to Java syntax which makes the learning curve non-existing. And that is a bigger deal than a random cryptic/confusing programming expression. Code readability is very important.
> Some people always talk down Groovy, yet the numbers speak for them self
Many of those numbers are fake. Groovy was #70 on the Tiobe index only 12 months ago, see [1], but is #16 now. How do you explain that? Groovy was last in Tiobe's top 20 about 2 years ago when the search numbers for "Groovy" from Baidu were hugely incorrect. Groovy later quickly dropped back out of the top 50.
Certainly not in Germany where it vanished from JUGs.
https://trends.google.com/trends/explore?q=%2Fm%2F07sbkfb,%2...
Java worldwide average 86%
Groovy worldwide average 2%
Pretty popular indeed.
"Cédric Champeau: Goodbye, Groovy!"
Fuchsia is language agnostic. This is a boon. Writing for Fuchsia isn’t like writing for Unix where C is king. Fuchsia is able to natively host many more ecosystems than Linux cares to bother with. It gives me great confidence.
Tons of great stuff for Unix is written in C++ and other languages all the way to Python and Java. You can write Unix apps in whatever language you want. Ditto for Windows and MacOS.
Not sure what the special deal is with Fuchsia here.
Perhaps you think you'll be able to write Fucshia device drivers with any language you like? That wont be the case at all.
Also Linux has this going in its favor over Fucshia: it actually exists.
Windows has been language agnostic for decades.
What's so remarkable about that fact?
"InteliJ support is more than enough"
That won't get kotlin more traction. No proper/official tools for LSP support means no vscode, vim, emacs etc. users. As a happy eclipse user, I wouldn't call it dead either.
Groovy was a random JVM-based dynamic language with no major company support and no special tooling.
Kotlin has IntelliJ (and thus a great IDE) and Google standing behind it, and Steve Yegge's nod of approval.
Not every Java shop is going to drop Eclipse and Netbeans just to make JetBrains happy.
As for Android, lets see what happens with Fuchsia.
The overwhelming majority of Java developers don't even know who Steve Yegge is.
>Not every Java shop is going to drop Eclipse and Netbeans just to make JetBrains happy.
True. They will drop them because Eclipse has been faltering for ages and has been dropped by IBM, and Netbeans has always been a subpar unloved stepchild used by the kind of devs that don't know better and think SlickEdit or Notepad++ are great editors.
>The overwhelming majority of Java developers don't even know who Steve Yegge is.
That's on them.
I guess Fortune 500's have missed that memo, including IBM own subsidiaries.
Lets talk back in 5 years from now.
I am betting Kotlin would become yet another language that happens to compile to the JVM, after the Android honeymoon goes away.
>I guess Fortune 500's have missed that memo, including IBM own subsidiaries.
They probably did. They're late for all memos. The Fortune 500 is not were you'll go to gauge adoption. Heck, half of them still have IE6 only apps.
There are hundreds of thousands of companies, and just 500, well, Fortune 500.
Apparently you use the most established and boring development-wise of companies (Fortune 500) to prove Kotlin is not used widely, but you're OK with vaporware like Fucscia that's not even beta yet as an argument that Dart and co are.
>I am betting Kotlin would become yet another language that happens to compile to the JVM
And I bet you're wrong. Let's see in 5 years. We were on HN 10 years ago, we'll probably be here then. I'll set a reminder.
Because they prove Google is struggling with internal politics where to go next.
There are plenty of java projects that change apis. Comparing a framework to a language is stupid.
If you develop, not if you maintain. This is a major reason we stay away from JS frameworks after burning the hands on implementing an AngularJS that was obsolete a year later.
That and a few page reloads never killed anyone.
Doesn't evolve _quickly_. Which as you say is say is part of the tradeoff of giving a trustable guarantee that the tooling you do use will continue to work for a long time.
I've been working professionally in Java for almost 20 years. I can't remember the last time I saw someone use features introduced after 1.6. The time API in 1.8 was nice. I've never seen anyone use lambdas in production code. I'm sure people do use newer stuff, but I think it's the minority. So in practice it's even more stable than it is in the headlines.
Strange, our production code is full of streams and lambdas. It probably depends on the type of product.
I work for a large company and the code base is full of streams and lambdas. Streams are almost used too much and could be replaced with a simple for-loop.
Yeah, stream overuse is definitely an issue at our company.
I started using Streams and lambdas immediately, along with functional interfaces. Java is still not nearly as pleasant as Scala or Clojure, however.
Chromium (and so Chrome too) uses lambdas in its Java parts.
Last time I used java, I used it extensivelly lambda, collection map and flatmap, optinnals... But old school javaist barely used them though.
We start using new features pretty much as soon as the new JDK version is released to general use.
I started using them ASAP.
>java is a stable api but it also doesn't evolve
You have probably missed the last 5 years. From streams, to closures, to default methods, to functional interfaces, to local type inference, to new Process APIs, to modules, to unsigned arithmetic, to new date/time APIs, http client, 2 new GCs, shell REPL, etc... with more to come, and new releases every 3 months...
> unsigned arithmetic
I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)?
Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types.
[0] https://kotlinlang.org/docs/reference/basic-types.html#unsig...
>I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)?
Yes, but it's also a new feature (along with dozens of others). The complaint I answered was that Java is stagnant somehow, when it has been evolving fast in the last 5 years, and is accelerating its pace (release cadenze) even more.
>Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types.
Which, given that the JVM doesn't support them at the bytecode level (iirc), they also use some similar trick of working with signed numbers under the hood, just hide it better at the syntax level.
I love Dart and Flutter. I actually think it was a good idea not to use Java. Dart is much more modern and nice to work with in my opinion. There are many reason and I won't dwell into it here. The biggest-ish project I've built with Flutter is an alternative to Nissan's ConnectEV app; it's used with the electric vehicles Nissan Leaf and Nissan E-NV200. You can see statistics, battery status and control climate control and charging of your vehicle. My alternative is called "My Leaf" on the Play Store and "My Leaf for Nissan EV" on the App Store. It's completely open source; https://gitlab.com/tobiaswkjeldsen/carwingsflutter
It consists of the main Flutter app and a Dart library for communicating with Nissan's API.
I am currently building my first mobile app on Flutter and quite happy I choose that technology! Developing in AndroidStudio + Flutter does not feel like the chore I remember developing android apps to be.
Biggest barrier to entry for me is the build dependency system Maven. And I never understood Ant. I did like the language when I played around with Java 8. Streams are amazing.
Maven is an incredible system. It can do so much and yet, even though I've setup countless apps and services, I can never use it without looking literally everything up.
Maven and spring are the worst parts, for me, when dealing with Java. I don't mind the language at all.
Yeah I felt the same. The language is fine. It’s got a fantastic set of libraries and a large ecosystem and one would be hard pressed to not find a job being a competent Java dev but maven ugh
With maven, less is more. Huge maven files usually means something is wrong.
Follow the conventions and it is less than a screenful for a basic project.
I typically solved maven problems by removing cruft and falling back to the standards.
What was your problem specifically ? For me these two worked great together actually. I really loved Spring. Maybe the problem has some overlooked fix that I can help with ?
Nothing in particular just lots of seemingly random issues trying and failing to get them working correctly, likely due to my lack of knowledge but every time I try to better learn them my brain just can't handle it.
I don't know what it is. I think part of it is my auto-cringe when I see XML nowadays.
I can understand the feeling. I think in the new Spring framework configurations are written in Java. I think this is from version 4.0. So that will solve your XML issues. However, I do make the assumption that you have control over what version of Spring you use. I think there is a problem with the documentation of Spring Boot when it comes to config code since you have a lot of stuff with XML but not so much with the modern Java based stuff. However you can try to learn how to map the XML to Java, you only need a few things to learn that mapping not the full XML configuration knowledge.
The success of javascript is hugely because of no dependency-hell (not being able to upgrade some lib to a new version, because it would conflict with some other lib which requires it in its current version and you can't have both of them loaded at the same time)
> It's also a shame Sun sold Java to Oracle
Worse: Oracle bought Sun.
Worse: IBM, Google and everyone else could have done it as well, but decided not to counter-offer.
The most interesting new feature I think is the Shenandoah GC. The summary from [1]:
"Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB."
The original algorithm was published in 2016 [2]. It consists of 4 phases: initial marking, concurrent marking, final marking, and concurrent compaction.
GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages for game development. This could open up the JVM for games, which could have some exciting implications.
Their lower end target is 10 ms. In a game, 16 ms is your entire time budget.
ZGC, included in JDK 11, has a 1ms average pause time and 4ms max on some demanding benchmarks, and they're now targeting 1ms max pauses.
Wow great link. I live pretty deep in Javaland and had no idea it was that good!
If it lives up to claims surely it’s a paid for add on?
Originally it was intended as a commercial feature, but since JDK 11 Oracle open sourced all previously-commercial features in the JDK, and now it's part of OpenJDK. It's already available in JDK 11 and 12.
I never got to the level where I needed anything more than the stock default GC. But this looks compelling. Does Kotlin and other JVM based languages benefit from it, too?
Sure. All languages that run on the Java platform[1] can benefit from it, and from most other Java platform enhancements.
[1]: I prefer saying Java platform rather than JVM, because a program written in Kotlin shares over 90% of its infrastructure code with a program written in Java (not including the OS), and the JVM constitutes only about 20% of that.
It works really great with heaps >100GB and is included in the openjdk since 11. Note, that only linux is supported, I think
As my world is currently only serverside this isn’t a limitation but a feature ;)
In VR your budget is 11 ms and you can't miss it or the entire frame is thrown away and you introduce a frame of latency to compensate. So for VR these kind of effects of GC are even worse.
Also, while most games are fine with losing a frame or two every few minutes, in VR dropping frames will cause motion sickness really fast. FPS is, from what I've observed, the most important part of a VR game. If you're dropping frames or stuttering, the experience will suffer greatly
When I was developing a VR game, my team noticed that some ultra-sensitive people started to get sick when we would drop around five frames (the vive displays 90, so this is only a ~5% drop). There was more to it (dropping a few frames every few minutes was usually fine, but consistently dropping frames every second or two is an issue).
10 ms isn't all that much. When games load in assets they'll do various things like malloc huge chunks and you lose a few frames.
If GC only causes occasional (maybe every 2 minutes) loss of a frame or two it should be no problem. If you watch benchmark FPS traces that count every frame delay you'll see that occasional stutters happen in basically every game.
Loss of a single frame just isn't noticeable
Quake, back in the late 90s, would preload assets for all entities in a level at level load time explicitly to avoid stutter when the entity finally shows up and needs to make a noise or whatever.
And some games much later didn't. I recall needing to fire off a shot on each new gun I picked up in Far Cry to be sure I wouldn't get a stutter later at a more critical moment.
Frame drops that happen more than once every several seconds are definitely noticeable (and, as a sibling comment pointed out, especially so in VR). Plus, throwing away more than half your frame budget just because of GC seems unreasonable. And this isn't even considering monitors with high refresh rates, which are slowly getting more and more popular.
> When games load in assets they'll do various things like malloc huge chunks and you lose a few frames.
Streaming/Loading assets in the main render thread is a very 2005 thing to do.
Yeah, the whole reason you have pools and arena allocators is so that you don't do small/large malloc mid-frame. Perf 101 is don't malloc during regular gameplay.
If you have some control over when a GC triggers you could sneak one in during hitstun.
A few of us built a webgl game backend in Java. It was fun but optimizing to make everything always work within 16ms was hard. In our case it was especially complicated because we shared state over websockets back to the clients.
16ms is only if you're just targeting 60fps. We now have 144hz monitors, leaving less than half of that if you want to take full advantage of the hardware.
Once upon a time the barrier was the existance of VMT tables and method dispatch.
GC use can be optimized in high level languages with support for value types (which are still missing in Java, though) and it is not like every game needs to be the next Fortnight.
Only tangentially related to your comment, Fortnite is based on UE4 so it does use garbage collection. And it has caused framerate/hitching issues as recently as a year ago according to an Epic developer.
https://www.reddit.com/r/FortNiteBR/comments/7gu8aq/hitching...
My point being that everyone evaluates programming languages for writing games as if they would be doing a AAA hit, when they will actually be doing a minesweeper clone.
Thanks for pointing it out though.
I didn't realize UE4 adds a garbage collector on to C++. Interesting.
Yes. UE4 also extends C++ with its own reflection system as well which is used all over the place, and critical to the garbage collector.
There are a lot of applications where predictable performance is just as important, if not moreso, as good performance.
Honestly, if you need real performance when writing a game, there's no reason not use the language that's most popular for your engine of choice. Mostly that's gong to be C++ with python scripting.
The GC doesn't just affect high-performance games. The problem is it doesn't just make things broadly slower; it introduces what can easily become a second-long pause a couple times a minute. Even if your game runs buttery smooth the rest of the time, that's pretty much unacceptable. There are measures to minimize it - object pooling, for example - but they remove most of the benefits of having a GC in the first place.
And Lua scripting
LuaJIT, presumably?
This has already happened in a way. Unity uses a ton of C# for scripting. While C# is somewhat nicer to work with, this low pause GC makes java a compelling option for moving much more logic into the VM language
Keep in mind that C# has support for non-primitive value types (structs) which means you can avoid garbage collection entirely if you're careful (not all that difficult in my experience). Additionally, Unity has just introduced a specialized low-latency garbage collector in their beta build. Overall, from where I'm standing, Java doesn't look very appealing for game development.
Lack of value types sucks so yes I agree. On the other hand this new GC might be fast enough that it just doesn't matter if you create garbage for most purposes
Yeah, I do wonder how Unity deals with the GC. Maybe there's an algorithm like this one, maybe the engine's core systems (physics and graphics) are written in native code.
C# as a language does tend to be nicer than Java, but its VM doesn't have as rich a family of languages.
My limited understanding is that high end Unity devs code their stuff not to make garbage. Unity has a very nice system for profiling that sort of thing.
Also, CLR has F#, which I like much better than Scala (and, no type erasure in CLR), Clojure which is ... just like Clojure on JVM, and C#, which as a Java dev since 1.1 I have come to prefer as a language even as I remain JVM ecosystem preferring on the server side. JVM has ABCL, a neat Common Lisp, and now Graal/Truffle which is super interesting. If not for Clojure though (and maybe Kotlin) I would probably give up on the JVM. Oracle does not help. Just my opinion.
I did just remember that C# has value-type data structures (which last I checked, Java didn't) which probably helps a lot. Most objects can probably be kept on the stack, and objects on the stack don't need to be garbage collected.
Totally agree. C# and kin are far better designed. It's the lively Java ecosystem that keeps me around as well
Less “lively Java ecosystem” - more “slow-moving Enterprise Java environments”.
Is Clojure on CLR actively maintained?
Yes, it's one of the officially supported platforms (albeit the least used one).
The first thing a game programmer will do in a garbage collected environment is either try to disable it or control it.
Or learn that maybe for the game that they are making it doesn't matter.
And if it does, making themselved acquainted with how value types, slices and gc-free pointers work would probably be a better idea.
>GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages
There is such a thing as reference counting :)
Trivial reference-counting can lead to memory leaks when you have an object graph that’s disjoint from an RC root object.
Non-trivial reference counting starts to look like mark-and-sweep GC.
And even then, when a ref count drops to zero, the runtime cost of destruction and deallocation of particular objects can be expensive. Stop-the-world GC is bad, but “make a blocking call because you can’t use async APIs in destructors” is worse - especially when the destructor runs in a program thread instead of a GC thread.
I feel that languages which provide support for defined object ownership and lifetime (Rust, any others?) will become the future because in many scenarios object-lifetime can be nailed-down by the compiler and thus eliminate the need for GC or ARC.
From my understanding of Rust, you will still pay the runtime cost of destruction and deallocation of objects with the object lifetime system ? It's like reference counting, but precomputed by the compiler. Please correct me if I'm wrong.
The way the "it's like reference counting" mental model goes wrong is that things don't live arbitrarily wrong. Reference counting is used to extend the life of things, Rust will not do that.
But yes, it's malloc and free.
It’s like manual allocate/deallocate. Only that the compiler will insert free (or drop, in case of Rust) for your variables when it reaches end of scope.
Right. It’s just easier to reason about the process with Rust’s ownership system compared to a reference-counting or GC system.
What makes you think reference counting leads to shorter pauses than tracing? While it is absolutely true that sophisticated implementations of garbage collection via ref counting can exhibit similar performance to sophisticated tracing algorithms[1], most implementations of ref counting aren't nearly as sophisticated as modern implementations of tracing, and tend to be worse.
[1]: https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
Not necessarily shorter, but predictable pauses.
Very predicatable indeed.
Go and C# running circles around Swift.
"35C3 - Safe and Secure Drivers in High-Level Languages"
https://www.youtube.com/watch?v=aSuRyLBrXgI
Possible stack overflows and unexpected pauses due to heavily nested data structures.
"CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default."
If your memory usage is regular and predictable, then both ref counting and tracing would behave regularly and predictably, and if it isn't, neither is.
How is memory efficiency? Usually faster and/or consistent GC performance comes at the cost of extra memory usage.
(This is why I'm excited for ARC / Swift on the server...)
From the tests I've seen on beta versions, no difference.
The performance increase is from a different algorithm + full multithreading. Not from collecting garbage less often as is a common tactic to reduce time spent in GC
Go and C# running circles around Swift.
"35C3 - Safe and Secure Drivers in High-Level Languages"
Well, not exactly C#. At 39:00 they show significant latency problems with C#’s garbage collector. Go and Rust did well though.
Will be interesting to see if ARC gets optimized for use cases like this (drivers). I wouldn’t say it’s super representative of general server programming though. And unless I missed it I don’t think they compared memory footprint.
This thread reads eerily like threads about Go's low latency GC from 2015 and how 10ms isn't good enough and throughput will be impacted and on and on. Three years later Go treats any 500 microsecond pause as a bug as Go continues to focus on throughput. Shenandoah is being put together by some very very smart people and I'm optimistic that the only thing that stands in the way of Java reaching the "500 microseconds is a bug" level is engineering hours and resources. More kudos for this achievement are in order.
Is there a guide to the various GC algorithms? Suppose I'm running an app where pause times don't matter, and I want throughout or reduced memory usage. How much more of this will I get by switching to another GC algorithm? 2%? 20%? 40%?
Mostly profiling.
Each JVM implementation (Azul, IBM, OpenJDK, PTC, Aicas,...) has their own collection of GC algorithms.
And their behaviour depends pretty much on the application as well.
Thanks. I understand that the numbers require profiling to determine, but I wish there was at least a high-level guide like:
Do you want to optimise pause times? Use X. Optimise throughput without regard to pause times? Use Y. Optimise memory use? Use Z.
It may not be accurate in every case (no guideline is), but it would be a good starting point for the vast majority of us who don't know the pros and cons of various collectors.
Here are some guides for different JVMs,
https://docs.oracle.com/javase/10/gctuning/introduction-garb...
https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/gen...
https://www.infoq.com/articles/G1-One-Garbage-Collector-To-R...
https://www.infoq.com/articles/tuning-tips-G1-GC
https://developer.ibm.com/articles/garbage-collection-tradeo...
https://www-01.ibm.com/support/docview.wss?uid=swg27013824&a...
> The most interesting new feature I think is the Shenandoah GC.
Well, one could build and run Shenandoah GC with JDK8 and JDK11. Ref: https://wiki.openjdk.java.net/display/shenandoah/Main#Main-B...
Here's a presentation on Shenandoah by one of the principal developers (focuses on the how): https://youtube.com/watch?v=4d9-FQZZoVA
Slides: https://christineflood.files.wordpress.com/2014/10/shenandoa...
Another presentation (focuses on the how, why, and when) at devoxx: https://www.youtube.com/watch?v=VCeHkcwfF9Q
Slides: https://shipilev.net/talks/devoxx-Nov2017-shenandoah.pdf
---
Tangent: Go GC (generational, non-copying, concurrent mark and concurrent sweep) and the improvements it saw from 1.5 -> 1.8 https://blog.golang.org/ismmkeynote
The mutator/pacer scheme, the tri-color mark scheme, using rw-barriers during the sweep phase are interesting to contrast between the two GCs.
Will this help spark performance at all? I remember having to make a lot of GC tweaks in order to get some of the larger jobs to run.
For most ordinary applications I've seen around about 5-10% of the time is spent on GC. Maybe some badly tuned applications would see benefits.
If you want an order of magnitude jump in performance need to see if the IBM work on Scala Native version of Spark manifests.
It should help performance on almost any JVM app, but much more on large heaps.
The GC time is lower and multi-threaded but most importantly the "pause time" is low and nearly constant (based on root set size)
The old GC's all scaled pause time roughly linearly with heap size. Apps that created a lot of garbage would have all their threads yielded for large amounts of time.
Now, essentially, it doesn't matter how much garbage you create. This is awesome because you used to carefully watch how many allocations you made to avoid bad GC times. Now it doesn't matter. Make as much trash as you want and the GC will deal with it
Interesting that they explicitly exclude time to safe point from that improvement. In my experience that is usually most expensive part of a stw pause.
> Pause times with Shenandoah are independent of heap size
I expect this needs to be taken with a chunk of salt, since a smaller heap can only require so much GC...
> I expect this needs to be taken with a chunk of salt, since a smaller heap can only require so much GC...
Pause times. Not GC times. Shenandoah pauses to scan the root set only. The size of the root set doesn't grow with the size of the heap.
You can have a large root set and a tiny heap, or a tiny root set and a massive heap. They're entirely independent.
What happens if a huge object becomes unreferenced and a new one of the same size is then allocated before the older one is GC'd (and you don't have enough memory to hold both simultaneously)? Does it just crash or does it pause to collect the older objects first?
It won't crash, but what it does is somewhat complicated. There's a section in the OpenJDK wiki addressing this question:
https://wiki.openjdk.java.net/display/shenandoah/Main#Main-F...
> Full GC. If nothing helped, for example, when Degenerated GC had not freed up enough memory, Full GC cycle would happen, and compact the heap to the max. Certain scenarios, like the unusually fragmented heap coupled with implementation performance bugs and overlooks, would be fixed only by Full GC. This last-ditch GC guarantees that application would not fail with OOM, if there is at least some memory is available.
> Usual latency induced: >100 ms, but can be more, especially on a very occupied heap
Seems like it confirms precisely what I wrote? You can get longer pauses the less memory you have left, i.e. the more of the heap you've used...
I mean that's effectively a deployment error. You're not supposed to run your application without enough head-room. You can degrade almost any GC by restricting the head-room. You're reading from the 'failure modes' section there.
Switch expressions prepare the way for pattern matching (https://openjdk.java.net/jeps/305), instead of `instanceof` checks and casts.
But (in my naive opinion) double dispatch seems a more elegant and java-ry solution, i.e. polymorphism on argument classes, so different methods are invoked for different object runtime classes (instead of using the compiletime type of the variable).
The switching could be optimised, as ordinary polymorphism is in the JVM.
Sure, you'd wreck legacy code if you just introduced it, but there's surely a backcompatible way to do it that isn't too awkward.
BONUS: goodbye visitor pattern!
That kind of multiple dispatch would be far more disruptive at several levels, and still wouldn’t really get you where you want to go without a lot more compiler and JIT magic.
Sure, you could match on types, but you wouldn’t be able to extend that to destructuring patterns, or regsxps as patterns on strings, or so many other ways patterns may be extended in future releases.
My comment's a little out of place. I'm not against pattern matching, but for double dispatch; we can have both.
Their initial motivating examples was bare instanceof, but I now see they extend it.
How would destructuring fit this model ?!
Brian Goetz has writes quite a bit about ongoing projects. The latest article he has done about pattern matching is I think http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.h.... There is a load of stuff in there about destructuring patterns from about half way down.
Thanks, a methodical article! Not keen on special support required for destructuring. Nice that they discuss Visitor pattern (and the switch example for such cases looks nice). They don't dicuss double dispatch - but not relevant to them.
I'm learning Swift on the side, I was pleasantly surprised by this.
Anybody know how the graal project ties in with all of this? Is oracle effectively developing 3 different JVMs (OpenJDK, Oracle JDK, GraalVM)? Or is there some sort of convergence plan?
From what I understand, graal has made a lot of headway with language interop, as well as a handful of specific memory optimizations and native compilation, but overall is lagging in pure throughput/latency performance behind hotspot. It would be really cool if we could get the best of both worlds.
Well the relationship between OpenJDK and Oracle JDK is that OpenJDK is the FOSS base and Oracle JDK is the proprietary structure built on top, kinda like Chromium and Chrome
As for GraalVM, I don't think it's meant to be mixed in with those 2 at all. From their website (https://www.graalvm.org/), it sounds to me as if it's a completely different project that shares none of the goals the other 2 JDKs have:
> GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Kotlin, Clojure, and LLVM-based languages such as C and C++.
> GraalVM removes the isolation between programming languages and enables interoperability in a shared runtime. It can run either standalone or in the context of OpenJDK, Node.js, Oracle Database, or MySQL.
Notably, Graal has been used extensively by TruffleRuby for a while now. It's not oficially ready for prime time but definitely promising.
Graal is a JIT for Hotspot (and other things), you can already use it be turning on experimental features and enabling JVMCICompiler. Graalvm is that packaged up with the Truffle framework (and languages written for that), and SubstrateVM which allows programs to be ahead of time compiled and linked as executables with a minimal VM.
> overall is lagging in pure throughput/latency performance behind hotspot
Twitter use Graal in production - I think it's about 13% faster for them on their real workloads. If you send a Tweet it's going through Graal.
Oracle JDK is just the Oracle(TM) Supported branding of OpenJDK, now. As of Java 11, there are no feature parity or real technical differences between OpenJDK or OracleJDK, just support/EOL differences from vendors. So, that's pretty simple.
GraalVM is... complicated. There are a few parts to it:
1) An advanced JIT compiler, written in Java, and distributed as ordinary maven/jar packages, etc. You can use it yourself if you want. Interestingly, this compiler package ("graal") can be used for the JVM itself, and it will be used to compile the Java code that is run by the JVM. The "JVMCI" feature allows you to plug third party compilers into the JVM and replace HotSpot, and Graal (the library) is such a replacement. You can use this compiler on ordinary OpenJDK 10+ with a special startup invocation.
2) Truffle, which is another library for writing programming language interpreters. It does a lot of magic to make them fast. It uses the graal JIT compiler to do this, so it depends on the previous library.
3) A bunch of programming language implementations under umbrella: Python, JS, etc. These are implemented using Truffle. By using Truffle, these language implementations magically share an object model (so they can interoperate), and they get a JIT compiler, based on Graal, for "free". This means the languages can interoperate and JIT together cleanly (the compiler can inline JavaScript into Ruby!)
4) If you use Graal as the JVMCI compiler (i.e. for your host Java code), and you use Truffle-based languages -- Graal can extend benefit #3 to the host Java code itself. This effectively means the JIT compiler can inline and optimize code across every language boundary.
5) SubstrateVM, which is is a tool to turn Java programs into native exe binaries. The intent is you use SVM on the programming language interpreters, to produce interpreter binaries that look "normal" to the user. These binaries are run on custom, non-JDK/HotSpot runtime. The Java code is not JITed, but interpreted code -- Ruby, Python, JS, etc -- is. (This means you have benefit #3, but not #4). SubstrateVM uses a custom generational garbage collector (written in Java!)
6) The "GraalVM distribution", from graalvm.org. This is a combination of all the above pieces together as a sanctioned package. This package uses JDK8 as the base virtual machine.
7) The GraalVM distribution comes in both a "community" and "commercial" edition, which do have technical/feature differences.
Here's the thing: you can use everything from 1-4 with an "ordinary" OpenJDK today if you know what you're doing, and you don't need a special JDK build. SubstrateVM might also be workable, but I don't know.
Points 6-7 actually mean that there is generally a difference between "GraalVM the platform" and "Graal the compiler". Notably, while OpenJDK no longer has feature gaps vs the commercial OracleJDK, GraalVM does, which I find a very weird choice on Oracle's behalf and unfortunate, but maybe it will change one day.
If you want to use one of the new low-latency garbage collectors (ZGC/Shenandoah) with Graal, I don't think that's possible as of right now: garbage collectors need to interface with the JIT compiler, but ZGC does not support the JVMCI interface (it will explode on startup), and Shenandoah doesn't either, I believe (but maybe this changed). This will almost certainly be fixed in the future, of course.
Thanks, this is a really useful overview, and also explains why I always seem to get so many different explanations as to what graal is.
This is excellent thank you
Included is JEP 230, a Microbenchmark Suite. It's based off of JMH. Nice to see this included!
Are they ever going to release value types?
Adding values is a huge task because they are a big change at the VM, language, and library level. You can read about some of the latest plans in draft form at https://mail.openjdk.java.net/pipermail/valhalla-spec-expert....
Rest assured progress is being made.
Sounds like we won't have them in the next LTS, so probably another 5 years at least.
Next lts is 14 which is due in a year as I understand the new release schedule.
No, the next scheduled LTS will be 17. The idea is that 1 release every 3 years will be an LTS release.
I’m not sure what would happen if values landed in 18, it might be an important enough change for people to want break the LTS cadence.
The worst thing Oracle can do is deliver a bad feature. Java Gererics turn 15 this year. It's better to delay such a radical change than being stuck with it for the next few decades. Oracle is no hurry to do that. Maybe they get it together in time for the next LTS release (Java 14).
You can play with them today.
https://jdk.java.net/valhalla/
The engineering problem is that they want to keep old jars running on a world of value types.
I get Java needs it because some uses need the performance gain in terms of less ram and less pointer interdirection. I'm glad library authors of like servers or caches will be able to improve performance without weird things like unsafe byte buffers and native memory leaks.
I suspect I won't ever use value types in my code though unless it's drop in to refactor from AnyVal=>AnyRef (or w/e the java equiv is).
* Does accepting a value type parameter accept it by value or by ref? * How does this play with GC? Can I get dangling ref with value type? * How does value types play with inheritance e.g. will it be like c# and struct and they will be boxed any time treated as ref? * How safe will it be to convert a class from being value type based to Object (w/e AnyRef equiv is). Will I need to inspect all methods that deal it now?
This can probably just be resolved with a style guide like c++ can be mostly sane if you're starting a new project today with an aggressive style guide, but I just appreciated not think about this and just count on escape analysis + gc + hotspot tricks like monomorphize code paths with some counters to be good enough.
I share your frustration but this new GC should drastically reduce the issues with creating tons of garbage. There's still the infamous "allocation wall" but value types wouldn't solve that either. But they would make it a lot better
GC is only part of the issue. Value types allow much finer control over locality, something completely lacking in Java now. And without that, you give up a lot of performance.
For example: https://rcoh.me/posts/cache-oblivious-datastructures/
Yeah that was supposed to be in 12 wasn't it? Everyone is waiting for that, it will obsolete Lombok.
No feature is meant to be in a release. A feature will be done when it’s done, though features may be split so that some functionality can land earlier.
Data classes will reduce the need for Lombok/immutables. Less so for value types.
Still heavily a work in progress based on the in-flight commits getting sent to valhalla-dev@
Still nothing to handle checked exceptions in streams properly... sigh.
I wonder why they didn't use generic exception type in their java.util.function classes. That would propagate checked exceptions statically.
Something like
@FunctionalInterface interface Function<T, R, E extends Throwable> { R apply(T t) throws E; }In Java, the concept of exceptions is incompatible with the concept of parametrized types.
During compilation, type parameters are erased. "T" becomes "Object"; "T extends Something" becomes "Something"; assignment becomes type conversion. But at the end it works correctly. If you try to make something that wouldn't survive the type parameter erasure -- such as having two methods with the same name, one of which accepts "List<String>" and another accepts "List<Integer>" as their input -- it will be a compile-time error, because you can't have two methods with the same name and the same parameter "List".
But imagine that you have a type "MyException" extending RuntimeException, and your code has "catch (MyException)". After compilation, this would become "catch (RuntimeException)", which is wrong, because it would also catch other RuntimeExceptions, and it is not supposed to. But if you make this construction a compile-time error, then... the whole thing becomes useless, because what's the point of having an exception type you cannot catch.
The entire concept of checked exceptions is compile-time, because there's no checked exceptions in JVM. I don't really understand your argument. I'm not suggesting to catch exception of generic type, it won't be possible indeed, but it's not required either. You just need to tell compiler to pass "throws" via generic type. You can declare your map function with generic throws and compiler will respect that.
On further thought I understood that streams usually are lazy and real exception would be thrown not at map, but later (probably in collect or similar method). So it would require to propagate that E generic parameter to almost every function (and Stream type signature). Also it won't work well with multiple checked exceptions. So yeah, not that easy.
This doesn't work if your function throws multiple checked exceptions.
Ah, that's because java generics don't work with exceptions.
What do you mean? They do work with exceptions.
Ah, my mistake. I was thinking of generice type arguments for exception subclasses: https://www.mscharhag.com/java/java-exceptions-and-generic-t...
That also includes generic catch clauses and inner exception types of classes with type parameters.
Fairly straightforward to handle yourself e.g. https://github.com/unruly/control/blob/master/src/test/java/...
if you have to do this in every step of the Stream then it seems like a failed design.
Or in FunctionalInterface, or in anonymous functions.
Makes HashMap computeIfAbsent much less useful than it should be. It's impossible to use a function in there that throws a checked exception (all I want is for the exception to propagate out of computeIfAbsent for the parent method to deal with).
Best option I've found is to wrap it in an unchecked exception, then unwrap it in the parent method, which is just .... yuck.
Another option is to fool the compiler. So-called sneaky throws. Something like
public static void main(String[] args) { try { sneakyThrow(new IOException("io")); Test.<IOException>emulateThrows(); } catch (IOException e) { e.printStackTrace(); } } static void sneakyThrow(Throwable e) { Test.<RuntimeException>sneakyThrow2(e); } private static <E extends Throwable> void sneakyThrow2(Throwable e) throws E { @SuppressWarnings("unchecked") E e1 = (E) e; throw e1; } static <E extends Exception> void emulateThrows() throws E { }This only works if I'm throwing the exceptions myself, but not if I'm using a library function (like a rowMapper for example).
You can write wrapper which takes function that can throw anything and returns regular java.util.function.Function. Here's example: https://github.com/rainerhahnekamp/sneakythrow/blob/master/s...
I share the conclusion of the other statically typed JVM languages (Scala, Kotlin): checked exceptions are bad.
If they are officially bad, remove them from the language. It's a backwards-compatible change. Currently we are in a weird situation, when standard library does not work well with each other. It's like making iPhone without USB-C cable and Macbook without USB-A port.
> It's like making iPhone without USB-C cable and Macbook without USB-B port.
Was there ever a MacBook with USB-B?
Why not? https://apple-history.com/mb_late_09 for example.
That's USB A / Display Port
That's USB-A.
Yeah, I'm always confuse USB-A and USB-B, sorry. Edited my post.
> If they are officially bad, remove them from the language
java.util.Date is bad, but it's not getting removed. java.net.URLEncoder is bad, but it's not getting removed.
I find checked exceptions interesting. They happen to be the only example of an effect system in a mainstream language. Anders Hejlsberg formulated the main argument against them here [1] Basically the problem is that checked exceptions are infectious and intermediary code needs to annotate all the exceptions of code that it calls. Which is a chore. Lucas Rytz states in his PhD thesis [2] that the problem is not wich checked exceptions themselves, but that in the java implementation 'not mentioning an exception means if won't happen'. He proposes a system where the default is 'any exception' and being able to turn it off with a compiler flag. And states that the developer experience of that would be much better. This may become possible in Dotty Scala using the effect system based on implicit functions. But that's in 'proposed' status.
[1]https://www.artima.com/intv/handcuffs.html [2]https://lrytz.github.io/pubsTalks/ the link to his thesis doesn't work anymore. I cherry pick some of it in my talk for a Scala meetup in Utrecht https://www.slideshare.net/yoozd/effect-systems-in-scala-bey...
Yes. One can workaround it with the throw-as-unchecked pattern: https://stackoverflow.com/questions/14038649/java-sneakythro...
This isn’t something where I remember the details, but the language designers decided there was not a good solution. There are some links from Brian Goetz in the comments/answers: https://stackoverflow.com/questions/27644361/how-can-i-throw....
Not in base java, but some libraries essentially fix this. Vavr https://www.baeldung.com/exceptions-using-vavr
But my favorite is abusing the language using Lombok SneakyThrows. It just feels dirty using it. In a good way.
You should return some ResultOrError<Result, Error> value instead of throwing Exception..
That's what languages like Rust do with a return return type that is part of the core language.
Sometimes I wish Java had one too to complement Optional. I wonder what the argument against that is? Too much confusion with the existing Exception system?
Java managed to break the Optional type badly enough that it can't be used for its intended purpose (it can't contain null which would be great if the rest of the language couldn't contain null either, but as it stands it's not practical to port existing Java code to use Optional), so I wouldn't trust them to implement a working result type.
Working with result types is really cumbersome in languages that don't have HKT (Rust hacks around it with a special-purpose language feature), and even more so in languages that also don't have pattern-matching. So I'm not sure how much use it would be in practice. But yeah it's the right way to solve the problem.
The new switch feature looks nice, the way it previously used to work was so unwieldy.
In case someone is curious what it looks like with the new -> form:
switch (day) { case MONDAY, FRIDAY, SUNDAY -> System.out.println(6); case TUESDAY -> System.out.println(7); case THURSDAY, SATURDAY -> System.out.println(8); case WEDNESDAY -> System.out.println(9); }or using the switch as an expression
System.out.println(switch(day) { case MONDAY, FRIDAY, SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; });The number of times I've wished this was possible is probably 50% of the times I've used a switch statement.
That's much nicer. Anything else added to Java recently to reduce the boilerplate? I haven't used Java much in 5-6 years. Glad they are iterating faster.
Local type inference[1] means you can write:
The static initialisation methods on collections[2] let you writevar foo = new Map<String, String>();
It's still clunkier than many newer languages but it is improving.var foo = List.of(1, 2, 3);1. https://developer.oracle.com/java/jdk-10-local-variable-type...
2. https://docs.oracle.com/javase/9/docs/api/java/util/List.htm...
As another poster mentioned, the new type inference is great. So is lambda support. Another is Lombok.... Yeah it's not official but we use it literally everywhere and it helps a ton with data classes especially.
Nullaway and a bunch of other linters will also save you from accidentally falling in one of the dusty corners.
RxJava and Java Streams are also very nice.
Anonymous classes are nice too I guess (although they're fairly limited).
Overall the java experience has improved massively in the last 5 years, but you need to know where to look. Highly recommend the two popular "awesome java" repos on GitHub for an overview
The .parallel() method in Java Streams is basically one of my favourite magic spells ever.
Ah yes, parallel stream(), for when you need to filter a list of 13000 entries for.... Reasons. Bad reasons.
Use it all the time :)
I tried it once on a simple monte carlo thingy and legitimately said "wow!" out loud when it just worked.
God, all the fussing with threads and fork-joins and mapreduces and god knows what everyone else wanted me to do: gone. Gone!
Yeah seriously Java's threading support is good but the boilerplate was horrific.
One thing you should know is that parallel streams use default thread pool unless you specify otherwise. Had that choke up some REST handler threads a few times. If you think it might be an issue make sure to specify a different pool
I assume the expression becomes null if none of those match?
No my bad, it doesn't compile, you have to add a default.
switch assignment:
int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; };Reminds me of Kotlin's "when" statement
Meanwhile, most enterprise apps still seem to only work with JRE 8. And those which I know of have elected to replace Java rather than upgrade.
8? I see more 7 or even 6. Until recently I actually thought 8 was the latest until I needed to develop a small project and discovered we were at 11.
Actually, looking at the version history, I guess it's not weird that I thought 8 was pretty recent, as until 1.5 years ago (Sept '17) it was actually the latest and it is still supported until 2020 (unlike 9 and 10).
v6 2006 2007 2008 2009 2010 v7 2011 2012 2013 v8 2014 2015 2016 v9 2017 v10 2018 v11 2018 again v12 2019Java 8 is supported until 2023.
Funny enough, Java 11 will be end of life the following year. It's not even worth migrating to, better jump to java 15 then.
Java 11 isn't worth migrating to because it's end of life is 2024, more than 5 and a half years from now? That's a little extreme.
You have to realize that the first LTS release after 8 was v11 which was released only a bit over 6 months ago. V12 is a non LTS release. So v8 is going to be around for a while. Adding to this is the rather substantial refactoring that happened due to the introduction of modules in v9. This is creating more than the usual amount of porting headaches. IMHO v8 to v9 was by far the most disruptive Java release ever in that sense.
Part of the issue is that a lot of libraries target jdk 8 since that's what Android supports.
Actually libraries that target Android need to use Java 7, unless they want to constrain their users to API 26+.
Is newer Android fully JVM-8 compatible? It'd be great to be able to start using Scala 2.12 even if it means I have to restrict to new devices only.
Not really, a lot of desugering still takes place into DEX bytecodes.
Stuff like lambdas take extra memory, because they convert into anonymous innerclasses instead of invokedynamic.
As far as I'm concerned that's an implementation detail. If I can take arbitrary JVM8 code and run it and expect a correct result then that's a huge improvement for my purposes.
What are they replacing it with?
I see a lot of business apps that use Java on the client side with the JRE. From my observation, they're tending to move towards HTML5 clients, rather than updating to more modern Java versions. The fact that the January 2019 security update, 8u201, is the last version of Java 8 commercial entities can use for free, has pushed this a bit, it seems.
> The fact that the January 2019 security update, 8u201, is the last version of Java 8 commercial entities can use for free, has pushed this a bit, it seems.
Isn't OpenJDK providing updates for Java 8 through to September 2023? 8u202 is published ...
I wonder how many of that web-based client solutions (outside of SV) will be built on Oracle APEX.
What stacks are being picked by enterprise for these sorts of projects? C#?
Well, most of JavaEE is still stuck on JDK8, unfortunately. Last I heard that Payara is maybe getting JDK11 support in Q2, and OpenLiberty currently only supports JDK11 on OpenJ9.
replace with another jvm hosted language ? like scala / kotlin /clojure ?
We have quite a couple of them running happily with Java 11.
Were there any hiccups in the upgrade?
Donald Smith the (one of?) product manager of Java at Oracle did a talk for the London Java Community[1] recently. He briefly mentioned that getting onto Java 9 was the hard part, 10->11->12 are significantly easier due to the far smaller number of changes in the release.
The meetup was recorded[2]. I can't tell you how far through he mentions it, but its a good talk to watch as he goes into some of their rationale for their approach.
[1] https://www.meetup.com/Londonjavacommunity/events/258987722/ [2] https://www.youtube.com/watch?v=RWpo92OBaNA
I've done this a few times. Most are due to reflection limitations with the newodule system.
They can be worked around by adding exceptions to removal of reflection metadata largely. Kinda a PITA but not too hard.
Active libraries have pretty good Java 11 support these days though. It's really improved a lot on the past year or two
> Active libraries
So my upgrade is going to be tremendously hard for this application, then. Good to know
Haha yeah it might be a PITA. Unless your app is huge it shouldn't take more than a couple days though.
Basically a compile run fix reflection loop until you stop getting errors :'(
To Java 9 yes, mostly due to third party dependencies and the move to modules.
To Java 11 you might have additional hiccups when using JavaFX, or the JEE libraries that were also being bundled with the Java SE.
Which wasn't our case.
Great to see Java 12 (and the shorter release cycles) but how quickly do people actually move to newer Java? Here's a poll with some results: https://twitter.com/otisg/status/1108093046397247488 (still open, please vote so there is more data)
I wonder if they might condescend to utilize the JVM so I don't have to compile JMC myself for another 5 months, or maybe at least they'll remove their circular links that infuriatingly obscure the fact JMC binaries don't currently exist. For the past 5 months.
I wonder if they'll fix the performance again. I'm mostly peripheral to clojure-land and 8 still seems to be the best choice.
presumably there's still primitives and boxing ?
I wish they did not decouple JavaFX...
Yeah, that kinda makes it impossible to become a successor to Swing. But the situation actually got more sane because JavaFX can be included now as a Maven dependency, like any other framework.
Why do people still use Maven when Gradle exists?
I'll never know.
Because Maven doesn't require a background daemon eating 2GB of memory to be fast and IDEs can actually provide code completion and documentation while typing.
Android is the only reason to have to put up with Gradle.
Gradle 5 lets you write the build scripts in Kotlin, which is supposed to address the code completion issue. (And the continuous build mode is a nice feature!)
But, yes, is does use a lot of memory.
So I have to use additionally 2GB, adopt yet another programming language, to get back what Maven already gives me out of the box?
Eclipse and Netbeans compile on file save, can't get more continuous than that.
Fair enough. It doesn't sell me on switching back to Maven. Ram is cheap enough. With 32GB Gradle can have a couple if it wants.
Most dev laptops are still running with 8GB.
2GB for a cache that isn't required by alternatives for the same result just feels bad.
And don't get me started into turning build scripts into full blown applications impossible to decipher what is going on without some kind of debugging process.
Because there's only one syntax (yes, XML, but it's consistent), it's fast, the documentation is comprehensible, it has multi-project and multi-module support that is easy to understand, I lose track of what else.
Gradle is the worst allergic reaction to XML in history.
because every Maven project is more or less same while Gradle projects vary drastically...I don't know how anyone can tolerate Gradle and performance benefit is not that great...
The performance benefit is huge.
I understand not wanting to learn another build tool, but I have no regrets where I've moved to gradle. It's so much faster on a project of any size it's stunning.
90% of maven projects don't do anything terribly complicated. Porting them to gradle leaves them uncomplicated and unexciting. I just wish there was a standard release mechanism. Poor as mavene-release is, at least everybody uses it and understands it.
> 90% of maven projects don't do anything terribly complicated. Porting them to gradle leaves them uncomplicated and unexciting.
They don't stay uncomplicated though. Someone puts a quick one-liner hack in the build definition to fix some trivial issue they were having, and it never gets removed, and years later it bites you. I don't trust myself to remember and understand arbitrary code that I put in a build definition, yet alone anyone else.
Why is that? Decoupling benefits JavaFX so it can have release cycles on their own pace.
Decoupling might have benefitted JavaFX, but it did not benefit me who develops professional desktop applications for a living, and it did not benefit my users.
If they wanted to decouple, they first should have created a cross-platform jpackager-like tool that generates native executables for major platforms.
I remember JavaFX was launched with great fanfare as a modern replacement, which it certainly might have been - a modern, efficient platform. I am afraid it will slowly decay and dissolve into oblivion to be replaced by gigabyte-size electron apps.
This tool is called jlink. https://docs.oracle.com/javase/9/tools/jlink.htm
does it create a native executable?
It builds a directory of files which contains a .bat to launch the bundle.
so it DOES NOT build a native app (jpackager does, but it's a mess: present in 8, removed in 9, coming back in 12 without cross-platform targeting).
The major point of JavaFX is cross platform development. Please offer a cross-platform jpackager, and we'll be happy.
I’m missing the TL;DR on what language features may be introduced. Any ideas?
Check out the OpenJDK page: http://openjdk.java.net/projects/jdk/12/
I understand why Java has to keep on chugging along, but I feel bad for the people that have to be a part of it. It's like watching people keep coal trains going while people are moving to cars.
Why? Besides being owned by Oracle, which is enough of a reason to never use Java ever again, it's also lost the niches that brought it into existence. Java no longer runs everywhere. Java on the web is dead, and you can now write ubiquitous apps in basically every language. There's no reason to deal with the JVM and it's domain knowledge when you can write a nimble Go app for your backend and a Javascript app that will run on mobile, web, or desktop. A VM language? You mean v8 sandboxing and web workers; WASM which lets me write C, C++, and Rust all of which can talk to Javascript APIs. All of my services are stateless and ephemeral. Crashing is expected, and I can use host monitoring tools instead of introspecting the JDK. On the cloud it gets even worse for Java. Why use a meaty framework like Spring when I want to just spin up a bunch of micro services, or have an API gateway kickoff a bunch of lambda jobs.
Java also took OO in so many terrible directions. OO defined by it's creator looks nothing like the enterprise OO that big business sold to commoditize programming, which now only exists as a ball and chain on legacy systems.
One day Java will be like Cobol. There's probably a lot of money for Java developers for many more decades, but god I do not envy anyone that has to do it.
Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements).
More importantly, the JVM ecosystem is much bigger than Java itself. The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Clojure is one of the most popular and performant Lisps we currently have, and Scala is one of the closest things we'll get any time soon to a practical version of Haskell. Both of these projects got to avoid building their own garbage collectors, which is an enormous lowering of the effort barrier. And to top it all off, all of these languages' binaries are interoperable, which not only allows you to use different ones for different parts of the same system, but makes it much easier to gradually migrate your legacy codebase to a newer, better language.
I don't know if I'd start a new project in Java-the-language, but it's far from a Cobol situation.
> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin.
Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it. The latest version of Groovy still uses that syntax, so if Java has syntactic baggage, then Groovy has it too.
I'm picking Groovy will still have that baggage-laden syntax for a while yet. 2 yrs ago, Daniel Sun built an Antlr 4 based replacement grammar, but the Groovy project managers at Apache are taking their sweet time in rolling it along. They even had its optional preview removed from the version 2.6 beta of Groovy.
I wasn't aware of Groovy's roots, but that doesn't diminish the point. It elected to take on Java's baggage; the JVM didn't impose it.
No idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH.
Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy
Groovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension
What makes Groovy unsuitable as a replacement for Java, if the performance is now comparable?
For the masses, imho, all round Groovy just isn't polished enough and is too complex. We are bringing someone up to speed now and there is an enormous amount to teach. There are a range of pitfalls that you have to alert them to. Mind you, a lot of other Java replacements are like that (eg. Scala).
Particularly though, the static compilation is just not comprehensive enough. It tries to do type inference but it's limited and invariably you end up having to add type casts in ugly places to convince it that expressions are valid. Occasionally it actually flat out refuses to compile something valid and you have to find a different way to do it. Sometimes it compiles with one version of groovy and then is broken in the next. It works great though to selectively add to hotspots of code and in other places to speed them up and define them better.
Having said that, we are essentially using Groovy as a java replacement and for our team I think the above costs are well worth it. This is partly because we have a heterogenous application that is partly dynamic in its nature and Groovy's dynamic scripting ability is amazing for this. The fact we can code our whole back end in the same language makes it super easy and well integrated.
> doesn't share lost of the performance penalties of Groovy
That's a bit of a myth these days. Groovy may even be more performant than Kotlin when used with static compilation.
The new parser is available in the Groovy 3 alphas.
The Apache project managers removed the new parser from the Groovy 2.6 betas over 6 months ago after officially canceling it and saying Groovy 3 would be the next release. But no real work has been done on Groovy 3 since then. I'm guessing they really intend releasing version 2.6 some time in the future. Perhaps they'll say "Groovy 3 is still far off and Groovy needs another release, so let's resurrect Groovy 2.6". Don't expect to see Groovy 3 move beyond alpha version anytime soon.
thank you for this comment. it brings a lot of light on the ecosystem
It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs.
A lot of my reasoning was criticizing the JVM itself, not Java. VM languages add unnecessary complexity in the post container world where ephemerality and kernel APIs (containers) can give the same advantages, although I think Kotlin and Clojure and remarkably good languages.
>It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming.
And historically, nobody cared for that style of programming in its pure form (where "nobody" is in the casual sense: a few FP-lovers, but not the 95% of working programmers).
From 1960 to today it remains niche in its pure form, even the most popular language following it fully (e.g. Clojure or similar) is still a niche language.
We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles.
And that's what modern JS, Java, C#, Rust, etc (even C++) give us.
And since FP is a style, it can be followed quite effectively in almost any language -- as long as it has some basic features, which, as you observed, Java has added.
> And since FP is a style, it can be followed quite effectively in almost any language.
It's not black and white. FP is more like a spectrum, with pure functional programming more towards the opposite end, just before total functional programming. Put another way, adding lambdas to Java does not make it like Haskell. Even Scala cannot effectively be used as Haskell substitute, as some in that community eventually realised.
It remains to be see how much of FPs benefits (composition, abstraction, reasoning) can be fully realised in languages with rampant side-effects and mutation.
Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure". There are many other styles of programming that are data oriented and are a better definition for Rust and some circles of Javascript than functional, but ergonomics of composition and partial application leads to something far short of FP.
> We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles.
Which is why you forgot to mention Scala, which shows us how great such a promise land can be when we try to please everyone.
> JS, Java, C#, Rust, etc (even C++) give us.
Out of the languages you mentioned, only certain circles of Javascript (React) and Rust are arguably functional as I mentioned above. Javascript has been a real exception to the rule in how its lack of real class support left a vacuum for some FP. C++, C#, Java, and the majority of Javascript are object oriented and always will be.
Pedantically, you can't just redefine a term to suit your need calling something "pure" or "unpure".
No, I think they are using those terms correctly. In FP, “pure” means absolutely no side-effects. So if you add an FP-style library to an existing imperative language, that’s “impure”.
That's not the context in which the word was used, but it's a fair point. I have worked professionally with Haskell, and while I am not good at it (my forte is Erlang which is what I would consider "close to functional"), other developers I have worked with were very good, and watching them code in non functional languages and listen to how they thought about solving problems is were I developed the idea that adding a few features doesn't make a language functional.
> It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs.
I categorically disagree. Nearly any program has pieces that benefit from OOP and pieces that benefit from FP and everything in-between. The most prevalent and useful languages support multiple paradigms (C++ is a mess for other reasons).
I'm not sure if you're trolling so I'll try to keep this short.
Java is old, it's crufty. Yes.
But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff.
The JVM is also extremely reliable. I've seen apps run for years straight.
And the tooling is better than basically anything. Profiling, debugging, realtime code generation and modification. Libraries for anything you can imagine. ~4 solid IDE's.
Java's OO is fine, and all the nightmare patterns died years ago. You only see them because Java has been around for so long. Modern frameworks like Vert.X or DropWizard are fairly nice to work with. Even Spring Boot isn't too bad.
But Spring is dated and not often used for new projects.
The JVM has extremely powerful built in monitoring API's that put any other language I know of to shame.
WebWorkers are trash compared to Java's nice threading model. It even supports CPU optimized Atomics.
There's nothing unusual about writing microservices in Java. V8/Node is just as "big" a virtual machine as the JVM except JS runs ~5x slower and takes 5x more ram.
You can also write Lamda in Java.
There's many valid critisicms of Java but yours are largely invalid
> There's many valid critisicms of Java...
Yes there are.
...but the parent assertion that Java will one day be like cobol; no longer taught in intro to CS course (where now we see python), considered bloated and legacy, and not picked for new projects (where we see the rise of languages like kotlin eating into what was once the primary growth for the language with mobile apps) and encumbered by problematic licensing issues...
Seems quite valid.
You have to live in a bubble right now not to get the feeling Java is stumbling, and there’s no indication to me that the overall direction of the language is positive right now.
...I’m sure there are still years ahead for earning a good living as a java developer, don’t get me wrong, but that’s a different issue.
May be I am living in a bubble... it's always hard to tell from inside the bubble. But this is not my impression at all. All of the major tech companies have major Java footprint which is not going anywhere. This is not only the older tech companies (FB, Goog, Amazon etc.). Even newer companies like AirBnb, Uber rely heavily on Java. Startups often start with fancy esoteric languages but eventually do come around to java/c++/python once they need to really scale. I am not sure what exactly gives you the impression that Java is like Cobol.
Agree, and yeah Java is peaking "uncool". But I don't care. Call me old fashioned but the damn thing works so good I can forgive a multitude of sins
I see the same in major enterprise companies I and my peers have worked in. Java is being used for a lot of large greenfield projects I am aware of.
I agree that the future looks bright for Kotlin and C# .Net Core especially. I'm also a big fan of Typescript but JS derivatives are missing many nice things like threading.
But I disagree that Java is like Cobol. The syntax and general situation is extremely similar to C++. There's still tons of work being done on it, but it's a mature language that will be around for decades. IMO it's still the best language to run on the server for a multitude of reasons.
Like COBOL in the sense of its purported future niche in the industry, not in the sense of syntax and language power.
Yes perhaps that's true. I ask you to consider some c++ to java conversions though. Usually the syntax is almost identical, whereas COBOL is clearly terrible
Yes, the enterprise bubble where Java, .NET, C++ and JavaScript rule.
I mostly agree, except:
> But Spring is dated and not often used for new projects.
Spring Initialzr (https://start.spring.io) is used millions of times per year.
Fair enough. The Java ecosystem is huge and I try to keep up but many things slip through the cracks, you'll find many in my furious comment history on the thread.
Thanks, looking it ip
No worries. I feel where you're coming from.
Spring Boot is all but dated. I could name you countless huge companies using Spring Boot to write new applications that will be used by millions of people per day in Austria alone.
> But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff.
Fast is a poor word to talk about benchmarks between languages. Memory, throughput, latency are the things we should be talking about. There’s also trade offs where predictable scaling of latency under massive load is important (Erlang, Elxir), or spending less memory and starting up quickly in order to scale horizontally is important (Golang), or speed of development is important (PHP, Python), or correctness is important (Haskell, Rust). Java is rarely the winner in any area in favor of being well rounded, but as we should be using tools that meet at least the broad requirements it is always possible to make a better choice than Java.
> I’ve seen apps run for years straight.
This is why Java is dated. I am an Erlang developer, which is known for being hot reloadable and running forever. It turns out this model is actually juxitposed to Kubernetes and severless, which both presuppose letting processed crash at the host level and starting and stopping quickly. This also gets into the tooling argument because profiling in Java would rather the VM be long lived.
> The tooling.
I too have an operating system with great tooling, it’s called Linux. My knowledge of tooling is more broadly applicable, I can introspect any binary and attach probes to the kernel with bpf. Profiling for a VM is table stakes because you’re on your own. Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.
> Java OO is fine.
OO in general is not fine.
Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.
Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..
It’s a spectrum. Java is at the very end with Erlang. I have a lot of domain specific knowledge of The Beam. Go on the other hand has a very lightweight runtime.
Very true. Newer languages seem to be moving back towards native binaries. The promised advantages of JIT compilation have faded with improvements to compilers and profile driven optimization.
Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes
> OO in general is not fine.
I smell a zealot or a troll.
Please elaborate on how OO is fine. OO hides state, which makes reasoning about cache, and therefore performance very difficult, which is why most game programers take a data oriented approach. It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Inheritance isn’t an abstraction because you inherit both code and state, which requires explicit knowledge of the intervals of the parent. It’s a code pasting tool. As OO tries to model arbitrary patterns in nature it’s also difficult to reason about the graph of objects apposed to the linear flow of data in FP. Pretty much all of the OO languages are walking back OO features at this point and trying to add type classes (contracts) or functional pieces, mapping and filtering a la linear data transformations.
> It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing.
Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language.
> Pretty much all of the OO languages are walking back OO features
About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually.
> and trying to add type classes (contracts)
In most OO languages, these typically naturally evolve out of interfaces.
> functional pieces, mapping and filtering a la linear data transformations.
This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.
Minor question: what does the word "penultimate" mean in your comment?
I actually agree with you here that OO is overused. Java has added quite a bit of FP in recent years though.
Lombok makes immutable data classes trivial. Improved interface support for default methods make it possible to largely ignore OO if you don't want it.
FP is mostly a community effort at this point, but solid. Java Streams are decent for basic stuff like map/filter but RXJava is extremely powerful if you want the complexity it comes with. Vavr is nice for adding more FP types too
These are actually all fairly common problems so I'm not sure why this is drowned out in gray...
The over-zealous tone may annoy some people. Also, he/she could have gotten the same point across more effectively without implying that Erlang and FP magically solve all problems.
True, class inheritance is so hard to get right that is just better to avoid it. Lots of coupling and spaghetti code because of this, but to be fair, you also see this on other languages, like python, php and even JS.
Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go.
IMO Java is the most well rounded language, but I'm not trying to convince you of that.
Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework.
Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#
Can do higher concurrency is a nonsensical phrase. Please show me your benchmarks versus Erlang at 10M web socket connections.
You’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices.
You’re not understanding what I told you.
Newer versions of Java cache compiled classes. The startup time is maybe 10 seconds for something big running Java 11.
You can also compile AOT for some performance loss at runtime but zero startup time. Android has been doing this forever but you can also do it on a PC using Graal.
And yes Java will destroy Erlang at concurrent connections if you use an async framework like Vert.X or fibers using Quasar/Comsat. It has lower per thread overhead than Erlang and runs code faster in general.
Both Java and Erlang will max out Linux TCP connections before running out of steam so this is kinda academic though
If you want to build systems at scale you want to use a lot of commodity boxes, not a few huge or 'special' machines.
I don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs.
Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about.
You might chose Java because:
* It is well understood and has a lot of mature libraries surrounding it.
* You can easily hire people to work on it.
* It is a stable language.
And so on...
I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow.
[1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.
Serious question: Isn't Java still one of the default languages if you are choosing a "safe" language to build and maintain a large piece of software? Considering how long it's been around and how many libraries exist for it now, i've generally viewed it as a language that's:
- fast enough for most things without a lot of pitfalls/gotchas
- easy enough to read for most developers
- easy enough for most developers to pick up if they've never used it, even if they aren't exactly enthused by the idea of doing so
- supported enough that you'll never be the only person who is debugging something
- widely used enough to never be alone when you are trying to use it in unsupported ways
- has commercial support from multiple companies
Basically all the things that a lot of "enterprise" companies love.
Edit: formatting
> Isn't Java still one of the default languages ?
Yes.
There is no need to engage the GP - let him rant about Go and JS. Java is still huge, for both legacy and new projects.
For context - I started as a C/Kernel dev. I also spent 2 years with Java on mission critical backend code. Both have their uses.
All of those points are also true for C#, which imho fixes a lot of Java's problems and is a much nicer language. With .Net Core maturing you even get the "runs everywhere" factor (at least everywhere you care about, i.e. Win+Linux+Mac), and Microsoft is a much better vendor than Oracle.
As someone that works with both stacks since their inception, there are tons of platforms with Java compilers, where .NET Core isn't even a thing today, and there are tons of .NET libraries that will never leave .NET Framework.
So it isn't like just exchanging one for the other like that.
I'm finding library support quite good for .NET Core tbh. Not perfect, but it's not at all a barrier to adoption.
Try to port any commercial component library to it like Telerik and friends, ODP.NET, WCF, EF 6, Forms, WPF.
.NET Core 3.0 will fix some of the compatibility issues but not all of them, for example EF 6 will only be partially supported (VS DB tooling is not being updated for Core).
Yeah .NET Core 3.0 will address some of that, not all. I suppose for any brownfield development looking at switching across those things are the potential blockers at the moment. Especially things running EF where EF Core doesn't have a particular feature just yet. But EF Core development is cracking on at a good pace.
Telerik and the likes I'm not so fussed about personally. I suppose DevExpress is another one on that list. I think front end component libraries like Prime-ng/PrimeReact are probably the way to go for the future of UI development for Line of Business applications.
Overall I reckon in a couple of years there won't be much of those blockers left at all.
I'm very happy to see .NET Core getting more stable and mainstream (I miss my days of working in C# even though I don't miss Windows) but I think running it on Linux for backend microservices still counts as fairly off-the-beaten-path compared to the safe, "no one ever got fired for doing X" choice of using plain ol' Java.
The problem with C#, which I think is a fine language, is the small(ish) size of the ecosystem and the refusal of the ecosystem to deviate away from non-MS endorsed libraries and frameworks.
It's the ridiculously large JVM ecosystem that makes Java awesome, not the language.
Yeah, I definitely feel this some days. I've just moved over to C# from Java because I'm bearish on Oracle as a vendor in general, I find C# great and impressed with Microsoft's efforts as a vendor with what they've done with .NET Core.
I have love for Java, but I gotta say it mostly is because the ecosystem is pretty fantastic. So much open source stuff for so long means it's all just there and it all just works. There are some gaps though.
.NET ecosystem isn't bad. It's pretty good. There are some phenomenal libraries. But sometimes the gaps are painful. The lack of an open source (read FREE) integration framework is a big one for me. There is BizTalk but that's commercial and probably expensive. Same with scheduling libraries. HangFire looks great but it's paid. A lot of the really high quality stuff you have to shell out for which when you're just hacking in your own time is not feasible. That being said there are open source libraries and some of them aren't bad. Lots of great stuff in general.
You can still have a more modern language i.e. Scala, Kotlin on the JVM whilst not abandoning the unparalleled array of libraries that the Java ecosystem offers.
Completely agree, except that MS was so crazy hostile to OSS that they scared off all the serious guys a decade ago. I wish them the best. The CLR has some compelling features that make it objectively better than JVM on so many levels.
But the lack of ecosystem is killing them. And has been forever. The new MS CEO is great in my mind but it will take many years to turn the ship around. Devs don't forget.
Best example I can think of (was a C# guy for years). Resharper has been around forever. But it costs a lot. This is par the course for C#. I can get the same thing in Java by pulling in a few linters with Maven, and it's all free. Because MS scared away everyone that was afraid of licensing fees (ie most academics, the sharpest devs out there), there's nothing comparable.
Same with C# port of Quartz and so many others. They killed off the real rockstars among us that create the majority of libraries that everyone else uses.
Can it be fixed? I hope so. The CLR is great and Oracle sucks. But for now there's a good reason Java is dominant
Resharper is $139 a year for a personal license and the price goes down 20% after the first year and 40% year after that. You can also pay monthly.
They also have a perpetual license. If you cancel after the first year, you can keep using the version that was current 12 months ago.
But the one thing missing in Java is anything like LINQ. I don’t mean the syntax I am referring to the idea of LINQ -> expression trees -> third party providers that translate LINQ to another language (sql, Mongo Query, etc.).
It's not built in to the language, but JOOQ and QueryDSL come fairly close.
I do miss LINQ though. The Java options are all clunkier because the type system isn't nearly as flexible
I can't tell from looking at the examples, but can I do things like pass around arbitrary expressions:
and have a methodPerson.Get(p => (p.Age > 65 && p.Sex == "M") || (p.Age > 63 && p.Sex == "F"))
and have that expression interpreted correctly at run time by separate providers?public List<Person> Get(Expression<Func<Person,bool>> expression)You get full compile time checking and IDE supported autocomplete.
Yes. But it's done in a different way than C#. C# supports fields and field references so you can pass them directly to a function.
The Java code "looks" like they do the same because they generate code to simulate method references instead. It's pretty clever and Javas code generation support for Annotation Processors is excellent and makes it possible to do this in a cross-ide cross-build-system way
LINQ and JOOQ/QueryDSL all work on plain data objects with fields. But with Java you do it on a pseudo object generated from your existing classes
That's really interesting.
All of these years I've been beating up on Java for lack of something akin to LINQ. I guess I'll have to find something else to complain about.....
IMO LINQ is still better because of how integrated into the language it is. JOOQ and QueryDSL were basically designed to replicate it as much as possible but not nearly to convenience levels of LINQ + Entity Framework
Yes, albeit with noticeably weaker libraries/ecosystem.
I gotta ask what in particular "problems" C# solves over Java, and I'm not talking about J2SE 1.4. Having dipped into C#, it feels like the designers resented OOP and reusable code. C# is not the new kid on the block and is almost 20 years old now.
Over that 20 years, C# has been continuously improved with language features added at a faster rate than Java. Some examples: * properties * LINQ * async/await * dynamic types * better generics * inferred typing - `var` * null conditional operators * custom iterators - `yield` * pattern matching
Also, .net is more of a “pit of success” language — Java with all its legacy baggage requires a lot more knowledge to avoid mistakes.
so... properties that require a steeper learning curve, a system that's worse far worse than JPA+Spring Data (or you could use the hibernate in both languages - a java development), another word for var/let, I'd disagree about generics, var/let again, I wonder what rust devs would say about these null inline conditionals that require more knowledge, and... yield is actually neat if also not another non-traditional baggage thing to learn. Anyhow, I guess my take is that Rust is a better language than C# in all the ways that C# might be better than Java and more... Except that C# is a lot like Java and is the language of choice if you use Unity - so it does have a big awesome ugly library that Java does not have. Really we should feel sorry about all the Unity baggage C# devs get to deal with. Then there's Microsoft land, which has not inspired me of code quality and can't get out of VB think.
Hibernate is an ORM. LINQ is just what the name says it is language integrated query. Linq is understood by the compiler, translated into expression trees at run time and then any third party provider can translate it to the destination language. You can pass Hibernate expressions around and depending on context, they can get translated to regular IL when working with Lists, Sql when working with RDMSs or MongoQuery when working with Mongo, etc.
> it feels like the designers resented OOP and reusable code
Can you give some examples, that wouldn't be equally applicable to Java?
Maybe it's less of a C# thing, and more of a Unity thing - but I'd say that Unity has some major architectural anti-patterns - which may just be to appease the ease of a the awesomeness of a wysiwyg type game engine.
Polymorphism and inheritance by default?
You mean the fact that methods aren't virtual by default?
As Hejlsberg explained, the problem with virtual-by-default is that every time one of your public methods calls another public method on the same object, it makes it that much more complicated to reason about your invariants. If the called method is non-virtual, then you're in full control, and you know exactly what happens. But if it can be overridden, then you need to define a contract for overriders to follow, and you can't assume that it does anything other than what's expressed in that contract (in particular, you can no longer call that method without ensuring that all class invariants hold, even if it's expensive). Furthermore, the overriders often also need to know which other methods on the class do or do not call this method.
In practice, this is so much hassle that not even the Java standard library does that. For example, given ArrayList, if you override add(), does that affect addAll()? The docs don't say. So in practice, the only things that are safe to override is what the docs say are safe to override... which is to say, exactly like "virtual", except it's not enforced by compiler. Overriding random methods often works, but is a hack not dissimilar to using Reflection to access non-public members - even if it works, you're relying on implementation details of the class.
> it's also lost the niches that brought it into existence
Applets, JavaBeans, and CORBA. What a loss.
> Besides being owned by Oracle, which is enough of a reason to never use Java ever again,
That stopped being an issue years ago. OpenJDK is a thing, you know?
> Java on the web is dead,
I don't think you have any idea about the hundreds of millions of lines of Java that power the web as you know it today.
The rest of your post is filled with equally uninformed claims but I'm going to stop here.
> Java on the web is dead,
>> I don't think you have any idea about the hundreds of millions of lines of Java that power the web as you know it today.
Presumably they meant Java in the client, not the server.
"Presumably they meant Java in the client"
Android?
They are talking about his https://en.wikipedia.org/wiki/Java_applet
Which were absolutely everywhere at the turn of century.
So, yeah...if you are only thinking about web applets, which died over 20 years ago, and ignoring Android, which runs on most of the world's phones, I see why you might think "Java is dead."
Thanks to WebAssembly it is back.
The web client specifically
>>> That stopped being an issue years ago. OpenJDK is a thing, you know?
Well, that's seeing the glass half full.
OpenJDK was complete garbage in the java 6-7 era, less than 5 years ago. Pretty much every major java software was requiring to install the Oracle JDK. Nobody would accept a bug or a support issue if it happened with the OpenJDK, which was the first question to be asked. And that wasn't fear mongering, java applications that worked perfectly fine just didn't work on the OpenJDK.
It is better now. I personally haven't seen an OpenJDK JVM crash in a while.
Yeah this was a problem for 6 & 7, but I've run plenty of code in production on OpenJDK 8 without issue. I think Java 8 was the first version where OpenJDK was the reference implementation so that likely helped a great deal.
That stopped being an issue years ago. OpenJDK is a thing, you know?
If Oracle's ridiculous interpretation of API copyrights holds up, they have a kill switch for OpenJDK.
Just like Google's ridiculous interpretation of the licenses of others being worthless.
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
I liked CORBA! I'll take it over whatever lackadaisical JSON silliness we have today.
Amen. Its a sad state of affairs when the middleware we had 25 years ago was faster and more robust that what we have now.
Java on the web is a reference to applets running in the browser.
Yes, Oracle, the company that sues people for breathing the same air owning Java is an issue.
Maybe I am uninformed, but you haven't made a good case that there's any truth to that.
Do you know anything about Java? I'm not trying to be insulting. Java has its problems, but your points are so far off the mark. Applets haven't been a thing for 20 years and I'm not sure they were a thing then either. Do you know people make web apps in Java and there's a ton of quality open source libraries out there?
I developed Java (Swing, Spring, JavaFX), managed tomcat deployments, good stuff.
I think my question is, do most Java developers really know what goes outside of their window? Every language has a good story for web apps these days. The web is ubiquitous. You can write in Phoenix, Cowboy, Rails, Sinatra, Express, "net/http", Django, Laravel, Flask, Rocket... Java is literally middle of the pack at best. So that's not a compelling reason to use Java. So then we have to look at the rest of Java. Is there anything else in there that would make it better for web dev than a simple Go/Ruby/Python/Javascript/Rust/Elixir app? No? Ok, then let's not use Java. Java excels at being mediocre at everything, but the best at nothing.
We rather enjoy the state of the art IDEs, JIT and GC compilers from Java and .NET, while slowly enjoying watching hipster startups rewrite their stacks when customers come flooding in.
Ask Twitter how their Rails apps is holding on.
> Java is literally middle of the pack at best
A warm JVM is faster than a greased millenium falcon.
Worked on a project to replace all Applets in a large enterprise product just a couple of years ago.
There is a lot of software running in this world. Some of it is very long lived.
Oracle owns the Java name and its implementation.
Other open implementations exist from Amazon, IBM, Microsoft, Zuul etc. And they are all using the JDK name which isn't owned by Oracle.
If Oracle were to die or become aggressive the Java ecosystem would just move on and not skip a beat.
Our company (on the scale of running it's own private cloud) has switched over to OpenJDK. Oracle is a non-issue for us
For people actually working with JVM and the languages on top of it, nobody really is worried about Oracle. The way the licensing is set up, they just don't have enough power to coerce people to use their version. It would kind of be like the SCO case if they came after it. I think they went after Google for Android simply to protect their IP, and that one they even "lost" (which detracts also from their possible future lawsuit on enforcing Java licensing)
As a believe in free and open source software, I think this is a very head in the sand approach. Any portion of Java, even if it's just a certification being open source is enough to run away from it when there are so many alternatives that are better languages and completely open source.
OpenJDK is GPLv2. I know of only a handful of other, popular languages with a license as copyleft as that.
So far I did not find anything comparable to replace Java for website server language. Go is a terrible extremely verbose language without vital features. JavaScript on Node is limited by single-thread and JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby). Rust is awesome, but I don't think that it'll be ever usable for mediocre developers, therefore it can't be a safe choice for ordinary project.
The only reasonable alternative is C#. But it has to go a long way to reach Java's level of stability and trust on non-Windows servers.
LASR 14 hours ago [dead] [-]
> JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby)
You know, I used to think that languages had a single axis of Good. And each language sat at a certain point in that one dimension.
After several years each of experience writing large web applications using C++, Java, C#, JS, Python, Ruby and Go, that mental model of languages being good, bad or terrible seems incredibly naive now.
But overall, if someone were to ask me to write a web app today, I would probably use Python server-side and break it down into microservices. Client-side, probably just pure js + HTML5 APIs.
Why? Because I don't have the time to argue about languages being better or worse. I am too busy writing code that does useful things.
In a high-skill rockstar team, dev time is by far the most expensive resource. In a startup environment, using your dev time wisely is the difference between a unicorn and a failed business. Nobody gives a fuck if your route handler executes in 1ms or 20ms. I'll gladly pay the 20x hosting costs if that will get my feature out to customers a week earlier.
i don't know why this comment was downvoted so much. i fully agree with every point that LASR makes. if you disagree, i'd like to see your counterpoints please.
Assuming you meant specifically the Java language, Kotlin for JVM may also be a good option. Solid set of language features that puts it at least on par with C#, and allows you to write more DRY code than you can with Java language. As with any JVM language, you get all the benefits of the JVM. IDE support is great (at least with IntelliJ IDEA). It's an officially supported Android development language, putting it further into the mainstream. Also, as with other non-Java JVM languages, releases are not tied to JVM releases (I still use Java 8 for my Kotlin projects, while using the latest Kotlin version).
For browser or Node.js, TypeScript is the way to go IMHO. Node.js and it's ecosystem have it's issues, but TypeScript is quite nice and a considerable improvement over JavaScript, while being close enough to JS where it fits nicely into the ecosystem. Only downside is that it adds a compile step that can potentially grow to be time-consuming.
Yeah, I mean all Java ecosystem and I, personally, prefer Kotlin too.
Kotlin is a drop in replacement for Java these days. I've switched a few projects now and mix Java and Kotlin during the transition. IMHO Kotlin is a breath of fresh air if you are coming from either Javascript or Java. Typescript is close but it is still javascript and it has a few inherent limitations because of that. Kotlin-js is basically a dropin replacement for that as well.
Bit of a Go fan here so just wondered if you'd qualify what you mean by: > without vital features
Beating a dead horse here - but Streams and Generics are now what I personally consider vital features. Code is much more compact and elegant with the proper application of these two features.
Error handling via exceptions and generics are things that I can't live without. Go moves in that direction, as far as I understand, generics are expected in the next versions of Go and error handling somewhat improved, so may be it'll be good enough after few years, but I just can't write current Go after Java, it's like running with chained legs.
Other than what the other posters mentioned, you have things like annotations in Java that allow for cool features such as validation and constraints, and auto translation between types. This is extremely verbose and error prone in golang because no such mechanism exists.
Vital features is double speak for any Java feature that isn’t in Go.
It's fascinating reading a post like this because I feel exactly the same from the opposite perspective.
I feel bad for people trying to write in other languages and manually re-inventing dozens of features the JVM ecosystem just gives you for free. In many ways, the whole container-push has been essentially people trying to achieve what the JVM already gave you (isolation, cross platform, etc etc). I still don't see anything equivalent that doesn't impose huge burdens of complexity (which java does have but it's a known quantity with two decades of maturity).
> the whole container-push has been essentially people trying to achieve what the JVM already gave you (isolation, cross platform, etc etc)
Google did containers in Borg many years ago, and many of its servers are written in Java.
Yep, WAR and EAR files with J2EE servers.
When I stopped caring about POSIX.
That's how much people hated writing Java. Also, Erlang would like to have a word with you.
> That's how much people hated writing Java.
or, they are more concerned with shiny new tech rather than using a mature and well-tooled out stack that doesn't sound sexy. I for one, don't need sexy tech - i want my app's domain to be the shining star, not the tech stack.
I'm using Java every day to deliver software that works to people who want solutions to their problems. It's interesting and enjoyable. No need to feel bad for me or any of the other folks happily solving real world problems in Java!
The Java Platform is state-of-the-art in compilation technology, GC, and monitoring/management; nothing else comes close on almost any one of those, and certainly not on all of them combined. The alternatives you mentioned are all "good enough" for some use cases, but are technologically years behind the JVM. Some people are fine driving a Hyundai, but others want to drive a Ferrari. Besides, if you need to write some serious software that has to be performant and manageable and that you're going to need to depend on for years and years, there really aren't that many alternatives. That's why Amazon and Netflix and Google and Apple and Twitter choose Java to run all/most/many of their backend. Such large companies tend to use Java more on new projects as they grow (that's the case with Facebook and GitHub).
It is true that for smaller, less demanding software, there are many alternatives, but except for a very short period (~2000-2005) Java never dominated that kind of software. Early on people used VB, FoxPro and Delphi for that stuff, and later PHP, Python and Node.
There's definitely alot of 'enterprisey' java code out there but that has more to do with the way people code than the language is now. Functional programming(.sort, .map etc) introduced in Java 8 allows more concise code and less boilerplate.
Even with Rust, Go, and .Net core out there it's really hard to beat Java's battletested libraries/frameworks and excellent tooling. Java is still very relevent today and will probably still be for a very long time.
Battle tested and tooling really aren't compelling arguments anymore, Java is very middle of the pack in both regards. Go is running as the basis of the next generation infrastructure in Kubernetes, Prometheus, Docker, Terraform... Elixir has revived Erlang, which now has great tooling in mix and is well known for being highly reliable. Go, Javascript, and Rust all have real package managers (even Go with mod) that are bundled with the language and come with auto formatters, vetting tools, etc.
Also, funcitonal programming is a style of programming, not a collection of features. Just because you have a map and sort method and a hacked in lambda syntax doesn't make Java anything less than OO. Multi-Paradigm usually means one paradigm with a bunch of extra crap in there to make bike shedding easier.
If you're really that much of a language snob then you should checkout kotlin. It has seamless integration with Java and has the _best_ ergonomics I've encountered language wise.
Go can't even get it's packaging story straight and once again doesn't have generics which makes 'functional' programming a no Go;)
Generics have nothing to do with functional programming.
I actually really like Clojure (really I just love Lisp).
Go also has modules now.
Pervasive use of HOFs is kinda difficult without generics or some equivalent.
> Just because you have a map and sort method and a hacked in lambda syntax doesn't make Java anything less than OO.
Maybe not fully functional programming, but something that's quite pleasant to work with to be sure.
> Go is running as the basis of the next generation infrastructure in Kubernetes
And it requires acres and acres of generated code, a custom runtime dynamic type system, whacky module names for compatibility instead of a reliable build system like maven, to make the thing work at all. Kubernets is a multi-megaSLOC advertisement for the virtues of Java as an ergonomic experience.
If it had remained in Java it could be incrementally ported to Kotlin. God, what I wouldn't give for that.
That's an impressive rant and can't disagree with some of it, but you're nearly a decade behind in your assessment of java in the Enterprise. New deployments of EJB apps have dropped precipitously (never should have existed), and Java still enjoys wide Enterprise use.
Part of the reason big businesses were able to abuse enterprises with their abominable Java server stacks is because corporations were slow to trust open source. But developers persisted and open source became too compelling to ignore, creating the upward pressure to embrace it and break the bloated and overpriced enterprise app server's stranglehold. This likely prevented the demise of Java that you suggest has happened.
In fact, when it comes to enterprise these days, you're pretty much either a Java or a .NET shop.
The large majority of enterprises I work with use both, depending on the use case.
The Java ecosystem is still there and still rich. It didn't go away or stop growing because golang was released.
You'd rather use wasm to write c to talk to javascript apis? Your case against Java might be more compelling if it wasn't so gross itself.
You're only rich if everyone else is poorer than you. At the point Golang, Javascript, Ruby, and Python (these are just the ones I use) have huge completely open source ecosystems. Java's ecosystem is no longer a convincing argument that we should ignore everything else about the language and it's place in the current line up.
No, they are all rich. But I would really hesitate to compare java to js, python, ruby, etc. They aren't as interchangeable.
I use all those languages too. Use the right tool for the job. Don't be dogmatic. And don't disparage others.
Would I start a new project in Java? Probably not. But I might reach for other jvm languages that were mentioned elsewhere. I'm definitely not too cool to work on an existing Java project. It's fine.
Don't conclude that someone is being dogmatic without compelling arguments. Java is a technology, it's ok for it to be superseded by changes in the landscape. I also never said that people should stop using Java, I simply said I felt bad for the people that had to work with it given that it's obsoleted by improvements in sandboxing, package management, and language design.
This seems a bit uncharitable.
I still use Java a lot for application servers[1] and enjoy it.
I've also used Go, but I wouldn't want to try and implement, say a non trivial REST server with it.
I don't have the time to code everything from scratch, or to use an immature Go library or framework for example, when there are perfectly good ones in the Java world.[2]
Perhaps it might be best to just see languages as tools, and that each language has a purpose.
Java is old, so what? Lots of people derive value from it, and it's very stable.
You might be glad that banks use it, instead of immediately jumping on whatever languages you mentioned above. At least it manages to do boring things like keep you accounts relatively safe from hackers.
[1] https://www.dropwizard.io/1.3.9/docs/
[2] And yes, for that kind of application, unchecked exceptions are way more convenient than thousands of lines of if err != nil all over the place. And annotations in Go are an afterthought and it shows.
The JVM powers Kotlin, Scala, and Clojure, which are all as sexy as golang.
way sexier actually
Why use a meaty framework like Swing
I'd suggest updating your misconceptions regarding Java before posting Yet Another Tirade about it.
E.g. the Javascript module/npm ecosystem is an absolute mess compared to any sane package/project description system, yet few people would disqualify JS for it.
>I understand why Java has to keep on chugging along, but I feel bad for the people that have to be a part of it. It's like watching people keep coal trains going while people are moving to cars.
Yeah, those poor devs with a rock solid, best of class, platform to write code on, with tons of libraries and tooling.
>Java no longer runs everywhere
It still runs everywhere where it matters. Nobody really cared if it could run on crappy smart tvs and other such BS SUN tried to push it. 99% of Java use has been for server work and enterprise development, and it remains there.
And on mobile, well, Android uses basically Java with a name-change.
>Java on the web is dead
Java on the web (Applets) was DOA, and has been dead for over 15 years. It's not gonna make any difference now.
>and you can now write ubiquitous apps in basically every language
Which again is neither here, nor there. People have been using Java as a very strong language for backend systems, application server side work, and enterprise stuff. And those deploy on at most one OS 99% of the time.
They don't use Java like e.g. Electron or QT. The only Java apps that are like that and are mainstream are basically IDEs.
>There's no reason to deal with the JVM and it's domain knowledge when you can write a nimble Go app for your backend and a Javascript app that will run on mobile, web, or desktop
Whatever.
>A VM language? You mean v8 sandboxing and web workers; WASM which lets me write C, C++, and Rust all of which can talk to Javascript APIs
How hipster. Meanwhile others do real work on Java, with finetuned GCs, mature libraries, and so on. I'm not sure where you've seen all this "WASM and Rust", as both are not even blips in production compared to Java adoption -- and wont be for a while, if ever.
>All of my services are stateless and ephemeral
Mine don't care much for the latest fads, so there's that.
>On the cloud it gets even worse for Java. Why use a meaty framework like Swing when I want to just spin up a bunch of micro services, or have an API gateway kickoff a bunch of lambda jobs.
I'm not ever sure what Swing has to do with a Cloud java deployment. Perhaps you meant Spring, but even so, it doesn't make sense.
And of course with Java you can always use something like Vert.x, which tops the performance charts for microservice work -- so much so, that the others are not even on the radar.
>Java also took OO in so many terrible directions.
2010 called, they want their arguments back.
Also, not sure if you've noticed, but Java is still in the top 3 of most in demand languages (along with JS and Python).
Perhaps your ideas about its death are premature, if not deluded?
> Whatever.
You have me convinced.
Well, for better counter-arguments you first need better arguments.
(And of course you skipped all the non-whatever points where you didn't have anything to respond).
We should print out copies of this comment, and laminate them, and give them to anyone who thinks that comments on HN are good, as an educational resource.
Limiting personal freedom is what the enterprise Java ecosystem is all about.
This is why people are calling you a zealot.
I think you meant Spring, not Swing, when talking about cloud frameworks.
And from this it seems to me you are somehow biased against the java ecosystem without hands-on experience to base your opinions on.
Edited, it was a slip of the tongue.
> Java also took OO in so many terrible directions
Java basically copied (and cleaned up a bit) C++ OOP of the time. Don't blame Java for any bad direction, it was following rather than leading.
I blame them both. No I don't really, there's historical context there, I only blame people who continue to push OO after 2020.
There are a huge number of Java programmers who know very little if anything outside of it, who've geared their entire careers towards learning the Java ecosystem and don't want to learn anything else.
There are also thousands of companies which are focused on Java, Java, and more Java. Many schools are also geared towards churning out more Java engineers, and people who don't yet know Java want to learn it because there are still so many Java jobs around.
That's a lot of inertia to overcome.
Maybe this is where Kotlin fits in.
Im loving it, i analyze and fix issues across a lot of platforms and languages and for me java is probably the least troublesome of them all. you will see a lot of good practices and standards established that when trouble hits which i find rarer in java its usally also easy to deal with. Not gonna mention other names but i find the practices and maturity of a lot of more hip languages lacking a lot still.
Two things (among many) you will be missing when targeting WASM vs JVM: Garbage collection and mature profiling tools. Each of these is bigger than many language features in my experience for writing production software. I would gladly write Java 1.0 if it was the only way I could have them. But in fact I can choose anything from Scala to clojure.
"One day Java will be like Cobol." I heard that one two decades ago about Java.
Two decades ago, Java was 3 years old.
It's still true, though, but it's a compliment. Most languages have no hope of ever becoming the next COBOL. For Java, it is practically a certainty, even if Oracle were to pull the plug on it this very moment. It's too big and too important to die.
I wanted to ask him how he felt about UNIX
Well I wish predicting future is this easy , as of now the place where I work we use lot of spring (Spring cloud) completly microservice and it is only reason I believe java is still alive. Spring makes things lot more easy for us atleast. But I have to agree with you regarding Oracle May be you will be interested in this article https://spring.io/blog/2019/03/07/has-there-ever-been-a-bett...
Ironicaly I'm the other way around. Java is a pretty good platform, save the GC pauses.
However I really dont see what benefits Spring brings. Spring Boot is great for prototyping and trivial apps, but for big systems you really want to break it apart. DI is better done with ServiceLocators. Some of the smaller libraries like Spring Shell, Spring Mobile are junk. And I still see lots of XML config that you dont know if they'll fail until you try to run them.
I am not sure what else are you looking for, Spring boot/cloud has pretty much all you need to build any application.
I know Spring and Spring boot are very popular, but I don't understand why. The Spring Boot home page says, "Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run"."
What does that mean? What does Spring Boot give me that Tomcat doesn't?
What code are you writing that Tomcat runs? Are you coding against the servlet spec? Or are you using something like dropwizard?
Tomcat is a servlet container that implements various Java EE specifications, such as the servlet spec, jsp spec, etc.
Spring encompasses many different libraries. The most widely used is probably Spring MVC, which builds on top of the servlet spec to make building web applications easier. After that Spring Security is probably most widely used, which adds things like auth, CSRF tokens, etc. Spring Data and Spring Cloud are also somewhat popular. There are many more Spring libraries, but I have little to no experience with them.
You can really give or take what you want here. You can use Spring MVC with Spring Data, or Hibernate, or JPA, JDBC, or whatever you want really. One place I worked used Spring MVC with home grown security and ORM layer.
Spring Boot brings "convention over configuration" to Spring. Because Spring is so configurable it can take a lot of boilerplate. Spring Boot removes much of that boilerplate for certain use cases and has, generally speaking, more user friendly defaults.
Spring Boot also runs off a server embedded in the jar. That's why you can "just run" it. You create a "Main" method. You can choose from several embedded servers, including Tomcat. But this isn't exactly special for Spring Boot because you could do this even if you didn't use Spring Boot.
Thanks - that's a good overview :)
Most of my apps just code against the servlet spec with a JDBC connection to a MYSQL database, sometimes with JSP. Perhaps because most of my business logic lives on the client I've usually found that plain servlets + plain JDBC calls were sufficient
Although I've found it pretty straightforward to configure servlets in Tomcat I can see that Spring MVC makes it a little easier. Maybe the introduction of a framework 'Model' is also an advantage - I'll investigate further.
Regarding Spring security - would I use this package if I was implementing a "Login with Email/Password or Facebook or Google" feature to a website?
One nice thing about Spring Boot is that you can mix and match. You can assemble stuff very quickly using the starters, or you can use your own stuff. Pretty much any level of abstraction is supported -- Spring Data spans the range from "thin convenience wrapper over JDBC" (JDBCTemplate) to "completely autogenerated RESTful endpoints based on JPA models" (Spring Data REST). In web land you can use raw servlets up to fully-dressed domain objects. Whatever you want, Spring can either fill in the gap or politely yield the floor.
Not forgetting that dependency injection -- the original core feature -- is just the bee's knees.
I work for Pivotal, but not on Spring. But I've definitely grown to appreciate it more and more over the years. I deeply miss it when mucking about in Golang.
I only need to run a few different applications and they require very little boilerplate to get this to work. Spring just gets in the way and makes simple things complicated.
"Spring Boot is great for prototyping and trivial apps, but for big systems you really want to break it apart."
Any practical advice for making this happen? I have a Spring Boot system I wrote and am responsible for, but now I just want the pain to stop.
You need to take the library approach. It's much like react vs angular. With angular, and spring, you get a ton out of the box but much is mediocre.
Like React, you can out together your own "best of breed" java stack. It just takes a lot more work.
Look to replace one component at a time. For DI Guice or Dagger2. For REST Vert.X or Jersey. Logging Logback. Metrics, DropWizard Metrics. OAuth ScribeJava. Hibernate for Spring Data.
Take a look at the "awesome java" repos and choose your poison.
I'll warn you now that while you can end up with something far better you lose the coherency of Spring. Of your organization doesn't have a good "apprentice" setup all the new devs will be utterly and hopelessly lost. And good luck finding a Dev that knows 20+ libraries vs "Spring".
Rolling the libs was worth it for us but probably not a lot of eng orgs
If you're just looking for a drop-in Spring replacement you can't go wrong with DropWizard. It's a solid combo of best-of-breed libraries and has quiet support/adoption by many huge companies
You know, libraries. Java as a language is pretty bad but the number of good libraries available is insane. You are not coming anywhere near with other languages with this. Also, many of the big data stack applications have Java as a primary language so the libraries are pusblished as Java libs first. As it was several times on HN people do not only chose languages they chose ecosystems.
As the world around Java advances, people need libraries for different things. The question is, of all those libraries, how many of them do I actually need, which ones are maintained, and is it worth the cost of Java. Many languages, like Go, have first class seat in cross platform cloud and containerization that is hard to beat.
Though I also have sympathy for those stuck in it, I kind of wish it would die just so I didn't have to be afraid anymore that I'd one day get stuck with having to use it after a sad sequence of bad luck ending with having to take a job in desperation.