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

New Features in Java 14

blogs.oracle.com

Post reply on HN
Print view View original

151–160 of 188 posts

Re: New Features in Java 14

#151

Post by exabrial »

How do I propose a language change? One thing I'd really like to see is optional type declarations in Lambdas to bulletproof them. Take this simple Lambda

   List names = new ArrayList();
   names.stream().filter(String name -> "Bob Vance".equals(name)).findFirst().get();
By adding the String type declaration, a whole host of bugs in really complicated Lambdas can be eliminated and found easier when the original types and lists are being shuffled around

Re: New Features in Java 14

#152

Post by hedora »

Benjammer wrote: post #53
mateuszf wrote: post #38

I wonder about records - they would be great for simplified implementation of immutability, but they seem to not provide a way to copy with a subset of modified fields - like in Scala: case class Person ( firstName: String, lastName: String, age: Int ) you could create an instance like this: val emily1 = Person("Emily", "Maness", 25) and then create a new instance by updating several parameters at once, like this: //…

You'd probably have to manually write a Builder in the Person record class. Then the callsite might look something like this: val emily2 = emily1.newBuilder() .lastName("Wells") .age(26) .build() I think the inner Builder pattern is common enough in immutable java object implementations that they might want to include that fully in the Record class generation at some point. Most immutable object libraries that I've s…

Builders are really only useful for small programs or classes that aren’t broadly used.

Otherwise, at some point you need to add a field to Person, and then the compiler can’t tell you about all the places where your code fails to initialize the field.

Worse, some people pass builders around.

At that point, the problem of checking that you’ve passed a legal set of arguments when constructing objects is as hard as the halting problem.

You can write tests to make sure your program is typesafe, but that takes time away from writing more useful tests.

Re: New Features in Java 14

#153

Post by steveklabnik »

swsieber wrote: post #150
steveklabnik wrote: post #142

Earlier quoted context omitted.

Rust refuses to compile, because an Option type is a different type than T, so if you try to use it like one, you get a type error.

Java would also refuse to compile using an Optional where T is expected. Java and Rust are practically the same regarding the differences between Optional and T (java), and Option and T (rust). Optional in Java has the `.get()` method which corresponds to the `.unwrap()` method in Rust. And in both are different different types than String in their respective languages. But in Java you can have an Optional that's nul…

I think we are saying the same thing, from slightly different perspectives. That Option can be nullable means that it can be used where it is not actually that type, without a type error, is what I’m saying.

Re: New Features in Java 14

#154

Post by jfengel »

hedora wrote: post #152
Benjammer wrote: post #53

Earlier quoted context omitted.

You'd probably have to manually write a Builder in the Person record class. Then the callsite might look something like this: val emily2 = emily1.newBuilder() .lastName("Wells") .age(26) .build() I think the inner Builder pattern is common enough in immutable java object implementations that they might want to include that fully in the Record class generation at some point. Most immutable object libraries that I've s…

Builders are really only useful for small programs or classes that aren’t broadly used. Otherwise, at some point you need to add a field to Person, and then the compiler can’t tell you about all the places where your code fails to initialize the field. Worse, some people pass builders around. At that point, the problem of checking that you’ve passed a legal set of arguments when constructing objects is as hard as the…

I find Builders most useful when you've got a lot of optional arguments. For mandatory arguments (and most arguments should be mandatory), you should definitely use constructors instead, so that your tool kit can tell you when they change.

Optional arguments with reasonable defaults don't present a problem for refactoring. It does make it hard to spot the cases where the reasonable defaults don't work. One trick is to temporarily add it to the constructor, review all the errors, and then remove the constructor arg.

Re: New Features in Java 14

#155

Post by sickmartian »

exabrial wrote: post #151

How do I propose a language change? One thing I'd really like to see is optional type declarations in Lambdas to bulletproof them. Take this simple Lambda List names = new ArrayList (); names.stream().filter(String name -> "Bob Vance".equals(name)).findFirst().get(); By adding the String type declaration, a whole host of bugs in really complicated Lambdas can be eliminated and found easier when the original types and…

Can't you do .filter((String name) -> "Bob Vance".equals(name)) already?

Re: New Features in Java 14

#156

Post by cxr »

pjmlp wrote: post #148
cxr wrote: post #144

Earlier quoted context omitted.

I don't know what you're referring to, but FSF does not allow the GPL be used in such a way that the four freedoms are compromised by the licensor imposing additional restrictions.

Except that there are plenty of dual licenses with GPL-exception clauses and Java was one of them back then. It is up to the courts and copyright holder to decided what to do with their IP.

First, you didn't describe an exception; you described additional restrictions. But now you're pivoting to talk about exceptions.

These are fundamentally different things. One enlarges the set of actions a recipient is free to do relative to what vanilla GPL allows. This is permitted (and in the case of the classpath exception, endorsed) by FSF. The other attempts to shrink the size of that set by denying the user things that the GPL would otherwise allow. The FSF simply does not permit the GPL to be used in that combination (and there would be extreme contrast in your last sentence and the failure to recognize the FSF's say in this).

And secondly, you've yet to substantiate your claim that Java was ever distributed with such GPL-modifying restrictions.

Re: New Features in Java 14

#157

Post by smt88 »

winrid wrote: post #70
smt88 wrote: post #37

Earlier quoted context omitted.

What would stop you from switching to Kotlin, which has those features and many more?

I was in a Java shop at one point where leadership said Kotlin would be too hard for the engineers to learn (they were all mostly fairly junior).

Syntax is not that different from Java. Someone who knows Java could be productive in 1-2 days. But it sounds like you agree that your leadership in that scenario was not rational.

Re: New Features in Java 14

#158

Post by rafaelvasco »

hyperpallium wrote: post #13
rafaelvasco wrote: post #2

"Helpful NullPointerExceptions": One of the biggest pain points of Java, probably the biggest. Good that it's being finally solved;

It's just better error messages (where within expression, not just which line).

The amount of time I've eye traced the code looking for the possible culprits for the NullPointerException and then debugging it later .... This feature should be there day one;

Re: New Features in Java 14

#159

Post by pjmlp »

vbezhenar wrote: post #116
correct_horse wrote: post #110

I feel like Java has a particular problem in common with Android - they both keep getting better, but most people are stuck on some old version. The difference is that smartphones phones last at most 5 years, but a program that a business depends on lasts forever.

People deliberately chosen to stay with some old version. Java backwards compatibility is awesome. The only questionable move was with Java 9, when they removed a lot of classes from standard library and introduced modules, but even that move was not so hard to migrate. Some people just don't want to invest ANY money to improve their code. They just want to release new features. They would use Java 1 on Windows NT 4…

To be fair, many users would do just fine with an Amiga 1000, given what they do with their computers.

Re: New Features in Java 14

#160

Post by pjmlp »

cxr wrote: post #156
pjmlp wrote: post #148

Earlier quoted context omitted.

Except that there are plenty of dual licenses with GPL-exception clauses and Java was one of them back then. It is up to the courts and copyright holder to decided what to do with their IP.

First, you didn't describe an exception; you described additional restrictions. But now you're pivoting to talk about exceptions. These are fundamentally different things. One enlarges the set of actions a recipient is free to do relative to what vanilla GPL allows. This is permitted (and in the case of the classpath exception, endorsed) by FSF. The other attempts to shrink the size of that set by denying the user th…

Well, I let Gosling speak about Google's then

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

Post reply on HN