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

Java 16

jdk.java.net

Post reply on HN
Print view View original

61–70 of 327 posts

Re: Java 16

#61

Post by T-zex »

dweekly wrote: post #48
mdm12 wrote: post #27

Earlier quoted context omitted.

We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc. While it's good for C#/Java, it does make it harder to push for adoption for a language such as Scala and F#. Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?

Really sorry to ask the dumb question here, but what is V9? A cursory Google search didn't show me anything about e.g. a major update to the V8 JavaScript engine? UPDATE: Ah, C# v9.0 thank you all.

it is a C# language version. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

Re: Java 16

#62

Post by [deleted] »

dweekly wrote: post #48
mdm12 wrote: post #27

Earlier quoted context omitted.

We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc. While it's good for C#/Java, it does make it harder to push for adoption for a language such as Scala and F#. Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?

Really sorry to ask the dumb question here, but what is V9? A cursory Google search didn't show me anything about e.g. a major update to the V8 JavaScript engine? UPDATE: Ah, C# v9.0 thank you all.

[deleted]

Re: Java 16

#63

Post by bartvk »

Erlangen wrote: post #14
java-man wrote: post #3

Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?

It's the same story in C++, co_await, co_yield. The sole purpose is not to break other people's code.

Whenever Swift adds a new keyword, they just add it and break everyone’s code. They do provide migration tools in Xcode though.

Re: Java 16

#64

Post by dadoge »

meddlepal wrote: post #20
dadoge wrote: post #12

Very cool to see that Scala continues to have a huge impact on Java’s roadmap. Records and Sealed Classes are borrowed from Scala. Could be not the best news for new Scala adoption, but good news for developers having better abstractions in Java Edit: Kotlin, and other languages should also mentioned since they also include similar features. I still think Scala has had the most influence over the years.

I think the reaction has been more to Kotlin than Scala.

I’m more a Scala dev than Kotlin

Think it’s safe to say both influenced Java’s Record, shoulda mentioned Kotlin too.

Re: Java 16

#65

Post by bartvk »

avodonosov wrote: post #53

The language is getting fragmented: value-based classes, records. I wish the features were introduced still keeping one kind of objects, instead of splitting the universe into 3 kinds of objects (usual objects, value-based objects, records). The feature I am awaiting most is the Project Loom.

What’s the use of forcing everything to be an object?

Re: Java 16

#66

Post by url00 »

dweekly wrote: post #48
mdm12 wrote: post #27

Earlier quoted context omitted.

We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc. While it's good for C#/Java, it does make it harder to push for adoption for a language such as Scala and F#. Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?

Really sorry to ask the dumb question here, but what is V9? A cursory Google search didn't show me anything about e.g. a major update to the V8 JavaScript engine? UPDATE: Ah, C# v9.0 thank you all.

C# 9.0: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

Re: Java 16

#68

Post by Decabytes »

dadoge wrote: post #12

Very cool to see that Scala continues to have a huge impact on Java’s roadmap. Records and Sealed Classes are borrowed from Scala. Could be not the best news for new Scala adoption, but good news for developers having better abstractions in Java Edit: Kotlin, and other languages should also mentioned since they also include similar features. I still think Scala has had the most influence over the years.

This is why it's so important to have different programming languages! Sometimes it's hard to do things differently when you are just looking at your own programming language, and the tools it has available to it. Not everyone programming language needs to be a behemoth to be useful to other people. I say keep making new an interesting programming languages! It will only lead to better programming languages over all

Re: Java 16

#69

Post by BoyRobot777 »

JCWasmx86 wrote: post #4
java-man wrote: post #3

Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?

Yes. It feels out-of-place. All other keywords are like one word: enum, class, public, protected, native, sealed, ... But looks entirely different: Two words, connected by a hyphen. But I think, it was done because of backwards compatibility. If they would have called it "closed", it would maybe break hundreds of programs that have methods/variables called "closed"

There was a lengthy discussion some time ago[0]. Quote:

#### Why not "just" make contextual keywords?

At first glance, contextual keywords (and their friends, such as reserved type identifiers) may appear to be a magic wand; they let us create the illusion of adding new keywords without breaking existing programs. But the positive track record of contextual keywords hides a great deal of complexity and distortion.

Each grammar position is its own story; contextual keywords that might be used as modifiers (e.g., `readonly`) have different ambiguity considerations than those that might be use in code (e.g., a `matches` expression). The process of selecting a contextual keyword is not a simple matter of adding it to the grammar; each one requires an analysis of potential current and future interactions. Similarly, each token we try to repurpose may have its own special considerations; for example, we could justify the use of `var` as a reserved type name because because the naming conventions are so broadly adhered to. Finally, the use of contextual keywords in certain syntactic positions can create additional considerations for extending the syntax later.

Contextual keywords create complexity for specifications, compilers, and IDEs. With one or two special cases, we can often deal well enough, but if special cases were to become more pervasive, this would likely result in more significant maintenance costs or bug tail. While it is easy to dismiss this as “not my problem”, in reality, this is everybody’s problem. IDEs often have to guess whether a use of a contextual keyword is a keyword or identifier, and it may not have enough information to make a good guess until it’s seen more input. This results in worse user highlighting, auto-completion, and refactoring abilities — or worse. These problems quickly become everyone's problems.

So, while contextual keywords are one of the tools in our toolbox, they should also be used sparingly.

[0]. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...

Post reply on HN