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

231–240 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#231

Post by lmm »

cryptos wrote: post #227
selfhoster11 wrote: post #142

Earlier quoted context omitted.

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.

If Java had had first-class functions to start with, things like Spring would probably have never got off the ground. Up until Java 8 you couldn't even pass a reference to a constructor as an argument without defining a whole class to carry it around in.

Re: The Modern Java Platform – 2021 Edition

#232

Post by lmm »

sreque wrote: post #144
lmm wrote: post #76

Earlier quoted context omitted.

I disagree with that blog post. It may be technically possible to hijack the classloader mechanism to make instantiating classes do dependency injection, but it's not easy or idiomatic, and it's not good for maintainability either; a reader can't tell the difference between a global service and a value object if both are just "new Foo()". DI, in the sense of separating the instantiation of long-lived service objects…

In response to: "DI, in the sense of separating the instantiation of long-lived service objects from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability." You don't need a DI framework to do any of what you described. Also, I believe that what you are saying doesn't fundamentally describe DI, though it is related. In this post I go…

Your blog post is, frankly, wrong. That's not what DI is usually used or understood to mean.

Re: The Modern Java Platform – 2021 Edition

#233

Post by lmm »

doctor_eval wrote: post #213
foo_barrio wrote: post #196

Earlier quoted context omitted.

I had this experience with the so-called "app servers" at our company. We also have a daily batch processing system has tons of operational support, db+serivice monitoring, a very useful web UI, logging split out, authorization system etc. It's built around common Nix concepts like files, pids, pipes, etc. Thousands of these batch jobs are little JavaSE programs that launch, do their business, record their progress a…

Yeah your experience absolutely mirrors mine. Don’t even get me started on JPA; I’ve used exactly the same phrasing you did: when you use JPA, now you have to know SQL, JPA and JQL. It makes no sense!

Heh, I found the opposite. JPA is one of the few parts of the ecosystem that actually work and deliver enough value to be worth it.

Re: The Modern Java Platform – 2021 Edition

#234

Post by lmm »

a_imho wrote: post #114
lmm wrote: post #21

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

I simply don't understand how people favor a stringly typed custom DSL in a reasonably typed language like java. Why is it better to write Spring annotations instead of actual java code? There is literally no upside.

Annotations are fairly typesafe. The parts that aren't safe are parts that Java offers no way to do at compile time (e.g. "are all the arguments to this constructor of types that are in this set of existing services?")

Re: The Modern Java Platform – 2021 Edition

#235

Post by lmm »

jrochkind1 wrote: post #151
lmm wrote: post #21

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

> 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 What does "decoupled" even mean anymore? That sounds like the opposite of "decoupled" to me. (/not a Java programmer).

The logic seems to be that having X use Y if it's available at runtime is less coupled than having X hard-depend on Y at build time. But IME the end result is similar to a "distributed monolith": you haven't actually decoupled it, you've just swept the coupling under the rug.

Re: The Modern Java Platform – 2021 Edition

#236

Post by The_rationalist »

zmmmmm wrote: post #226
The_rationalist wrote: post #35

Earlier quoted context omitted.

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.

Interesting, I don't know groovy much but Kotlin has two major points in addition to interop it has idiomatic interop:

1) The kotlin standard library is the Java standard library.

2) kotlin feel similar with Java and has analogues to almost every Java feature e.g SAM conversions.

The fact that groovy is dynamic make much less suitable for hybrid code bases (half Java half X)

Re: The Modern Java Platform – 2021 Edition

#237

Post by [deleted] »

sz4kerto wrote: post #54
lmm wrote: post #21

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

There's a very good reason why Spring is used so widely. Complex enterprise apps are often complex because the use case and the environment is complex. E.g.: - integration testing and unit testing is required - transparently pluggable backends for message queues so that locally you can use SQLite as your pub/sub storage but in production it's Google P/S - standardized health check endpoints for all your apps ... The…

[deleted]

Re: The Modern Java Platform – 2021 Edition

#238

Post by jillesvangurp »

lmm wrote: post #229
jillesvangurp wrote: post #90

Earlier quoted context omitted.

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.

You can disable configuration classes and then set things up manually. I did this recently with the mongo driver.

Re: The Modern Java Platform – 2021 Edition

#239

Post by lmm »

jillesvangurp wrote: post #238
lmm wrote: post #229

Earlier quoted context omitted.

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

You can disable configuration classes and then set things up manually. I did this recently with the mongo driver.

Right, but you can't customise the automatic config. It's all or nothing - you have to either use the whole autoconfig as-is or reimplement everything that it does yourself.

Re: The Modern Java Platform – 2021 Edition

#240

Post by Cullinet »

chris_wot wrote: post #77
avodonosov wrote: post #73

Earlier quoted context omitted.

Typo :)

Also amazing new pejorative.

ah, I am promoted thus to reminisce upon my boolshitten youth spent vainly stabbing out crud most fervid and amorous to dump the vilest cores to jest with that naivest child me to know it better than to presume that my brittle logic could affect it so profoundly to do my bidding...
Post reply on HN