4 ms·

Growing the Java Language [video]

73 points by JackFr 1y ago

sgt 1y ago
This is great, should we all rush back towards Java to build our startups on?
- ludovicianul 1y ago
  Yes :)
- winrid 1y ago
  Quarkus and Vaadin is pretty productive.
  - p2detar 1y ago
    I don't know. I still find Vaadin's pricing way over what I could spend on a startup project. But it could just be me. edit: People also forget that Eclipse RAP still exists and although it's probably not that "modern", it works. https://eclipse.dev/rap https://eclipse.dev/rap
    - fredu81 1y ago
      The vast majority of people don't pay anything for Vaadin as it's Apache 2 licensed. Out of curiosity: Why do you feel you have to spend on it – is it some part of the tooling or are the support alternatives the reason? (I work for the company behind Vaadin, thus honestly curious).
      - p2detar 1y ago
        AFAIR, it was the "Grid Pro" and "Dashboard" features that were needed, but they were out of budget for our infant phase of the product and we went with React. It was a long time ago anyway, I last worked with Vaadin 7. I will however say, that I really enjoyed working with it at that time.
        sebak82 1y ago
        If you used React back then, what do you miss from the Vaadin world and what was easier in React in comparison ? Have you tried one of the latest versions? Disclaimer: I work for Vaadin.
    - winrid 1y ago
      I can't imagine seriously showing RAP to a CEO and saying we're using that. I don't pay for Vaadin, you don't need to unless you want the extra components, and even if you do it's affordable, much cheaper than building the same system in React.
  - kitd 1y ago
    Quarkus is just a little too much like magic for me. Too many annotations hides what's going on underneath, which makes me feel a bit uncomfortable. But I'll accept that's probably just me. Vertx on the other hand, which it is built on and which itself builds on Netty, is excellent, and very performant for typical backend services. It now has support for virtual threads too.
    - vram22 1y ago
      >Vertx on the other hand, which it is built on and which itself builds on Netty What does the highlighted part above mean? I know what Netty is, but did not understand that phrase above,
      - kitd 1y ago
        Vertx uses Netty as the event loop handler for concurrent IO. Vertx adds a simplified asynchronous API on top of Netty (whose API can be pretty complicated), making backend services that need to handle large numbers of concurrent connections easy to implement. HTH
    - winrid 1y ago
      Please DO NOT build a large application on raw Vertx. Quarkus gives you things like auto generated openapi specs etc. Quarkus is just compile time stuff around vertx, and you write simple synchronous code. Again, DO NOT use vertx directly for building APIs. It'd be like using just expressjs and writing your api specs manually... in 2025...
      - kitd 1y ago
        No capitals needed. I have written many backend services around raw Vertx very successfully. It's simple, well documented and predictable, mainly because everything is done in code. Deviating from Quarkus's standard behaviour was comparatively difficult, either tracking down the correct configuration properties and what to change them to, or which api to implement and override and what it needs to do. I prefer to develop OpenAPI specs separately from the code too, mainly because it's a joint effort with other teams. Vertx can incorporate them easily.
  - mands 1y ago
    Modern Java (21+), Spring Boot backend, and Vaadin Hilla (https://vaadin.com/hilla https://vaadin.com/hilla) frontend is a great startup combo
- vbezhenar 1y ago
  I'm concerned about Spring Framework shenanigans. It's under Broadcom now, which feels like a dangerous steward. Just few weeks ago Broadcom discontinued newly acquired bitnami images. It's hard to imagine Java without Spring, everyone uses Spring.
  - guidedlight 1y ago
    Broadcom just want to milk corporates. That is their business model. I’m sure they will commercialise the Spring framework and force fragmentation. Not unlike what happened to Java and Docker.
seunosewa 1y ago
Getting rid of checked exceptions would be very beneficial for Java's popularity. No modern JVM language has kept that annoying feature. Just stop checking them at compile time, or make it an optional feature.
- Defletter 1y ago
  Checked exceptions are not the problem. In fact, I don't think there should be ANY unchecked exceptions outside of OOM and other JVM exceptions. I will die on this hill. The actual problem is that handling exceptions in Java is obnoxious and verbose. I cannot stress enough how bad it feels going from Zig back to Java, error-handling wise. If Java had Zig-style inline catching, there wouldn't nearly be as much humming and hawing over checked exceptions.
  - xmodem 1y ago
    A hot take I have is that Java's checked exceptions - which everyone hates - are semantically very similar to Rust's Result<T, E> and ? error handling - which is broadly liked. The syntax makes or breaks the feature.
    - lock1 1y ago
      It shares the same important property (short-circuiting, explicit & type checkable) with Rust's `Result<>`, yes. I don't think it's a direct equivalent though - Java's exception creates stack trace by default - Type erasure which prevents you from doing anything "fancy" with try-catch + generic's type parameter - You can only throw something that extends `Throwable` rather than any type `E` - etc But yeah sure, if Java somehow provided a standard interface & an associated operator like Rust's Try trait to handle checked exception, it would probably have a much better reputation than it has now.
    - redditor98654 1y ago
      A while ago, I had attempted to do it the Rust style with a Result type in Java (where it is called Data oriented programming) and the result is not great. I was fighting a losing battle in a naive attempt to replace checked exceptions but still retain compile time type safety. https://www.reddit.com/r/java/s/AbjDEo6orq https://www.reddit.com/r/java/s/AbjDEo6orq
augustl 1y ago
Kotlin is a much better Java so that's what we use :) I have a friend who maintains a gazillion JVM based apps for the Norwegian tax authorities and he's a Kotlin skeptic. He's pretty tired of maintaining and porting various small apps and microservices from arcane old and discarded Scala web frameworks etc. Given how locked-in Kotlin is to a single company, I kind of get his skepticism.
- gorset 1y ago
  I think the «best practices» found in Java enterprise has meant that a lot of people think all Java has to look like that. High performance Java is awesome and can be competitive with C++ and Rust for non trivial systems, thanks to much better development cycle, debugging and high quality libraries. Most the benefits is the JVM, so Kotlin has those too, but I don’t feel Kotlin is enough of an improvement to warrant the downsides (at least for me). But both Kotlin, Scala and Clojure are great for the Java ecosystem.
  - deleted 1y ago
    [deleted]
- jillesvangurp 1y ago
  Java is controlled by Oracle. It's not that different from Kotlin in that respect. Go is controlled by Google. Swift is controlled by Apple. Typescript, C#, F#, VB, etc. are Microsoft controlled things. It's not like the grass is that much greener next door. I don't think these things are show stoppers. A lot of this stuff is open source after all. Jetbrains considered using Scala before they created Kotlin. I think they were right. With Kotlin they went for a bit more conservative approach. Mainly undoing things that aren't so great in Java language and unlikely to change for language compatibility reasons, and avoiding some of the pitfalls with Scala. I think Scala saw a bit of wild growth of features and frameworks that Kotlin largely avoided. For better or worse, there has been a bit of a Scala diaspora with people flocking to things like Rust, Elixir, and indeed some to Kotlin. Weather people like it or not, Kotlin plays very nice with existing Java code bases. By design. It was designed as a drop in replacement. It's why it caught on with Android developers before it even was released. It's a bit different from Scala in that respect, which while it worked alright with Java code bases really nudged you away from that to the point where you'd be swapping out your build tools, frameworks, etc. At this point Kotlin is arguably a better language to use with any of the popular Java frameworks. I'm not really aware of any exceptions to this. Spring is a good example (arguably the most popular server framework for Java and the JVM). IMHO you are missing out if you are not using that with Kotlin. The Spring people certainly seem to agree. They've invested lots of time and effort to make Kotlin a first class citizen in the ecosystem. Documentation is dual Kotlin/Java, the framework ships with lots of extension functions for Kotlin and Kotlin specific features, and expanded Kotlin support is one of the headline features for the upcoming major version. And it's not like the previous version was particularly lacking on that front. They've been supporting the Kotlin ecosystem for many years now.
elric 1y ago
Brian Goetz mentions Guy Steele's 1998 lecture "Growing a language" [1]. It's worth a watch if you haven't watched it yet. It's been discussed on HN several times [2]. Java gets a lot of flack in these parts, mostly by people who don't use Java and pull opinions out of their arse, but you'd be hard pressed watching both talks and not being impressed by the effort that's going into continuously improving the language. [1] https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 [2] https://hn.algolia.com/?q=growing+a+language https://hn.algolia.com/?q=growing+a+language
- gorset 1y ago
  I enjoyed both talks a lot. I really appreciate the work done to evolve Java. They seem to be able to both fix earlier mistakes (and there were many!) and new ones from happening. While I see other languages struggling with the weight of complexity added over time, Java seems to get simpler and easier even with significant updates to the language spec.

73 points by JackFr 1y ago

sgt 1y ago

This is great, should we all rush back towards Java to build our startups on?

ludovicianul 1y ago
Yes :)
winrid 1y ago
Quarkus and Vaadin is pretty productive.
- p2detar 1y ago
  I don't know. I still find Vaadin's pricing way over what I could spend on a startup project. But it could just be me. edit: People also forget that Eclipse RAP still exists and although it's probably not that "modern", it works. https://eclipse.dev/rap https://eclipse.dev/rap
  - fredu81 1y ago
    The vast majority of people don't pay anything for Vaadin as it's Apache 2 licensed. Out of curiosity: Why do you feel you have to spend on it – is it some part of the tooling or are the support alternatives the reason? (I work for the company behind Vaadin, thus honestly curious).
    - p2detar 1y ago
      AFAIR, it was the "Grid Pro" and "Dashboard" features that were needed, but they were out of budget for our infant phase of the product and we went with React. It was a long time ago anyway, I last worked with Vaadin 7. I will however say, that I really enjoyed working with it at that time.
      - sebak82 1y ago
        If you used React back then, what do you miss from the Vaadin world and what was easier in React in comparison ? Have you tried one of the latest versions? Disclaimer: I work for Vaadin.
  - winrid 1y ago
    I can't imagine seriously showing RAP to a CEO and saying we're using that. I don't pay for Vaadin, you don't need to unless you want the extra components, and even if you do it's affordable, much cheaper than building the same system in React.
- kitd 1y ago
  Quarkus is just a little too much like magic for me. Too many annotations hides what's going on underneath, which makes me feel a bit uncomfortable. But I'll accept that's probably just me. Vertx on the other hand, which it is built on and which itself builds on Netty, is excellent, and very performant for typical backend services. It now has support for virtual threads too.
  - vram22 1y ago
    >Vertx on the other hand, which it is built on and which itself builds on Netty What does the highlighted part above mean? I know what Netty is, but did not understand that phrase above,
    - kitd 1y ago
      Vertx uses Netty as the event loop handler for concurrent IO. Vertx adds a simplified asynchronous API on top of Netty (whose API can be pretty complicated), making backend services that need to handle large numbers of concurrent connections easy to implement. HTH
  - winrid 1y ago
    Please DO NOT build a large application on raw Vertx. Quarkus gives you things like auto generated openapi specs etc. Quarkus is just compile time stuff around vertx, and you write simple synchronous code. Again, DO NOT use vertx directly for building APIs. It'd be like using just expressjs and writing your api specs manually... in 2025...
    - kitd 1y ago
      No capitals needed. I have written many backend services around raw Vertx very successfully. It's simple, well documented and predictable, mainly because everything is done in code. Deviating from Quarkus's standard behaviour was comparatively difficult, either tracking down the correct configuration properties and what to change them to, or which api to implement and override and what it needs to do. I prefer to develop OpenAPI specs separately from the code too, mainly because it's a joint effort with other teams. Vertx can incorporate them easily.
- mands 1y ago
  Modern Java (21+), Spring Boot backend, and Vaadin Hilla (https://vaadin.com/hilla https://vaadin.com/hilla) frontend is a great startup combo
vbezhenar 1y ago
I'm concerned about Spring Framework shenanigans. It's under Broadcom now, which feels like a dangerous steward. Just few weeks ago Broadcom discontinued newly acquired bitnami images. It's hard to imagine Java without Spring, everyone uses Spring.
- guidedlight 1y ago
  Broadcom just want to milk corporates. That is their business model. I’m sure they will commercialise the Spring framework and force fragmentation. Not unlike what happened to Java and Docker.

seunosewa 1y ago

Getting rid of checked exceptions would be very beneficial for Java's popularity. No modern JVM language has kept that annoying feature. Just stop checking them at compile time, or make it an optional feature.

Defletter 1y ago
Checked exceptions are not the problem. In fact, I don't think there should be ANY unchecked exceptions outside of OOM and other JVM exceptions. I will die on this hill. The actual problem is that handling exceptions in Java is obnoxious and verbose. I cannot stress enough how bad it feels going from Zig back to Java, error-handling wise. If Java had Zig-style inline catching, there wouldn't nearly be as much humming and hawing over checked exceptions.
- xmodem 1y ago
  A hot take I have is that Java's checked exceptions - which everyone hates - are semantically very similar to Rust's Result<T, E> and ? error handling - which is broadly liked. The syntax makes or breaks the feature.
  - lock1 1y ago
    It shares the same important property (short-circuiting, explicit & type checkable) with Rust's `Result<>`, yes. I don't think it's a direct equivalent though - Java's exception creates stack trace by default - Type erasure which prevents you from doing anything "fancy" with try-catch + generic's type parameter - You can only throw something that extends `Throwable` rather than any type `E` - etc But yeah sure, if Java somehow provided a standard interface & an associated operator like Rust's Try trait to handle checked exception, it would probably have a much better reputation than it has now.
  - redditor98654 1y ago
    A while ago, I had attempted to do it the Rust style with a Result type in Java (where it is called Data oriented programming) and the result is not great. I was fighting a losing battle in a naive attempt to replace checked exceptions but still retain compile time type safety. https://www.reddit.com/r/java/s/AbjDEo6orq https://www.reddit.com/r/java/s/AbjDEo6orq

augustl 1y ago

Kotlin is a much better Java so that's what we use :) I have a friend who maintains a gazillion JVM based apps for the Norwegian tax authorities and he's a Kotlin skeptic. He's pretty tired of maintaining and porting various small apps and microservices from arcane old and discarded Scala web frameworks etc. Given how locked-in Kotlin is to a single company, I kind of get his skepticism.

gorset 1y ago
I think the «best practices» found in Java enterprise has meant that a lot of people think all Java has to look like that. High performance Java is awesome and can be competitive with C++ and Rust for non trivial systems, thanks to much better development cycle, debugging and high quality libraries. Most the benefits is the JVM, so Kotlin has those too, but I don’t feel Kotlin is enough of an improvement to warrant the downsides (at least for me). But both Kotlin, Scala and Clojure are great for the Java ecosystem.
- deleted 1y ago
  [deleted]
jillesvangurp 1y ago
Java is controlled by Oracle. It's not that different from Kotlin in that respect. Go is controlled by Google. Swift is controlled by Apple. Typescript, C#, F#, VB, etc. are Microsoft controlled things. It's not like the grass is that much greener next door. I don't think these things are show stoppers. A lot of this stuff is open source after all. Jetbrains considered using Scala before they created Kotlin. I think they were right. With Kotlin they went for a bit more conservative approach. Mainly undoing things that aren't so great in Java language and unlikely to change for language compatibility reasons, and avoiding some of the pitfalls with Scala. I think Scala saw a bit of wild growth of features and frameworks that Kotlin largely avoided. For better or worse, there has been a bit of a Scala diaspora with people flocking to things like Rust, Elixir, and indeed some to Kotlin. Weather people like it or not, Kotlin plays very nice with existing Java code bases. By design. It was designed as a drop in replacement. It's why it caught on with Android developers before it even was released. It's a bit different from Scala in that respect, which while it worked alright with Java code bases really nudged you away from that to the point where you'd be swapping out your build tools, frameworks, etc. At this point Kotlin is arguably a better language to use with any of the popular Java frameworks. I'm not really aware of any exceptions to this. Spring is a good example (arguably the most popular server framework for Java and the JVM). IMHO you are missing out if you are not using that with Kotlin. The Spring people certainly seem to agree. They've invested lots of time and effort to make Kotlin a first class citizen in the ecosystem. Documentation is dual Kotlin/Java, the framework ships with lots of extension functions for Kotlin and Kotlin specific features, and expanded Kotlin support is one of the headline features for the upcoming major version. And it's not like the previous version was particularly lacking on that front. They've been supporting the Kotlin ecosystem for many years now.

elric 1y ago

Brian Goetz mentions Guy Steele's 1998 lecture "Growing a language" [1]. It's worth a watch if you haven't watched it yet. It's been discussed on HN several times [2]. Java gets a lot of flack in these parts, mostly by people who don't use Java and pull opinions out of their arse, but you'd be hard pressed watching both talks and not being impressed by the effort that's going into continuously improving the language. [1] https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 [2] https://hn.algolia.com/?q=growing+a+language https://hn.algolia.com/?q=growing+a+language

gorset 1y ago
I enjoyed both talks a lot. I really appreciate the work done to evolve Java. They seem to be able to both fix earlier mistakes (and there were many!) and new ones from happening. While I see other languages struggling with the weight of complexity added over time, Java seems to get simpler and easier even with significant updates to the language spec.