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

241–250 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#241

Post by cryptos »

lmm wrote: post #231
cryptos wrote: post #227

Earlier quoted context omitted.

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.

But first-class function is a completely different thing than dependency injection (DI). Supporting functional programming is a an aspect of the programming language itself, while DI is part of the infrastructure.

I agree with you, that Java should have had first-class function from day one. Ironically this was considered by the language designers, but they decided that it would be too exotic for the average Joe. OOP was a hype back then ...

Re: The Modern Java Platform – 2021 Edition

#242

Post by lmm »

abledon wrote: post #176
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…

One power of Spring Boot , non-xml based code is using an IDE like intelliJ for refactoring/navigation. XML is hard to refactor/navigate if you're dealing with 1000s of files.

You don't need Spring Boot for that. You can use plain Spring with annotation-based config, no XML needed. And your IDE navigation will work, whereas with Spring Boot it frequently finds the wrong bean definition because of all the dynamic magic (ConditionalOnClasspath, ConditionalOnMissingBean etc.).

Re: The Modern Java Platform – 2021 Edition

#243

Post by holografix »

pjmlp wrote: post #169
holografix wrote: post #135

Earlier quoted context omitted.

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.

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.

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

Re: The Modern Java Platform – 2021 Edition

#244

Post by lmm »

cryptos wrote: post #241
lmm wrote: post #231

Earlier quoted context omitted.

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.

But first-class function is a completely different thing than dependency injection (DI). Supporting functional programming is a an aspect of the programming language itself, while DI is part of the infrastructure. I agree with you, that Java should have had first-class function from day one. Ironically this was considered by the language designers, but they decided that it would be too exotic for the average Joe. OOP…

DI is a design technique, you don't have to use a framework to implement it. Reflection-based frameworks became a popular way of doing it in Java because doing it in plain Java is cumbersome, and that's due to the limitations of Java as a language.

Re: The Modern Java Platform – 2021 Edition

#245

Post by dfacastro »

holografix wrote: post #135
jlward4th wrote: post #125

Earlier quoted context omitted.

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.

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.

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.

Re: The Modern Java Platform – 2021 Edition

#246

Post by TobySKT »

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

Re: The Modern Java Platform – 2021 Edition

#247

Post by tatersolid »

syjer wrote: post #91
eecc wrote: post #85

Earlier quoted context omitted.

> Complex enterprise apps are often complex because the use case and the environment is complex. Uh maybe... the real question is where does that complexity come from. Is it intrinsic to the problem or just bureaucratic slob? Given a framework so popular, what are the incentives to go uphill and challenge assumptions - with the likely risk of being fired - or just concede and ad your little contrived contribution to…

From my experience, enterprise apps are generally complex because they are a combination of: - environment: integration of a large amount of services - and a good amount of them are legacy and idiosyncratic - use case: enterprise app are at the intersection of real life and the virtual world: the rules are messy, illogical and have a baggage of 20/30+ years. Thus they cannot be changed at all. This is IMO the main di…

> use case: enterprise app are at the intersection of real life and the virtual world: the rules are messy, illogical and have a baggage of 20/30+ years. Thus they cannot be changed at all.

This is in my experience exactly the problem. They can be changed and should be changed as it would save everyone boatloads of time and money. Engineers need to advocate these business process simplifications, and managers need to illustrate the ROI of making such simplifications.

One has to challenge nonsensical requirements: it’s a critical part of engineering.

Re: The Modern Java Platform – 2021 Edition

#248

Post by dmitryminkovsky »

gred wrote: post #198
dmitryminkovsky wrote: post #8

Earlier quoted context omitted.

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.

I'm hoping to skip modern (i.e. reactive) and go straight to post-modern (i.e. Loom).

Post-modern, pre-future

Re: The Modern Java Platform – 2021 Edition

#249

Post by diroussel »

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…

The real thing that is missing is a runtime annotation scanning API.

Spring does this my examining the class path, casting it to a urlclasspath, finding all the zip/jar files, unzipping them and then parsing the byte code.

Interestingly the set let spec added annotation scanning too. And now if your not careful you jar files get extracted three times. The JVM, the server conteainer and spring all repeating the same work.

No wonder people think java is slow to start up.

Re: The Modern Java Platform – 2021 Edition

#250

Post by diroussel »

codr7 wrote: post #23
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…

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.

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.
Post reply on HN