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?
Java backend = Spring Boot. It dominates the market.
The Modern Java Platform – 2021 Edition
201–210 of 259 posts
Re: The Modern Java Platform – 2021 Edition
#202Really the future of the Modern Java Platform is Graal - 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/ You can also compile your application into a native image (like Go?) - https://www.graalvm.org/reference-manual/native-image/ you can try it in the next 5 mins 1.…
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…
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.
Re: The Modern Java Platform – 2021 Edition
#203There'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 th…
I've been through the whole evolution from Spring with XML configuration to the current 'convention over configuration' approach of Spring Boot. I actually liked the idea behind the XML configuration when I first got to know Spring in 2007. With this you could decouple the composition of your application from the actual code. You could deliver a jar and the user could decide with his own XML which parts to use and wh…
My thoughts exactly. I started with the XML flavor, and although I hate XML, it was (IMO) a far superior mechanism than annotations. All the config was in one spot. You didn't need to recompile to change it. So much easier, all in all.
Re: The Modern Java Platform – 2021 Edition
#204When 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…
I think it's a shot at Ruby and Node- they have a lot of dependencies that rely on underlying C/C++ libraries so you can end up having to manage both. Things like that exist in Java (e.g. some OpenGL libraries) but they're relatively rare.
Re: The Modern Java Platform – 2021 Edition
#205Earlier quoted context omitted.
And you end up writing yet another custom framework for yourself when you realize you are writing the same things over and over...
But you and up writing just the bits you need so that you end up with a framework that serves your use cases, that you grew so you understand and unencumbured by the use cases of others. It'll make you more productive... but not necessarily the person you hand it off to.
Yes totally agree with that, it is not only negatives.
Re: The Modern Java Platform – 2021 Edition
#206Earlier quoted context omitted.
I'm not sure I do. Isn't polyglotism about being able to write in different languages, and Java VM making that possible?
WORA is about coding in one language and running the code in any OS/hardware. Openjdk is one of the only language VM to support multiple languages (with coreclr). However the languages that compile to bytecode are not automatically interoperable between each other. Usually languages (scala, groovy, etc) have partial interoperability with Java and almost zero interop between each other (scala kotlin, kotlin groovy). K…
I see. GraalVM sounds great. Thanks for the explanation
Re: The Modern Java Platform – 2021 Edition
#207Earlier quoted context omitted.
What do you mean by write-only framework?
WOF == you understand your software while you're writing/developing it but give it a rest for a Trump's "two weeks" and you'll have no clue what you did.
Apparently Donald Trump always said "two weeks". I was unaware of this meme.
* https://www.axios.com/trumps-timeline-always-two-weeks-15133...
* https://www.bloomberg.com/news/articles/2017-06-06/in-trump-...
Re: The Modern Java Platform – 2021 Edition
#208People 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 alt…
Spring is a flow of control obfuscation framework.
Dependency Injection is for people who reject the clarity of composition.
Re: The Modern Java Platform – 2021 Edition
#209With 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.
Project Loom (structured concurrency) is a game changer.
Re: The Modern Java Platform – 2021 Edition
#210Earlier quoted context omitted.
XML is not any more or less "turing complete" than yaml, is it? They both express static data structures. I suppose you can make turing complete languages that use the syntax of either one (XSLT is one; i'm sure there are others in YAML), although it gets pretty iffy.
I agree, static data structures are far from ideal. Practically speaking, there's not much more you can accomplish with YAML or JSON compared to XML, even if some people find the syntax more palatable. Also, trying to shoehorn conditions and loops into a non-Turing Complete language is cumbersome. I would imagine it being a nightmare for platform and framework maintainers, as well. Rather than create a config or depe…
> there's not much more you can accomplish with YAML or JSON compared to XML, even if some people find the syntax more palatable.
Sure, and vice versa.
I think there are arguments to be had for whether you want your config language to be "turing complete" (or in general capable of containing logic or just static data). I am not sure I am convinced.
But you seemed to be saying that XML was preferable to yaml for some reason related to turing completeness/logical power, which I'm not seeing. You can "shoehorn" conditions and loops into YAML or XML if you want (by defining a semantics on top of either one), and it's going to be cumbersome, yup.