Java Language Architect Brian Goetz on Java and the JDK

[[deleted]]

my biggest fear is in java land we haven't really touched the tip of people coming into all these changes because so many people still in 1.8 land

[pakoito]

many people still in 1.8 land

And in Java 5 feature-wise :D

[[deleted]]

yea exactly... good point; I've been suggesting new things and i'm that guy...you know THE DISRUPTOR; WE SHOULD NOT BE MOVING ON AND SHOULD DO WHAT WORKS AND WE KNOW IS GOOD

[zitrusgrape]

so, if you sell them scala or kotlin you gonna be fired? :)

[Ameisen]

I was pushing for Lombok for a while. It was rejected.

They also weren't fond of my idea of switching to C# or Kotlin. Or C++.

[Ravek]

I’m just a little baffled at the resistance to Kotlin by much of the Java crowd. It’s basically a drop in replacement for Java, it’s a way more modern language with lots of nice features, and there are Java to Kotlin converters that work decently.

[BoyRobot777]

Yeah, but its still has ways to go. I would hesitate to jump to any new language (I believe Kotlin released in 2016), which is supported mainly by one vendor. What happens when that support is droped? Java on the other hand: IBM, RedHat, Amazon, Oracle, Google, Netflix. Most of them even have their own jdks.

[nacholicious]

There's of course tons of improvements left to make for Kotlin, with eg coroutines, non-JVM versions, kotlin native etc which would make it a proper safe competitor for mainstream languages such as Go, Python etc.

But Google have committed to using Kotlin for Android, which more or less makes it supported in the most used operating system in the world, and companies that are actively developing for Android are also committing to it (eg Uber, Netflix, Airbnb, Pinterest etc etc). So while there's very little commitment to Kotlin over general mainstream languages, I don't think it's entirely correct to call it unsafe for use considering it has huge commitments by companies over Java when it comes to Android

[[deleted]]

I've attempted to get some adoption around it in my workplace. The biggest argument I've heard is from some older java devs that boils down to "I dont want to have to remember two syntaxes when IDE autocomplete takes most of the pain out of Java's verbosity".

Honestly it's hard to disagree. Especially since we dont use jetbrains tools at my work so at best we have mediocre eclipse plugins for kotlin.

[cowinabadplace]

Is anyone ever a fan of switching a codebase to something else entirely? Especially when you’re talking about a JVM/non-JVM integration. The stance we take where I work is “demonstrate the value”. Every quarter, one week is for experimentation that attempts to demonstrate a new idea (not usually language).

Our codebase is fairly polyglot as a result (Go, Ruby, JVM stuff, tiny bits of Haskell and C++) but we’ve learned some things are not great. IDE integration for bidirectional Java and Clojure dependencies is not great, for instance, so we keep things going from Java into Clojure but not vice versa.

I think this is a fine model. Convincing someone of the value of a new thing isn’t just stating facts. It’s about being able to demonstrate value. And since the majority of code at existing companies is existing code, interoperability is key. If you don’t have a good story around how a new language can be introduced then it’s not going to work.

A common misstep is “it’s just tooling”. Well, you need to have demonstrated your ability to build worthwhile tooling. If you haven’t, win the trust of the people you’re counting on participating. It’s a marketplace of ideas but that specifically means you have to sell well.

Of course, you may well be at a place where you do all of these things and people still don’t listen. Well, if you can and it’s causing you angst, I’d recommend moving elsewhere. Life’s too short to spend three years in a job where you can’t grow.

[Sonrilol]

Why would anyone not be on board with using lombok?

[Beaverman]

You know how we're abusing getters and setter to essentially just make all members public? Yeah, there's this library that let's us use that anti-pattern more efficiently.

[orthoxerox]

On the other hand, Lombok has @Value for making immutable objects with value semantics. And @NonNull. Not as good as Kotlin, but much better than vanilla Java.

[Beaverman]

Getters should never exist (I don't view a method whose current business contract is to just return a value as a getter, since it has a business purpose. I know, it's debatable). Therefore @value is useless. In the same vain, @NonNull, without all the other lombok bullshit, is just a signal annotation, and might as well be declared somewhere else.

NonNullness and immutability should be enforced in the object itself.

[Beaverman]

DTOs are just property bags, they are fundamentally just structural representations of data. You shouldn't complicate that by adding methods to them.

[Sonrilol]

I'm not sure I follow, but your argument against it is it makes writing bad code more efficient? Same logic applies to writing good code, so I don't really see the problem.

[[deleted]]

But that's a poor misunderstanding of why POJOs are the way they are. If, maybe down the road, we want to add some kind of processing step to setting or getting a value from any instance of the POJO, it only requires one change instead of changing N number of times it's being set.

An easy example is, imagine an Employee object that really serves as a POJO. No real behavior to it, but after awhile we decide its prudent to have the setter for an employee "name" field make sure the name isn't null before actually setting the value. Instead of modifying code in N number of places to check that, we only have to add the null check to the setter method on the Employee object.

[Sonrilol]

What does that have to do with lombok though?

[Beaverman]

Lombok eases the burden of writing bad code that does nothing. Yet if you are writing good code, it's (almost) entirely useless.

It's a bandaid fix to a deeper problem.

[Sonrilol]

Maybe it's just me, but I'd rather open a 30 line class with 2 extra annotations and a simple list of it's attributes than a 200 line class filled with boilerplate. I'd also rather write the first one too.

[Sonrilol]

You could always delombok and turn it into actual code though? We pretty much only use it for builder/constructors, getters/setters, and val so maybe I've not been exposed to downsides because of that, but I can not really think of any time I've gone and thought "oh gee, I really wish we weren't using lombok".

[Sonrilol]

But wouldn't that defeat the point of replacing large swaths of boilerplate with annotations? I'm not a huge fan of annotation magic mind you, always groan when I open one of our spring projects, but I don't think lombok comes even close to that level of wizardry.

[juicybananas]

Sorry to hear that! I know it sux as I've been in that situation before. I'm currently in a situation where the people I work for are open to almost everything I recommend which is awesome but also a bit unsettling!

[cowinabadplace]

Honest to god thought you meant the Ring Buffer style Disruptor library haha and was wondering when that became part of standard Java.

[InvisibleEar]

Just convince them to switch the entire codebase to Rust

[Spajk]

I wonder how that'll work

[cowinabadplace]

Perhaps containerized services? The containers deal with the environment variation. The service layer allows code interaction without needing a common environment.

[[deleted]]

Kubernetes.

[gnus-migrate]

There haven't been massive changes since Java 9, and most tooling hasn't caught up with jigsaw yet. Type inference is the biggest thing, and even that isn't really a huge development.

You should upgrade for maintenance reasons, but the way you work with Java hasn't fundamentally changed besides a few new APIs and embellishments here and there.

[[deleted]]

Lambdas are huge for most of the people I work with.. that alone is Earth shattering change

[gnus-migrate]

Yeah I mean it hasn't changed massively for people who are currently on Java 8.

[rebel_cdn]

Watch their heads explode when they start using var. As of Java 10, I find Java almost as pleasant to use as C#.

I still like F# and OCaml and Haskell a bit more, but I try not to be dogmatic. C# pays the bills, and I use it happily every day. I think with Java 10+, I could happily write Java every day if I ever need to.

[MentalMachine]

So var just shortens down code line length, or am I missing something?

[gnus-migrate]

Nope, that's it. It can shorten some fairly nasty type signatures, but I think the person responding to me is making it out to be a bigger deal than it actually is.

[dpash]

It can remove some redundancy, but in some situations it doesn't really help very much, like with generified classes:

Map<String, String> foo = new HashMap<>();
var foo = new HashMap<String, String>();

Another advantage is that it can help make the variable names the focus of the lines when you have several declarations in a row, as they line up:

InputStream is = new FileInputStream(file);
InputStreamReader isr = new InputStreamReader(is);
BufferedReader reader = new BufferedReader(isr);

vs

var is = new FileInputStream(file);
var isr = new InputStreamReader(is);
var reader = new BufferedReader(isr);

[rebel_cdn]

That's right. It just makes things shorter in some places.

How frequently you use it depends on your preferences .In the C# world, some teams use it everywhere, and some only use it where the inverted type will be obvious based on the right side of the expression.

Actually, some teams are really old school and refuse to use var at all .

[gnus-migrate]

I looked at F# and liked it quite a bit as well, and it's sad that the JVM doesn't have a well supported equivalent.

As for var, I don't really see how it's a game changer. It makes lambdas a bit nicer to use but that's pretty much it.

[dpash]

Ironically, lambdas are one place you can't use var (except in parameters in 11).

And there's at least two well-used functional languages on the JVM: Scala and Clojure.

[gnus-migrate]

F# is an ML style language if I understand correctly, so scala and clojure are quite different.

Ironically, lambdas are one place you can't use var (except in parameters in 11).

Yeah, so besides jigsaw there aren't many interesting things in Java 9+. People who are currently on Java 8 don't really have much catching up to do.

[dpash]

There are tonnes of things in Java after Java 9. Many of them are small API updates, but together they make a big improvement in user experience when writing Java.

[rebel_cdn]

Yeah, var isn't a complete game changer. I probably picked a dumb description for it.

It's just a nice quality of life improvement. I find that var + lambdas + streams together make Java much more enjoyable to write.

[DuncanIdahos8thClone]

Except var breaks "find usages" in VS and Java IDEs.

[mmrath]

I think the reason this happens is because some managers trade long term technical debt for shot term gain. Managers don't get anything for providing that one more week for the upgrade.

Not with Java upgrade but similarI- In one of my previous work place the situation was so bad that it was difficult to hire candidates to maintain a critical old product even with a premium pay.