Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Modern Java Platform – 2021 Edition

jamesward.com

Post reply on HN
Print view View original

221–230 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#221

Post by foo_barrio »

strictfp wrote: post #215
foo_barrio wrote: post #193

Earlier quoted context omitted.

Just as a counterpoint, I've done a little bit of game programming and currently work on a tax reporting system (mostly). Both are full of random shit you have to know for no reason. The game random shit I've had to learn was often tied to very specific platforms at very specific times. The game stuff very often I had to delve into actual math + algos. The tax reporting system I get bogged down and mired in the liter…

I'm not refuting that businesses can be complex, but I am saying that most of the complexity I've seen hasn't been inherent to the business.

I understand, I should have been clearer. My experience has been the opposite. The companies I've worked for had actual complexity to tackle. I guess I got a little defensive because I've encountered "game programmers are gods, everyone else sucks" attitudes before from forums and fellow programmers and projected that onto your response. Sorry.

Re: The Modern Java Platform – 2021 Edition

#222

Post by ralmidani »

jrochkind1 wrote: post #210
ralmidani wrote: post #194

Earlier quoted context omitted.

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…

I didn’t mean to imply that XML was preferable to YAML. I meant that neither is Turing Complete, so using either for dependencies and config is likely to be cumbersome. YAML looks nicer, and if you’re not using a decent IDE, you’re less likely to mess up with closing tags, etc., but that’s about it.

Re: The Modern Java Platform – 2021 Edition

#223

Post by strictfp »

foo_barrio wrote: post #221
strictfp wrote: post #215

Earlier quoted context omitted.

I'm not refuting that businesses can be complex, but I am saying that most of the complexity I've seen hasn't been inherent to the business.

I understand, I should have been clearer. My experience has been the opposite. The companies I've worked for had actual complexity to tackle. I guess I got a little defensive because I've encountered "game programmers are gods, everyone else sucks" attitudes before from forums and fellow programmers and projected that onto your response. Sorry.

No worries. The gaming industry has its own set of problems for sure, so I'm not claiming it's inherently better in any way :)

I'm glad to hear if your major challenge in the enterprise was to solve actual problems and produce real value. My journey was mostly learning one over-complicated framework after another, and finally coming to the conclusion that it was mostly for nothing. I was the local Spring expert, but at the same it's biggest critic. The "code", or more accurately the configuration, gets very consise, but you risk ending up with only a handful of people in the building who know how to debug the app properly.

I started coding Java when Sun marketed it as a very pragmatic choice, focusing on "simply writing code". The influence of IBM and the whole JEE movement (including Spring) still looks at the problem of coding from the wrong angle IMO.

Creating a good development environment is not about creating a all-in-one runtime environment or methodology, nor about simplifying the problem space for developers by letting them write plugins to large servers.

It's about establishing a fast RAD cycle and offering a buffet of good libraries, to simplify the writing of code.

Java used to be the language which allowed you to "just program", nowadays the mainstream choices are golang or node. To me it's become very clear that Java is on the wrong track here.

There are an infinite number of distractions as a coder, including Microservices, responsive design, functional purity, patterns etc.

If you managed to duck most of these and end up in a place where you were producing value effectively, you were very lucky judging by my experience :)

Re: The Modern Java Platform – 2021 Edition

#224

Post by loic-sharma »

erikds wrote: post #111
sandGorgon wrote: post #61

Really 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.…

Never heard about Graal before. When reading the description it reminds me of WebAssembly. Can anyone compare how they compare?

Yup, they are very similar as both are used to run code at high performance.

WebAssembly was designed for the browser. Users want their websites to load quickly, so startup time is crucial. Also, users want to browse sketchy websites, so security is also crucial. WebAssembly is more like an instruction set for a "fake" CPU. It's very low-level and is not ideal for running high-level languages like Ruby (though it's possible!).

On the other hand, GraalVM isn't constrained by these browser requirements. This lets Graal do nifty tricks so that highly dynamic languages - like Ruby or JavaScript - run as fast as possible.

Re: The Modern Java Platform – 2021 Edition

#226

Post by zmmmmm »

The_rationalist wrote: post #35
galaxyLogic wrote: post #30

Earlier 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…

> Kotlin stands out by being the only language truly seamlessly compatible with Java

Not sure I would agree with that - I think Groovy has at lest as good, maybe even better compatibility than Kotlin.

Re: The Modern Java Platform – 2021 Edition

#227

Post by cryptos »

selfhoster11 wrote: post #142
oweiler wrote: post #59

Earlier quoted context omitted.

I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.

You know what should be taking care of all of these things? Java! For a language that bills itself as the "enterprise language #1", it's abysmal in supporting actual enterprise features like you listed above in a lightweight fashion. Instead, a whole third-party framework has to be tacked on just so you don't have to reinvent the wheel. Java doesn't even support dependency injection, something that I would consider a…

I don't think there is a need to blur the line between a standard library and frameworks. Maybe @Inject should have been in the JDK, but on the other hand it can be added to any project easily and is supported by several frameworks.

In general I think, it is wise to keep the standard library small, because innovations are easier to implement in libraries. Rust is a good example for this style.

Re: The Modern Java Platform – 2021 Edition

#228

Post by wiradikusuma »

rowland66 wrote: post #163
wiradikusuma wrote: post #37

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-sca…

I think that you have the option with Quarkus to use the traditional JVM with byte code for development, and only generate exe's for stage or production deployment. Best of both worlds.

If my experience with cross platforms (flutter, react native, phonegap, and now quarkus) tells me anything, it's to check everything (still) working everywhere after every small changes :)

Re: The Modern Java Platform – 2021 Edition

#229

Post by lmm »

jillesvangurp wrote: post #90
misja111 wrote: post #83

Earlier quoted context omitted.

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…

There's a next stage after annotations. The current thinking is to replace annotations with function calls. It makes more sense if you use Kotlin because Java is a bit verbose when you do this and in Kotlin you get to create nice DSLs. This cuts down on use of reflection and AOP magic that spring relies on and also enables native compilation. It also makes it easier to debug and it makes it much easier to understand…

> Stuff just works with minimal coding and you customise it as needed (or not, which is perfectly valid).

You can't though, because the usual pattern is that the classpath-based self-configurer imports a non-public class that contains all the actual configuration. So you can't customize or extend the autoconfigured version - you have to either accept it as is or replicate the entirety of it from scratch.

Re: The Modern Java Platform – 2021 Edition

#230

Post by lmm »

soco wrote: post #106
eecc wrote: post #89

Earlier quoted context omitted.

That’s all fine and nice, except when the magik doesn’t work and you’re ctrl-clicking for hours trying to figure out what darn annotation is breaking the whole incantation. Or you realize a that the tiny tiny small configuration change you need isn’t contemplated by the code supporting the auto-magik, so you start adding overrides which turn off the autoconf, and you have to manually configure the whole beast by your…

Luckily this doesn't happen all that often. Unfortunately this is gonna happen in every framework. Compromises is what you always get when reusing somebody else's framework/program/anything basically, because use cases are never 100% similar.

A good framework lets you gracefully progress from 100% autoconfigured to 95% autoconfigured, 5% customized to 90% autoconfigured, and so on. It does this by working in a consistent way, where framework-provided defaults behave the same as custom implementations of the same thing, and you can use the same tools and techniques to understand what the framework is doing as you use to understand your own application.

None of that's true of Spring Boot. The autoconfigured stuff comes in in its own fashion that's hard to relate to your normal configurations, and it's encapsulated in such a way that as soon as you want to replace part of it you find you have to reimplement all of it.

Post reply on HN