21 ms·

The Modern Java Platform – 2021 Edition

266 points by craigkerstiens 6y ago

cosmotic 6y ago
What does modern mean in this context?
- dmitryminkovsky 6y ago
  Probably relative to things like J2EE as mentioned in the beginning, and as mentioned toward this middle: > Non-blocking / reactive is one of the central demarcating elements of “modern” vs traditional.
  - gred 6y ago
    I'm hoping to skip modern (i.e. reactive) and go straight to post-modern (i.e. Loom).
    - dmitryminkovsky 6y ago
      Post-modern, pre-future
kylecazar 6y ago
Go? Archaic? I suppose you are referring to the paradigm it employs...
- andrewstuart2 6y ago
  Maybe the author isn't a fan of explicit pointers? Because yeah, though it's obviously c-like (as is Java), I can't think of anything else one might consider archaic that isn't also in the java language or virtual machine.
  - oblio 6y ago
    Why does Go need explicit pointers?
    - jrsj 6y ago
      It’s less about need and more that it’s a feature to help you more easily understand your memory allocations and when you are getting a reference to something vs a copy
  - bosswipe 6y ago
    There are sooo many nice language features that have proven themselves over the last 3-4 decades and have become popular but are missing from Go that I think archaic is appropriate.
    - andrewstuart2 6y ago
      There's archaic and there's minimalist, and they're definitely not the same. Languages with buckets of features have steeper and longer learning curves, and if they're still actively developed, what you do learn may not last long. Go is what I'd call minimalist. COBOL or fortran are what I'd call archaic.
- jlward4th 6y ago
  Author here. Yeah, the Go language feels very archaic when using more modern languages. Some things I miss when I use Go: immutability as a default, monadic error handling, type classes, higher-kinded types, high-level collection operations (map, flatmap, filter, etc), ADTs, extensive pattern matching, expression-orientedness, and explicit null handling.
  - holografix 6y ago
    Guess that’s why kubernetes and so many other CNCF projects were written in Go. It’s archaic enough that everyone can get things done instead of worrying about esoteric new features.
    - pjmlp 6y ago
      Kubernetes was prototyped in Java and rewritten in Go due to Go bias of some team members, which forced a rewrite into Go. Source: A couple of talks at FOSDEM. Don't attribute to technology the outcome of political decisions. I also used to get things done in TASM.
      - holografix 6y ago
        Have you stopped to consider why those team members had a bias towards Go? Maybe it’s for a reason. Maybe the people behind Istio, InfluxDB, Docker, Traefik, Terraform, etc also chose the “archaic” Go for “political reasons”.
    - phillipcarter 6y ago
      Some of the world's most incredible software is written in C and JavaScript and both are languages with incredible deficiencies from a language design standpoint. This doesn't take away from the software that was written in them.
    - dfacastro 6y ago
      You're assuming that tech is a meritocracy (it very much is not). You're implying that if a tool is archaic, things cannot be done with it (also not true). You're also explicitly saying that the features James mentioned are esoteric, which is easily disproven by the fact that many mainstream languages have them nowadays.
The_rationalist 6y ago
GraalVM truly has the potential to become the universal, interoperable VM. It would be rational for e.g Julia folks to migrate to the graalVM ecosystem and cotntribute to it instead of living on their small code island. They would get an un inimaginable amount of benefits in the process.
- toomanyducks 6y ago
  How does a VM (JVM, GraalVM) compare to something like LLVM's IR? From your description as a ``universal, _interoperable_ VM`` it seems like they have some similar goals --- what are the reasons to write a compiler to a VM instead of with LLVM/IR?
  - AlphaSite 6y ago
    I don’t think LLVM IR is really interoperable, is it?
  - The_rationalist 6y ago
    Good question: GraalVM support taking LLVM IR as an input https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong Which means that graalVM can support any llvm language almost out of the box (in theory) Llvm IR however has not been designed with inter language interoperability in mind or at least not enough. E.g rust has no transparant, complete, seamless and efficient interop with swift, go, c++, etc But in theory llvm is just an AOT and both AOT and JIT can enable true interoperability which is why graalvm support both a jit mode and an AOT mode. However JITs enable better performance at least for any high level, GCed language than would an AOT. Moreover, GraalVM through the truffle framework enable unprecedented language designer productivity. Through high level constructs the designers can be much more productive than in standard VM/AOT, which explains how with a few engineers Oracle has managed to reimplement Java, ruby, python, js and R in parallel in only a few years...
  - kaba0 6y ago
    I’m not super knowledgeable on LLVM, but as far as I know while it did have at some point a VM runner, it is rather meant to abstract hardware for native compilation. The Java bytecode is much less specific. Also, LLVM IR is not really backward compatible, while Java bytecode is. (By the way Graal has sulong which actually runs LLVM IR on top of the JVM)
mberning 6y ago
My biggest gripe with java is developer productivity. It has gotten better but is still far behind interpreted languages like Python and Ruby. Class hot loading and things like that have made it better, but if you change a method signature or interface you have to stop your process, recompile, redeploy, and restart. For big codebases it’s brutal compared to the aforementioned languages and their attendant frameworks.
- hello_moto 6y ago
  In big codebases, people don't change Interface (that's a contract btw) that often. They would do the proper "migration" by offering path to the new contract/api. If you have huge codebase in Python or Ruby, you'll rip your hair more often because it's riskier to make changes (dynamic language) according to your use-case :).
  - mberning 6y ago
    Sure, according to some OO professor. In real life these things change all the time. And it’s not just methods and interfaces that force a recompile, those are just examples. As for dynamic language projects, they should include a test suite to mitigate such issues, but often do not.
    - NOGDP 6y ago
      A big chunk of the issues you're writing that test suite for, and constantly rerunning, are solved, out of the box, by having a decent type system. The type system also gives you superior code completion (with proper IDE support), which already outweighs any potential reload time costs in Java vs Python/Ruby, for me personally.
- jakear 6y ago
  If you change an interface in Python you need to manually verify that everything is correctly using that new interface. That’s much more of a devprod hit.
- lenkite 6y ago
TeaVMFan 6y ago
The one thing missing is the innovation happening on the Java front end. Frameworks like TeaVM (https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...) let you extend your Java app all the way to the browser.
- TeaVMFan 6y ago
  For more info on full-stack Java, including options for Java based single-page apps and Java-based mobile apps, visit https://frequal.com/FullStackJava/ https://frequal.com/FullStackJava/
- cromwellian 6y ago
  From that article "and produces smaller JavaScript that performs better in the browser". Not according to my benchmarks. That may be true if you use the GWT Widget library, but if you code 'to the metal' using Elemental, GWT produced substantially smaller code than TeaVM when I benchmarked it a few years ago with the Bench2D (Box2D) benchmark. Maybe it got better since then, but I doubt it given the progress GWT's successor made. Using J2CL (the successor to GWT), the following Java class public class Main { public static void main(String argv[]) { window.alert("Hello World"); } } would actually compile down to just (JS) window.alert("Hello World") TeaVM doesn't support code splitting that Both GWT and Closure Compiler support, or cross-module code motion. https://github.com/konsoletyper/teavm/issues/333 https://github.com/konsoletyper/teavm/issues/333
- koala7 6y ago
  You might be interested in https://vaadin.com/ https://vaadin.com/.
lmm 6y ago
There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess that must mean you want a MongoDB connection pool spun up and running). I swear I'm going to add a bitcoin miner to my libraries and list it in spring.factories so that it autostarts whenever someone starts a Spring Boot application with my library on the classpath. There'll be an undocumented config property to turn it off or make it mine to a different address. That's standard practice with every other library that uses Spring Boot, so it's perfectly ethical, and it's not like anyone using Spring Boot would notice that their application was wasting a bunch of resources. Maybe someone else did this already. That would explain a lot actually.
- reda-alaoui 6y ago
  I think too that Spring Boot opt-out autoconfiguration is an issue. Take a look at https://github.com/spring-projects/spring-boot/issues/25742#issue-835713980 https://github.com/spring-projects/spring-boot/issues/25742#... I included a workaround allowing to opt-in for autoconfiguration instead of opting out. I have used the filter for more than 2 years without issue.
- codr7 6y ago
  This. I spent so much time this week chasing magic buttons in that over engineered piece of stink. I'd rather do raw HTTP servlets at this point.
  - diroussel 6y ago
    Even servlet containers are the wrong approach. I have from experience it’s best to stick to libraries. You know where you are when you call a function. The Servlet spec now includes annotation scanning by default now, which is unnecessarily complicated and slows down start up.
  - ianlevesque 6y ago
jacques_chester 6y ago
I liked this article, but it felt to be as much about Scala and Kotlin as about Java. A more accurate title would've been "The Modern JVM Platform". I recently began doing a side project and, for the first time in a while, picked Java over Kotlin. I mostly did so because most books on deep details of the JVM are mostly books about the deep details of Java. Plus: Java is moving along at a fair clip these days. Records just landed in 16, Project Loom and Project Valhalla are coming over the horizon, plus lots of other niceties that've showed up lately.
- orthoxerox 6y ago
  > Project Loom and Project Valhalla are coming over the horizon A: They say it's coming over the horizon. What's the horizon, B? B: That's the imaginary line where the land and the sky meet that you cannot reach however fast you go.
  - twic 6y ago
    Things can come over the horizon towards you though.
johndoe42377 6y ago
Oh, really? I used to be banned from this site for bashing J2EE lmao. Now it is a new normal, I see.
- deleted 6y ago
  [deleted]
dang 6y ago
Recent and related: Java 16 - https://news.ycombinator.com/item?id=26477144 https://news.ycombinator.com/item?id=26477144 - March 2021 (276 comments)
wiradikusuma 6y ago
Quarkus (and its dependent techs) has been in my radar for a while, and recently I've started using it, and I must say I'm impressed. Code in modern Java (lamba etc) -> build native Linux exe -> package as Docker image -> deploy in Google Cloud Run. All wiring from CLI so CI/CD friendly (next is to use Google Cloud Build). Since it's native, memory usage small and boot time negligible. Since it's managed, it auto-scales (up and down, to zero cost). My complaints: * Quarkus is very opinionated. I'm used to this coming from Google App Engine. * Building _native_ exe is slow. Like 1995 Java slow. * Scala support is limited. If you're used to App Engine, you know exactly the dream I'm living in. Without App Engine's limitations.
- TheGuyWhoCodes 6y ago
  I had the opposite reaction. They decided to reimplement almost everything and pushing hard on reactive stream, but their documentation is horrendous and the API is super complicated. After a month of tinkering I just gave up and used spring boot.
  - wiradikusuma 6y ago
    I almost fall into the same trap. Lucky the documentation for reactive approach is very lacking, and I'm lazy, so I stick with traditional approach.
  - lenkite 6y ago
    Please don't use Reactive in Java. Stick to plain imperative - and you'll be compatible with Project Loom in the future.
    - EvilEy3 6y ago
      I don't see how using Reactive makes you incompatible with Project Loom.
      - lenkite 6y ago
        I meant using the Reactive API types like using Publiher<Response> in REST APIs. These will be un-necessary in the future.
hans0l074 6y ago
When I use developer tooling in other platforms I’m usually disappointed. I shouldn’t need some special native library installed on my system so I can install a dependency. It shouldn’t take me hours to get my local developer toolchain set up. I found this comment odd - it does take some time to get a modern Java dev env up and running from scratch. For e.g. you have to at least download/install gradle or maven after the JDK. And then the author goes onto to talk about the Testcontainers project for which it appears you need to set up Docker. And so on. Wonder if I missed the meaning there.
- elygre 6y ago
  The Gradle wrapper is how you let gradle download itself upon first execution. It stays in your git-repo, and then you don’t need to install gradle yourself. https://docs.gradle.org/current/userguide/gradle_wrapper.html https://docs.gradle.org/current/userguide/gradle_wrapper.htm...
  - hans0l074 6y ago
    But surely if you are starting off you need to install/initialize the wrapper itself, no? From your link, Generating the Wrapper files requires an installed version of the Gradle runtime on your machine as described in Installation. Thankfully, generating the initial Wrapper files is a one-time process.
    - vbezhenar 6y ago
      If you’re using existing project, you don’t need to install gradle. For new projects you can copy few files from any other project. That “generation” just copies few files into your project and puts tiny config file. It should really be available as a separate tiny download IMO. Gradle makes it looking harder than it is.
    - twic 6y ago
      You can bootstrap a fresh project using this: https://gradle-initializr.cleverapps.io/ https://gradle-initializr.cleverapps.io/
matsemann 6y ago
Pair programming with colleagues I often get frustrated by them wasting time doing things a hard way. Like using print statements instead of the debugger, or setting a breakpoint but then have to skip it twenty times to get to the correct case (instead of a conditional bp), or restarting the whole server instead of hot reloading the changed class in a second. So I think many don't know how smooth java can be if used correctly. But that also makes me think if there are low hanging fruit / obvious stuff I also don't know that could be a boost to my productivity?
- elric 6y ago
  Conditional break points are definitely a great secret weapon. But don't underestimate the value of the humble print statement. It's convenient and can often lead to surprising insights "hmm, why is this getting printed so damned much?" in a way that is sometimes more accessible than a debugger.
  - blacktriangle 6y ago
    This right here, print statement debugging gets far more of a bad name than it deserves. If that's a developers only tool then sure that's a problem, but no need to hate on a very simple and effective technique just because it's often the only one people know when they are starting out.
    - zaphar 6y ago
      Print debugging results in a printed log of this happened, then this happened, ..., and finally this happened. And you can trivially rewind it and do random looks at the log. Debuggers have difficulty giving you this much context at your fingertips. The downside is that if you missed one of those critical "this happened" items in your log you have to rerun. But debuggers have the same problem. If you missed a breakpoint you have to re-run.
      - dropofwill 6y ago
        Intellij’s debugger has a ‘drop frame’ feature that i use a lot for going back in time when i missed something. It also shows you the state of variables at various points alongside the code, which is basically the context i want to log anyways.
TedShiller 6y ago
Java Play Framework is great. It's what Spring should be. https://www.playframework.com/ https://www.playframework.com/
akhilcacharya 6y ago
What’s the modern standard for a full stack JVM app these days? Something rails-esque, or is it still just a split between Play and Spring Boot?
- deleted 6y ago
  [deleted]
- jillesvangurp 6y ago
  Spring Boot pretty much dominates. I think Play market share is a bit more in the long tail of alternatives. Also, it's very Scala centric and not widely used without Scala. Spring is increasingly Kotlin centric and the combination is pretty nice. There's a wide variety of other frameworks such as vert.x, ktor, quarcus, etc. They are popular but compared to Spring quite niche. With Graal and Kotlin native, the whole space is becoming less JVM centric as well. E.g. Spring Native just went into beta and Ktor has been inching closer to working on the Kotlin Native compiler for a while now (still some missing pieces). Particularly for serverless, this is relevant due to reduced startup time. Overall performance is not significantly better though.
- augusto-moura 6y ago
  You have Grails p. P p a Rails alternative, I don't recommend it though Grails has come a long way but still has a lot of inconeniences and is becoming obsolete by the day, it became a monster with tangled and twisted code, everything (views, models, queries) has 2 or 3 reimplementations that don't quite work and are not finished. I used to develop more than 5 services in it and frankly I don't know how I managed to stay sane or sleep at night
- cabraca 6y ago
  Check out https://www.jhipster.tech https://www.jhipster.tech It uses Spring Boot, but comes with a lot of sane defaults.
- orthoxerox 6y ago
  Job listings in the searches I am subscribed to are almost universally Spring and Spring Boot.
sandGorgon 6y ago
Really the future of the Modern Java Platform is Graal - https://www.graalvm.org/reference-manual/embed-languages/ https://www.graalvm.org/reference-manual/embed-languages/ Java is not Spring Boot. For example, this is Python 3.8 compliant runtime on top of Graal - https://www.graalvm.org/reference-manual/python/ https://www.graalvm.org/reference-manual/python/ You can also compile your application into a native image (like Go?) - https://www.graalvm.org/reference-manual/native-image/ https://www.graalvm.org/reference-manual/native-image/ you can try it in the next 5 mins 1. docker pull ghcr.io/graalvm/graalvm-ce:latest 2. docker run -it ghcr.io/graalvm/graalvm-ce:latest bash 3. gu install python 4. graalpython -m venv myvenv
- kaba0 6y ago
  What is more impressive is the graaljs implementation, that when warmed up, has comparable performance to god damn v8. All that with a complete polyglot runtime, so you can call python code from js and vice versa and the best part: it will inline and JIT compile over language boundaries. Also, truffleruby (graalvm’s ruby implementation) is/was two times faster than regular ruby - that’s how much engineering went into the JVM. And of course well-performing (but worse than JIT) AOT compilation is also a possibility with it, though I feel it is not needed as often as people think.
  - cogman10 6y ago
    Doesn't stop there. There's also project sulong that tries to bring LLVM IR into the graal ecosystem. Giving you the ability to integrate C/C++/Rust/Fortran/etc. Whatever has an LLVM backend could possibly run side by side with Java/javascript/python all without major FFI penalties and possible cross language optimizations. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
- erikds 6y ago
  Never heard about Graal before. When reading the description it reminds me of WebAssembly. Can anyone compare how they compare?
andresp 6y ago
Java is a great language. It keeps evolving at good pace, increasing dev productivity and adapting to modern patterns, while keeping a clear syntax, scalable VM, relatively fast compiler, in a mature ecosystem. It might be at the healthiest level it has ever been.
MaxBarraclough 6y ago
> in most ways, the core Java platform technologies work like other free and open programming platforms. There are, however, a few parts that are proprietary. I thought OpenJDK was TCK-certified to be Java compliant, and 100% Free and Open Source software. Is that mistaken? > To label a custom JDK with the Java brand (which is owned by Oracle) it must pass the tests in the Technology Compatibility Kit, which must be licensed from Oracle for such purpose. Right, except there's a special exception for OpenJDK and derivatives. [0] Apparently though this doesn't always work out. [1] [0] https://openjdk.java.net/groups/conformance/JckAccess/ https://openjdk.java.net/groups/conformance/JckAccess/ [1] https://adoptopenjdk.net/quality.html https://adoptopenjdk.net/quality.html
lmilcin 6y ago
I find reactive stuff the best improvement in my productivity since Spring. I use both RxJava and Reactor, and I sometimes have a one page function that could have been an entire application in the past. My manager once asked me if we can have a complex endpoint to page data from multiple collections on multiple MongoDB clusters (paging is for backwards compatibility with some clients) and do it efficiently. This requires sorting query results on each of the clusters, then merging the streams of data into a sorted stream and then do that paging manually on the resulting stream. You also need to deal with various error handling and retry requirements. He asked this 20 minutes before our 1:1 and I had working endpoint before we started it. Does it have steep learning curve? Sure. But it is totally worth it.
throwaway4good 6y ago
People are critical of Spring because they have seen it in production and in practical projects. And fall in the naive trap that somehow the tools and the libraries are the reasons why a real-life software project is messy. However Spring is something that has stood the test of time and is used in thousands of actual projects. And Spring itself emerge out of practical software development with plenty of competing alternatives (Guice, classic J2EE plus many others). The mentioned alternatives in article: Micronaut and Quarkus are not much beyound the demo state, and frankly based on some questionable ideas: Compile-time dependency injection and idea of "cloud native" - that somehow things run better in the cloud if they are compiled into a binary.
- zaphar 6y ago
  I'm not critical of spring because real life software projects are messy. I'm critical because I rarely if ever do greenfield development and when I'm debugging a production exception caused by something that Java's type system was perfectly capable of treating as a compile time error that is suddenly a runtime error I'm a little bit sad. And the sheer frequency that I encounter them indicates that just getting more disciplined developers isn't really a solution here.
  - selfhoster11 6y ago
    The real solution is to bite the bullet and build Spring's features into Java. Make as many failures as possible detectable during compilation, and go back to hard typing.
    - diroussel 6y ago
      Micronaut gives you that. Compile time validation of your bean wiring.
    - throwaway4good 6y ago
      Or maybe if you just want to hardwire your dependencies, you shouldn't use dependency injection.
    - 6y ago
geodel 6y ago
> I really enjoy writing Scala code and the continual improvements. It feels very cutting edge and my personal productivity feels significantly better than with more archaic languages like Go. Google seems really hiring clueless marketers lately. This article is indeed full of hilarious nuggets like above.
mwcampbell 6y ago
With Project Loom coming soon, I think it's a mistake to write new application code in the reactive style. The imperative style is much more straightforward, gives access to a wider world of libraries, and (IIUC) will be just as efficient when Project Loom reaches production.
- EvilEy3 6y ago
  Reactive style is written for reactive style, not to somehow bypass concurrency limitations.
- specialist 6y ago
  Project Loom (structured concurrency) is a game changer.
rowland66 6y ago
That first sequence diagram in the article reminds me of similar diagrams that I have seen for microservice based systems recently. Progress? Not so sure.
Zababa 6y ago
How do you get started with the whole Java ecosystem in 2021? It feels so vast.
TobySKT 6y ago
How to Build an On-Demand Platform Like Uber or Airbnb The following article examines how build an on-demand platform like Uber or Airbnb and how other apps and digital services may benefit from the on-demand delivery apps. https://steelkiwi.com/blog/how-to-build-an-on-demand-platform-like-uber-or-airbnb/ https://steelkiwi.com/blog/how-to-build-an-on-demand-platfor...

cosmotic 6y ago

What does modern mean in this context?

dmitryminkovsky 6y ago
Probably relative to things like J2EE as mentioned in the beginning, and as mentioned toward this middle: > Non-blocking / reactive is one of the central demarcating elements of “modern” vs traditional.
- gred 6y ago
  I'm hoping to skip modern (i.e. reactive) and go straight to post-modern (i.e. Loom).
  - dmitryminkovsky 6y ago
    Post-modern, pre-future

kylecazar 6y ago

Go? Archaic? I suppose you are referring to the paradigm it employs...

andrewstuart2 6y ago
Maybe the author isn't a fan of explicit pointers? Because yeah, though it's obviously c-like (as is Java), I can't think of anything else one might consider archaic that isn't also in the java language or virtual machine.
- oblio 6y ago
  Why does Go need explicit pointers?
  - jrsj 6y ago
    It’s less about need and more that it’s a feature to help you more easily understand your memory allocations and when you are getting a reference to something vs a copy
- bosswipe 6y ago
  There are sooo many nice language features that have proven themselves over the last 3-4 decades and have become popular but are missing from Go that I think archaic is appropriate.
  - andrewstuart2 6y ago
    There's archaic and there's minimalist, and they're definitely not the same. Languages with buckets of features have steeper and longer learning curves, and if they're still actively developed, what you do learn may not last long. Go is what I'd call minimalist. COBOL or fortran are what I'd call archaic.
jlward4th 6y ago
Author here. Yeah, the Go language feels very archaic when using more modern languages. Some things I miss when I use Go: immutability as a default, monadic error handling, type classes, higher-kinded types, high-level collection operations (map, flatmap, filter, etc), ADTs, extensive pattern matching, expression-orientedness, and explicit null handling.
- holografix 6y ago
  Guess that’s why kubernetes and so many other CNCF projects were written in Go. It’s archaic enough that everyone can get things done instead of worrying about esoteric new features.
  - pjmlp 6y ago
    Kubernetes was prototyped in Java and rewritten in Go due to Go bias of some team members, which forced a rewrite into Go. Source: A couple of talks at FOSDEM. Don't attribute to technology the outcome of political decisions. I also used to get things done in TASM.
    - holografix 6y ago
      Have you stopped to consider why those team members had a bias towards Go? Maybe it’s for a reason. Maybe the people behind Istio, InfluxDB, Docker, Traefik, Terraform, etc also chose the “archaic” Go for “political reasons”.
  - phillipcarter 6y ago
    Some of the world's most incredible software is written in C and JavaScript and both are languages with incredible deficiencies from a language design standpoint. This doesn't take away from the software that was written in them.
  - dfacastro 6y ago
    You're assuming that tech is a meritocracy (it very much is not). You're implying that if a tool is archaic, things cannot be done with it (also not true). You're also explicitly saying that the features James mentioned are esoteric, which is easily disproven by the fact that many mainstream languages have them nowadays.

The_rationalist 6y ago

GraalVM truly has the potential to become the universal, interoperable VM. It would be rational for e.g Julia folks to migrate to the graalVM ecosystem and cotntribute to it instead of living on their small code island. They would get an un inimaginable amount of benefits in the process.

toomanyducks 6y ago
How does a VM (JVM, GraalVM) compare to something like LLVM's IR? From your description as a ``universal, _interoperable_ VM`` it seems like they have some similar goals --- what are the reasons to write a compiler to a VM instead of with LLVM/IR?
- AlphaSite 6y ago
  I don’t think LLVM IR is really interoperable, is it?
- The_rationalist 6y ago
  Good question: GraalVM support taking LLVM IR as an input https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong Which means that graalVM can support any llvm language almost out of the box (in theory) Llvm IR however has not been designed with inter language interoperability in mind or at least not enough. E.g rust has no transparant, complete, seamless and efficient interop with swift, go, c++, etc But in theory llvm is just an AOT and both AOT and JIT can enable true interoperability which is why graalvm support both a jit mode and an AOT mode. However JITs enable better performance at least for any high level, GCed language than would an AOT. Moreover, GraalVM through the truffle framework enable unprecedented language designer productivity. Through high level constructs the designers can be much more productive than in standard VM/AOT, which explains how with a few engineers Oracle has managed to reimplement Java, ruby, python, js and R in parallel in only a few years...
- kaba0 6y ago
  I’m not super knowledgeable on LLVM, but as far as I know while it did have at some point a VM runner, it is rather meant to abstract hardware for native compilation. The Java bytecode is much less specific. Also, LLVM IR is not really backward compatible, while Java bytecode is. (By the way Graal has sulong which actually runs LLVM IR on top of the JVM)

mberning 6y ago

My biggest gripe with java is developer productivity. It has gotten better but is still far behind interpreted languages like Python and Ruby. Class hot loading and things like that have made it better, but if you change a method signature or interface you have to stop your process, recompile, redeploy, and restart. For big codebases it’s brutal compared to the aforementioned languages and their attendant frameworks.

hello_moto 6y ago
In big codebases, people don't change Interface (that's a contract btw) that often. They would do the proper "migration" by offering path to the new contract/api. If you have huge codebase in Python or Ruby, you'll rip your hair more often because it's riskier to make changes (dynamic language) according to your use-case :).
- mberning 6y ago
  Sure, according to some OO professor. In real life these things change all the time. And it’s not just methods and interfaces that force a recompile, those are just examples. As for dynamic language projects, they should include a test suite to mitigate such issues, but often do not.
  - NOGDP 6y ago
    A big chunk of the issues you're writing that test suite for, and constantly rerunning, are solved, out of the box, by having a decent type system. The type system also gives you superior code completion (with proper IDE support), which already outweighs any potential reload time costs in Java vs Python/Ruby, for me personally.
jakear 6y ago
If you change an interface in Python you need to manually verify that everything is correctly using that new interface. That’s much more of a devprod hit.
lenkite 6y ago

TeaVMFan 6y ago

The one thing missing is the innovation happening on the Java front end. Frameworks like TeaVM (https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...) let you extend your Java app all the way to the browser.

TeaVMFan 6y ago
For more info on full-stack Java, including options for Java based single-page apps and Java-based mobile apps, visit https://frequal.com/FullStackJava/ https://frequal.com/FullStackJava/
cromwellian 6y ago
From that article "and produces smaller JavaScript that performs better in the browser". Not according to my benchmarks. That may be true if you use the GWT Widget library, but if you code 'to the metal' using Elemental, GWT produced substantially smaller code than TeaVM when I benchmarked it a few years ago with the Bench2D (Box2D) benchmark. Maybe it got better since then, but I doubt it given the progress GWT's successor made. Using J2CL (the successor to GWT), the following Java class public class Main { public static void main(String argv[]) { window.alert("Hello World"); } } would actually compile down to just (JS) window.alert("Hello World") TeaVM doesn't support code splitting that Both GWT and Closure Compiler support, or cross-module code motion. https://github.com/konsoletyper/teavm/issues/333 https://github.com/konsoletyper/teavm/issues/333
koala7 6y ago
You might be interested in https://vaadin.com/ https://vaadin.com/.

lmm 6y ago

There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess that must mean you want a MongoDB connection pool spun up and running). I swear I'm going to add a bitcoin miner to my libraries and list it in spring.factories so that it autostarts whenever someone starts a Spring Boot application with my library on the classpath. There'll be an undocumented config property to turn it off or make it mine to a different address. That's standard practice with every other library that uses Spring Boot, so it's perfectly ethical, and it's not like anyone using Spring Boot would notice that their application was wasting a bunch of resources. Maybe someone else did this already. That would explain a lot actually.

reda-alaoui 6y ago
I think too that Spring Boot opt-out autoconfiguration is an issue. Take a look at https://github.com/spring-projects/spring-boot/issues/25742#issue-835713980 https://github.com/spring-projects/spring-boot/issues/25742#... I included a workaround allowing to opt-in for autoconfiguration instead of opting out. I have used the filter for more than 2 years without issue.
codr7 6y ago
This. I spent so much time this week chasing magic buttons in that over engineered piece of stink. I'd rather do raw HTTP servlets at this point.
- diroussel 6y ago
  Even servlet containers are the wrong approach. I have from experience it’s best to stick to libraries. You know where you are when you call a function. The Servlet spec now includes annotation scanning by default now, which is unnecessarily complicated and slows down start up.
- ianlevesque 6y ago

jacques_chester 6y ago

I liked this article, but it felt to be as much about Scala and Kotlin as about Java. A more accurate title would've been "The Modern JVM Platform". I recently began doing a side project and, for the first time in a while, picked Java over Kotlin. I mostly did so because most books on deep details of the JVM are mostly books about the deep details of Java. Plus: Java is moving along at a fair clip these days. Records just landed in 16, Project Loom and Project Valhalla are coming over the horizon, plus lots of other niceties that've showed up lately.

orthoxerox 6y ago
> Project Loom and Project Valhalla are coming over the horizon A: They say it's coming over the horizon. What's the horizon, B? B: That's the imaginary line where the land and the sky meet that you cannot reach however fast you go.
- twic 6y ago
  Things can come over the horizon towards you though.

johndoe42377 6y ago

Oh, really? I used to be banned from this site for bashing J2EE lmao. Now it is a new normal, I see.

deleted 6y ago
[deleted]

dang 6y ago

Recent and related: Java 16 - https://news.ycombinator.com/item?id=26477144 https://news.ycombinator.com/item?id=26477144 - March 2021 (276 comments)

wiradikusuma 6y ago

Quarkus (and its dependent techs) has been in my radar for a while, and recently I've started using it, and I must say I'm impressed. Code in modern Java (lamba etc) -> build native Linux exe -> package as Docker image -> deploy in Google Cloud Run. All wiring from CLI so CI/CD friendly (next is to use Google Cloud Build). Since it's native, memory usage small and boot time negligible. Since it's managed, it auto-scales (up and down, to zero cost). My complaints: * Quarkus is very opinionated. I'm used to this coming from Google App Engine. * Building _native_ exe is slow. Like 1995 Java slow. * Scala support is limited. If you're used to App Engine, you know exactly the dream I'm living in. Without App Engine's limitations.

TheGuyWhoCodes 6y ago
I had the opposite reaction. They decided to reimplement almost everything and pushing hard on reactive stream, but their documentation is horrendous and the API is super complicated. After a month of tinkering I just gave up and used spring boot.
- wiradikusuma 6y ago
  I almost fall into the same trap. Lucky the documentation for reactive approach is very lacking, and I'm lazy, so I stick with traditional approach.
- lenkite 6y ago
  Please don't use Reactive in Java. Stick to plain imperative - and you'll be compatible with Project Loom in the future.
  - EvilEy3 6y ago
    I don't see how using Reactive makes you incompatible with Project Loom.
    - lenkite 6y ago
      I meant using the Reactive API types like using Publiher<Response> in REST APIs. These will be un-necessary in the future.

hans0l074 6y ago

When I use developer tooling in other platforms I’m usually disappointed. I shouldn’t need some special native library installed on my system so I can install a dependency. It shouldn’t take me hours to get my local developer toolchain set up. I found this comment odd - it does take some time to get a modern Java dev env up and running from scratch. For e.g. you have to at least download/install gradle or maven after the JDK. And then the author goes onto to talk about the Testcontainers project for which it appears you need to set up Docker. And so on. Wonder if I missed the meaning there.

elygre 6y ago
The Gradle wrapper is how you let gradle download itself upon first execution. It stays in your git-repo, and then you don’t need to install gradle yourself. https://docs.gradle.org/current/userguide/gradle_wrapper.html https://docs.gradle.org/current/userguide/gradle_wrapper.htm...
- hans0l074 6y ago
  But surely if you are starting off you need to install/initialize the wrapper itself, no? From your link, Generating the Wrapper files requires an installed version of the Gradle runtime on your machine as described in Installation. Thankfully, generating the initial Wrapper files is a one-time process.
  - vbezhenar 6y ago
    If you’re using existing project, you don’t need to install gradle. For new projects you can copy few files from any other project. That “generation” just copies few files into your project and puts tiny config file. It should really be available as a separate tiny download IMO. Gradle makes it looking harder than it is.
  - twic 6y ago
    You can bootstrap a fresh project using this: https://gradle-initializr.cleverapps.io/ https://gradle-initializr.cleverapps.io/

matsemann 6y ago

Pair programming with colleagues I often get frustrated by them wasting time doing things a hard way. Like using print statements instead of the debugger, or setting a breakpoint but then have to skip it twenty times to get to the correct case (instead of a conditional bp), or restarting the whole server instead of hot reloading the changed class in a second. So I think many don't know how smooth java can be if used correctly. But that also makes me think if there are low hanging fruit / obvious stuff I also don't know that could be a boost to my productivity?

elric 6y ago
Conditional break points are definitely a great secret weapon. But don't underestimate the value of the humble print statement. It's convenient and can often lead to surprising insights "hmm, why is this getting printed so damned much?" in a way that is sometimes more accessible than a debugger.
- blacktriangle 6y ago
  This right here, print statement debugging gets far more of a bad name than it deserves. If that's a developers only tool then sure that's a problem, but no need to hate on a very simple and effective technique just because it's often the only one people know when they are starting out.
  - zaphar 6y ago
    Print debugging results in a printed log of this happened, then this happened, ..., and finally this happened. And you can trivially rewind it and do random looks at the log. Debuggers have difficulty giving you this much context at your fingertips. The downside is that if you missed one of those critical "this happened" items in your log you have to rerun. But debuggers have the same problem. If you missed a breakpoint you have to re-run.
    - dropofwill 6y ago
      Intellij’s debugger has a ‘drop frame’ feature that i use a lot for going back in time when i missed something. It also shows you the state of variables at various points alongside the code, which is basically the context i want to log anyways.

TedShiller 6y ago

Java Play Framework is great. It's what Spring should be. https://www.playframework.com/ https://www.playframework.com/

akhilcacharya 6y ago

What’s the modern standard for a full stack JVM app these days? Something rails-esque, or is it still just a split between Play and Spring Boot?

deleted 6y ago
[deleted]
jillesvangurp 6y ago
Spring Boot pretty much dominates. I think Play market share is a bit more in the long tail of alternatives. Also, it's very Scala centric and not widely used without Scala. Spring is increasingly Kotlin centric and the combination is pretty nice. There's a wide variety of other frameworks such as vert.x, ktor, quarcus, etc. They are popular but compared to Spring quite niche. With Graal and Kotlin native, the whole space is becoming less JVM centric as well. E.g. Spring Native just went into beta and Ktor has been inching closer to working on the Kotlin Native compiler for a while now (still some missing pieces). Particularly for serverless, this is relevant due to reduced startup time. Overall performance is not significantly better though.
augusto-moura 6y ago
You have Grails p. P p a Rails alternative, I don't recommend it though Grails has come a long way but still has a lot of inconeniences and is becoming obsolete by the day, it became a monster with tangled and twisted code, everything (views, models, queries) has 2 or 3 reimplementations that don't quite work and are not finished. I used to develop more than 5 services in it and frankly I don't know how I managed to stay sane or sleep at night
cabraca 6y ago
Check out https://www.jhipster.tech https://www.jhipster.tech It uses Spring Boot, but comes with a lot of sane defaults.
orthoxerox 6y ago
Job listings in the searches I am subscribed to are almost universally Spring and Spring Boot.

sandGorgon 6y ago

Really the future of the Modern Java Platform is Graal - https://www.graalvm.org/reference-manual/embed-languages/ https://www.graalvm.org/reference-manual/embed-languages/ Java is not Spring Boot. For example, this is Python 3.8 compliant runtime on top of Graal - https://www.graalvm.org/reference-manual/python/ https://www.graalvm.org/reference-manual/python/ You can also compile your application into a native image (like Go?) - https://www.graalvm.org/reference-manual/native-image/ https://www.graalvm.org/reference-manual/native-image/ you can try it in the next 5 mins 1. docker pull ghcr.io/graalvm/graalvm-ce:latest 2. docker run -it ghcr.io/graalvm/graalvm-ce:latest bash 3. gu install python 4. graalpython -m venv myvenv

kaba0 6y ago
What is more impressive is the graaljs implementation, that when warmed up, has comparable performance to god damn v8. All that with a complete polyglot runtime, so you can call python code from js and vice versa and the best part: it will inline and JIT compile over language boundaries. Also, truffleruby (graalvm’s ruby implementation) is/was two times faster than regular ruby - that’s how much engineering went into the JVM. And of course well-performing (but worse than JIT) AOT compilation is also a possibility with it, though I feel it is not needed as often as people think.
- cogman10 6y ago
  Doesn't stop there. There's also project sulong that tries to bring LLVM IR into the graal ecosystem. Giving you the ability to integrate C/C++/Rust/Fortran/etc. Whatever has an LLVM backend could possibly run side by side with Java/javascript/python all without major FFI penalties and possible cross language optimizations. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
erikds 6y ago
Never heard about Graal before. When reading the description it reminds me of WebAssembly. Can anyone compare how they compare?

andresp 6y ago

Java is a great language. It keeps evolving at good pace, increasing dev productivity and adapting to modern patterns, while keeping a clear syntax, scalable VM, relatively fast compiler, in a mature ecosystem. It might be at the healthiest level it has ever been.

MaxBarraclough 6y ago

> in most ways, the core Java platform technologies work like other free and open programming platforms. There are, however, a few parts that are proprietary. I thought OpenJDK was TCK-certified to be Java compliant, and 100% Free and Open Source software. Is that mistaken? > To label a custom JDK with the Java brand (which is owned by Oracle) it must pass the tests in the Technology Compatibility Kit, which must be licensed from Oracle for such purpose. Right, except there's a special exception for OpenJDK and derivatives. [0] Apparently though this doesn't always work out. [1] [0] https://openjdk.java.net/groups/conformance/JckAccess/ https://openjdk.java.net/groups/conformance/JckAccess/ [1] https://adoptopenjdk.net/quality.html https://adoptopenjdk.net/quality.html

lmilcin 6y ago

I find reactive stuff the best improvement in my productivity since Spring. I use both RxJava and Reactor, and I sometimes have a one page function that could have been an entire application in the past. My manager once asked me if we can have a complex endpoint to page data from multiple collections on multiple MongoDB clusters (paging is for backwards compatibility with some clients) and do it efficiently. This requires sorting query results on each of the clusters, then merging the streams of data into a sorted stream and then do that paging manually on the resulting stream. You also need to deal with various error handling and retry requirements. He asked this 20 minutes before our 1:1 and I had working endpoint before we started it. Does it have steep learning curve? Sure. But it is totally worth it.

throwaway4good 6y ago

People are critical of Spring because they have seen it in production and in practical projects. And fall in the naive trap that somehow the tools and the libraries are the reasons why a real-life software project is messy. However Spring is something that has stood the test of time and is used in thousands of actual projects. And Spring itself emerge out of practical software development with plenty of competing alternatives (Guice, classic J2EE plus many others). The mentioned alternatives in article: Micronaut and Quarkus are not much beyound the demo state, and frankly based on some questionable ideas: Compile-time dependency injection and idea of "cloud native" - that somehow things run better in the cloud if they are compiled into a binary.

zaphar 6y ago
I'm not critical of spring because real life software projects are messy. I'm critical because I rarely if ever do greenfield development and when I'm debugging a production exception caused by something that Java's type system was perfectly capable of treating as a compile time error that is suddenly a runtime error I'm a little bit sad. And the sheer frequency that I encounter them indicates that just getting more disciplined developers isn't really a solution here.
- selfhoster11 6y ago
  The real solution is to bite the bullet and build Spring's features into Java. Make as many failures as possible detectable during compilation, and go back to hard typing.
  - diroussel 6y ago
    Micronaut gives you that. Compile time validation of your bean wiring.
  - throwaway4good 6y ago
    Or maybe if you just want to hardwire your dependencies, you shouldn't use dependency injection.
  - 6y ago

geodel 6y ago

> I really enjoy writing Scala code and the continual improvements. It feels very cutting edge and my personal productivity feels significantly better than with more archaic languages like Go. Google seems really hiring clueless marketers lately. This article is indeed full of hilarious nuggets like above.

mwcampbell 6y ago

With Project Loom coming soon, I think it's a mistake to write new application code in the reactive style. The imperative style is much more straightforward, gives access to a wider world of libraries, and (IIUC) will be just as efficient when Project Loom reaches production.

EvilEy3 6y ago
Reactive style is written for reactive style, not to somehow bypass concurrency limitations.
specialist 6y ago
Project Loom (structured concurrency) is a game changer.

rowland66 6y ago

That first sequence diagram in the article reminds me of similar diagrams that I have seen for microservice based systems recently. Progress? Not so sure.

Zababa 6y ago

How do you get started with the whole Java ecosystem in 2021? It feels so vast.

TobySKT 6y ago

How to Build an On-Demand Platform Like Uber or Airbnb The following article examines how build an on-demand platform like Uber or Airbnb and how other apps and digital services may benefit from the on-demand delivery apps. https://steelkiwi.com/blog/how-to-build-an-on-demand-platform-like-uber-or-airbnb/ https://steelkiwi.com/blog/how-to-build-an-on-demand-platfor...