Java Language Update – a look at where the language is going by Brian Goetz

https://www.youtube.com/watch?v=bKwzONOGLxs

by belter • 2 years ago

83 56 2 years ago

21:48 the reasoning is facinating. "OOP thrived in an age of monoliths. But program units are getting smaller. They don't need as many internal boundaries. They are often coupled by less strongly typed schema."

symaxian• 2 years ago

I understand where he's coming from, but on the other hand it sounds like he's trying to avoid saying "maybe that OOP thing isn't all it was cracked up to be".

Pet_Ant4• 2 years ago

I think that is more descriptive and less prescriptive.

I’ve never seen a codebase ever really use OOP in an enterprise setting. Just spaghetti and meatballs architecture. Meaty god objects “services” with long strings of structs.

belter3• 2 years ago

Or more about boundaries, like in less Monoliths, and more micro services and container deployments including cloud functions like AWS Lambda and Azure Functions. And "coupled by less strongly typed schemas" is more of a fact statement, but is it really a good thing?

Software Engineering will not progress into real Engineering, until it starts building on the past instead of throwing away past lessons. OO was about many things but particularity about code reuse. Is that also a bad thing?

DarkNova6• 2 years ago

I think you are misrepresengin Goetz slightly. He said "OOP was necessary in the time of Monoliths because they erect clear boundaries".

lolinder3• 2 years ago

I haven't had a chance to listen, but if he said those exact words they certainly seem to imply the rest of what OP said.

EDIT: I have now listened, and I'm with OP on their interpretation. Goetz doesn't say the exact words that OP used, but he definitely expresses each idea and means what OP says he means.

rlawson• 2 years ago

I don't like Oracle very much but I have to say I appreciate the rate at which Java has improved

rcaught• 2 years ago

Appreciate Kotlin and others pushing it there.

kaba02• 2 years ago

Yeah, the ant pushing the elephant..

halfmatthalfcat• 2 years ago

Scala, especially

The_Colonel3• 2 years ago

Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases.

JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.

elric• 2 years ago

Thankfully, the Java Community Process works pretty well, and it's not just Oracle pulling the strings. JEPs and JSRs are the primary drivers of Change in the Java world, and they are largely driven by the Java Community Process and its many members.

shellac• 2 years ago

It's working out well as a 'forever' language: I can understand and use java code from the dawn of time (aka late 90s, but more realistically 1.5, 20 years ago), and Goetz seems to being doing well keeping that going. The challenge is adding any new features, but they are maintaining a reasonable cadence.

At some point I imagine they will have to remove or at least isolate and disarm some ubiquitous core features (e.g. serialisation and synchronisation).

MrBuddyCasino2• 2 years ago

The hypothetical return type for Future using ADTs was interesting - this seems almost Rust-ish. The distinction between a return Value and an Exception really is often unnecessary and complicates things.

jayceedenton• 2 years ago

I struggle with this one because exceptions are a perfectly good solution. The compiler will tell you when you are not handling a failure case. And if exceptions are unchecked, then you won't get a compiler warning but at least failures will be obvious at runtime.

Why push java towards this 'failures as return values' when we already have a solution? Yes, you will be able to get the compile-time safety by immediately using switch on the return value, but what if you don't? Exceptions are a completely sound solution, failures as return values can easily escape detection.

No-one likes having to think about the error cases, it feels like it complicates things. But we need to stop seeing exceptions/try/catch as something to eliminate and realise that this approach is one of the best innovations of Java. Using return values, or monadic approaches to error handling, are fundamentally unsafe when you have a mixed paradigm language. Far too easy for the programmer to do something wrong, so we're relying on discipline again and not the compiler. In other words, back to square one.

gergo_barany2• 2 years ago

Yes, you will be able to get the compile-time safety by immediately using switch on the return value, but what if you don't?

Then you switch on the value at some other point in time. It's still AsyncReturn<V>. Why do you think safety would get lost?

Exceptions are a completely sound solution, failures as return values can easily escape detection.

How so?

Java Language Update – a look at where the language is going by Brian Goetz

Related Stories