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

New language features since Java 8 to 17

advancedweb.hu

Post reply on HN
Print view View original

321–330 of 358 posts

Re: New language features since Java 8 to 17

#321

Post by jcelerier »

filoeleven wrote: post #226
jcelerier wrote: post #198

Earlier quoted context omitted.

> Once you know that “Java says X is the first day of the week,” The basic assumption when designing anything is that you can never rely on assuming that other humans "will" know.

Sure, but how far does that go? If I try to assign an int value to “3.2” will the language silently fail with null, or a round, or a floor, or a ceiling? Some level of understanding is necessary. I want it to also be reasonably explicit. Java time library doesn’t meet that standard until Instant.

> If I try to assign an int value to “3.2” will the language silently fail with null, or a round, or a floor, or a ceiling?

one may argue that the only correct thing to do here is a compile-time error

Re: New language features since Java 8 to 17

#322

Post by dmitriid »

pron wrote: post #320
dmitriid wrote: post #297

Earlier quoted context omitted.

But on the other hand you have object initializers directly in the language In Java you have one of these: - a hope that someone provided a useful static `.of` method - a hope that someone provided the 15000 setter methods that you have to tediously invoke one by one - a hope that someone provided a generator that created a builder that has 15000 setter methods that you have to tediously invoke one by one Meanwhile i…

Easier construction for records will come to Java. As with most Java features, it will come once it's been carefully considered, and done in a way that gives the most bang for the buck (e.g. we do want easier object construction, but if we add a feature for that, we'll try to get more than just easier object construction out of it). > And don't get me started on array vs list vs collections none of which are compatib…

> Easier construction for records will come to Java.

Once again: when?

And why only records? Why does everything in java require someone to manually create an .of method, or create 15000 setter methods or generate those 15000 setter methods?

> This is not true. Lists are collections, and while arrays are different,

I remember running into an issue with the difference, but can't remember now. Quite possible it was an artefact of an early implementation.

> Arrays.asList() gives you a list view of arrays.

Yup. One of the hundreds papercuts that litter Java.

C#:

    var list = new List()
    {
        "carrot",
        "fox",
        "explorer"
    };

    var array = new string[]{ "carrot", "fox", "explorer" };

    ... use whatever IEnumerable methods on both ...
Java:

Ahahaha. No. For lists use a static .of method and be glad that someone manually wrote that in the library. And be thankful that there's some shortcut to create an array. But for Lists? eff off, no shortcuts for you.

Oh you want convenience methods on arrays? Ahahaha, no. Use a separate helper to convert into a list first. (This is so bad that IDEA suggests some version .toList as the first method on I swear 90% of array/collection/list/stream operations).

Because, as someone said, "our goal isn't to adopt the strategy of less successful products, but to forge our own".

I'm really surprised records made it into the language with this approach to things.

Edit: Note: Ii use Java and C# interchangeably at my day job. Man is C# a nicer language with literally hundreds of QoL improvements that make you scream "why didn't Java adopt these?" I still reach for Java as I'm more comfortable with it and it has an unparalleled breadth of libraries.

But every time I need to write or implement and write another X.builder().setX.setY.setZ.build() instead of `new X { x=.., y=.., z=.. }` I want to claw my eyes out.

Re: New language features since Java 8 to 17

#323

Post by The_Colonel »

Twisol wrote: post #288
kaba0 wrote: post #286

Earlier quoted context omitted.

I think what op meant is that dependency injection is type safe, in that in case of going through a constructor, they have to indeed type check with the dynamically provided instances.

(I got lucky and spotted this reply instantly; I promise I wasn't lurking waiting for a reply.) Don't dynamic DI frameworks like Spring use runtime reflection to invoke such constructors? If a bug existed in Spring causing a value of the wrong type to be provided, I expect it would go undetected until runtime, at which point Java will throw an exception. My understanding of "type safe" is that the code is statically…

Yes, that's the case in Spring.

But there are DI containers which are statically safe, e.g. Dagger.

Re: New language features since Java 8 to 17

#324

Post by Skinney »

Twisol wrote: post #290
Skinney wrote: post #257

Earlier quoted context omitted.

Really? They’ve already written the JEPs. It seems to me that they just have a few more details to iron out. Wouldn’t be surprised to see something land for Java 19.

I'd definitely be curious about which signals you're drawing on. From what I've seen, the Valhalla OpenJDK wiki has gone without update for quite some time, and even that wiki refers to JEP 169 ("Value Objects") as old. I do get the feeling that there's activity, given that JEP 416 is targeted for Java 18 and specifically refers to Valhalla (and Loom) as benefactors of the proposal, and seeing as the mailing list is…

JEP 401 (candidate status) was updated this september: https://openjdk.java.net/jeps/401

Also in September, a brief status was posted: https://mail.openjdk.java.net/pipermail/valhalla-spec-observ...

Re: New language features since Java 8 to 17

#325

Post by pron »

dmitriid wrote: post #322
pron wrote: post #320

Earlier quoted context omitted.

Easier construction for records will come to Java. As with most Java features, it will come once it's been carefully considered, and done in a way that gives the most bang for the buck (e.g. we do want easier object construction, but if we add a feature for that, we'll try to get more than just easier object construction out of it). > And don't get me started on array vs list vs collections none of which are compatib…

> Easier construction for records will come to Java. Once again: when? And why only records? Why does everything in java require someone to manually create an .of method, or create 15000 setter methods or generate those 15000 setter methods? > This is not true. Lists are collections, and while arrays are different, I remember running into an issue with the difference, but can't remember now. Quite possible it was an…

> Once again: when?

When it's ready. Again, because of Java's position, we aim for features that will work well for decades rather than those that will grab some more users now. I know this is hard for some to understand, but the main complaint we're getting is that Java is getting too many features too quickly, not the other way around. The people who like lots of features are a minority; a large one, but still a minority. Whether we add a feature or don't add it, some people will be disappointed. It's impossible to please everyone, so we try to please the majority.

> Ahahaha.

    var list = List.of(
        "carrot",
        "fox",
        "explorer");

    var array = new String[]{"carrot", "fox", "explorer"};
This is not where we think the language's complexity budget is best spent. When we do add a feature to the language, we want it to have much more bang than that. Those who like lots of features don't like that but, again, they're the minority. I cannot stress enough how much people hate language features. Language features don't have Javadoc, and people have to learn them. If they have to go and learn a new feature, they expect it to be worth it.

> I'm really surprised records made it into the language with this approach to things.

You mean the approach that has consistently made Java so successful? We try to add as few features to the language as we can afford to, which means that we make the features we do add extra powerful. This gives us room to add some of the features people will be asking for in ten years, rather than waste all of the complexity budget now.

> "why didn't Java adopt these?"

Because Java's strategy is different, and it's working better.

> But every time I need to write or implement and write another X.builder().setX.setY.setZ.build() instead of `new X { x=.., y=.., z=.. }` I want to claw my eyes out.

With that I completely agree, which is why we'll address that.

Re: New language features since Java 8 to 17

#326

Post by dmitriid »

pron wrote: post #325
dmitriid wrote: post #322

Earlier quoted context omitted.

> Easier construction for records will come to Java. Once again: when? And why only records? Why does everything in java require someone to manually create an .of method, or create 15000 setter methods or generate those 15000 setter methods? > This is not true. Lists are collections, and while arrays are different, I remember running into an issue with the difference, but can't remember now. Quite possible it was an…

> Once again: when? When it's ready. Again, because of Java's position, we aim for features that will work well for decades rather than those that will grab some more users now. I know this is hard for some to understand, but the main complaint we're getting is that Java is getting too many features too quickly, not the other way around. The people who like lots of features are a minority; a large one, but still a mi…

> When it's ready.

So, I'm likely to be dead by then.

> You mean the approach that has consistently made Java so successful?

Why are you adding all these features from all these "non-successful languages" then?

Why is it that dealing with long chains of setter methods isn't "spending complexity budget" and is a "feature more bang than that" (whatever "that" is), but adding literally the same thing: better ways of working with collections is "no, we don't adopt features from less successful languages".

Re: New language features since Java 8 to 17

#327

Post by pron »

dmitriid wrote: post #326
pron wrote: post #325

Earlier quoted context omitted.

> Once again: when? When it's ready. Again, because of Java's position, we aim for features that will work well for decades rather than those that will grab some more users now. I know this is hard for some to understand, but the main complaint we're getting is that Java is getting too many features too quickly, not the other way around. The people who like lots of features are a minority; a large one, but still a mi…

> When it's ready. So, I'm likely to be dead by then. > You mean the approach that has consistently made Java so successful? Why are you adding all these features from all these "non-successful languages" then? Why is it that dealing with long chains of setter methods isn't "spending complexity budget" and is a "feature more bang than that" (whatever "that" is), but adding literally the same thing: better ways of wor…

> Why are you adding all these features from all these "non-successful languages" then?

The issue isn't the features themselves but the evolution strategy. Sure, we've been adopting most of the features added to Java since 1995 from ML (1972-3) and we're nearly done, but what we don't adopt is the approach of adding lots of features that each help a little. We like few features that help a lot.

> Why is it that dealing with long chains of setter methods isn't "spending complexity budget" and is a "feature more bang than that" (whatever "that" is), but adding literally the same thing: better ways of working with collections is "no, we don't adopt features from less successful languages".

We don't adopt an evolution strategy -- not features -- from less successful languages just because they're doing it. Java's strategy has been to innovate quickly on the VM (and we're innovating there more than anyone else, I think), and keep the language relatively conservative and relatively slow-moving. And it seems that more people like it this way. For the others, we make sure that the platform supports a choice of more feature-rich languages with good interop.

But the answer to your question is that we're trying to add as few features as we can (to leave room for growth in the futures, as requirements and fashions change again) and we believe that the features we do add help more than the ones we don't. Still, at the end of the day, there's hardly ever consensus among developers on anything. Whatever we do or don't do, some people won't like it. What's important to remember is that even if in some cases you don't agree with the language team's decisions, they are among the most experienced and successful language design teams in the history of software (I can say that because I'm not on the language team). They might make mistakes from time to time, but overall, they know what they're doing. In any event, the argument that millions of people prefer Pepsi to Coke is not the one that will convince Coke to change its flavour to that of Pepsi, because even more people prefer Coke.

Re: New language features since Java 8 to 17

#328

Post by pron »

dmitriid wrote: post #318
pron wrote: post #312

Earlier quoted context omitted.

The gap between Java and C# has grown very slowly but surely for many years, and more people feel Java is changing too quickly than too slowly. Different people prefer different things, some will always prefer Pepsi (although C# will probably not be that Pepsi, as it's lost too much ground and MS seems to be losing interest in it, as they tend to do), and our goal isn't to adopt the strategy of less successful produc…

> it's lost too much ground and MS seems to be losing interest in it wat > our goal isn't to adopt the strategy of less successful products This sounds like "we don't care if some other languages have great quality of life improvements, we pretend that success (for some unknown definition of success) is the only thing that matters, so we'll keep implementing one or two features every 10 years that don't work with hal…

> wat

Their focus seems to have shifted to TypeScript, and that's understandable as they have far better chances for success there. Their best hope for .NET was to make it the Pepsi to Java's Coke, but that hasn't materialised (in fact, it's getting further away). .NET has not been anywhere near the go-to alternative choice for people who just don't want Java for one reason or another in years.

> This sounds like "we don't care if some other languages have great quality of life improvements

I'm sorry it sounds that way to you. It means, "we understand that some portion of developers prefer more features, but we cater to the majority, and, given that Java has a very long future, we'd rather pace ourselves." For the quick-feature-loving minority -- which we also care about -- we make sure the platform can host more feature-rich languages that interop well.

> It won't, not for another ten years.

You're very wrong about that. Remember that only five years ago, Java didn't have var, didn't have switch expressions, didn't have text blocks, didn't have records, didn't have sealed classes, and didn't have pattern matching. More people complain that Java is getting new features too quickly than too slowly.

> Wait. Those come from less successful languages. How could you?

It's not that we don't adopt features from less successful language; it's that we don't copy their evolution strategy. Our goal isn't just to make sure Java is very popular now, but also that it's very popular ten and even twenty years from now. This means that we have to budget language complexity very carefully. We also have the new developers learning Java in 2035 to think of.

Re: New language features since Java 8 to 17

#329

Post by jmfldn »

frant-hartm wrote: post #261
jmfldn wrote: post #136

Earlier quoted context omitted.

It's not in decline imho, it has settled as middle ranking language in terms of popularity and is v popular in its niche. It depends where you are of course but in London it's used in loads of places from major corporations to startups. The market is hot.

I used to contract in London, I still occasionally get info about contracts from recruiters, Kotlin largely replaced Scala, compared to 5 years ago.

Kotlin is growing for sure on the server side. Far from replacing it though.

Re: New language features since Java 8 to 17

#330

Post by bradleyjg »

kjeetgill wrote: post #219
bradleyjg wrote: post #190

Earlier quoted context omitted.

No. You can’t make an ArrayList at all. You can make an ArrayList and trust the JVM to optimize as it may or you can use c++.

You can mostly trust the JVM to not optimize this the way you'd want for primitives. ValueTypes are int he works though, and using a supplementary library for primitive specialization like Trove or fastutil have become the norm for now. Not ideal, but tolerable!

If your application needs that kind of control, use a more suitable, lower level language. If you just want that level of control for aesthetic reasons, get over yourself.
Post reply on HN