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

91–100 of 188 posts

Re: New Features in Java 14

#91

Post by pjmlp »

cryptos wrote: post #5
rafaelvasco wrote: post #2

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

Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.

You can get those compile time checks with PMD. It plugs into all major Java IDEs and build tools.

Re: New Features in Java 14

#92

Post by pjmlp »

Sharlin wrote: post #15
rakoo wrote: post #9

Earlier quoted context omitted.

> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…

In Java you're passed a reference to an object. Might it be null? Can it be null? Who knows! Mostly you're just going to ignore the possibility and hope for the best. In Rust you're passed a reference to an object. Can it be null? No, it simply can't! There does not exist a magic "null" value for references. To represent the possible absence of a value, you explicitly encode it into the type system by using `Option `…

Integrate PMD and enable its errors as broken builds, done.

Re: New Features in Java 14

#93

Post by frant-hartm »

koreth1 wrote: post #86
frant-hartm wrote: post #85

Earlier quoted context omitted.

Two reasons - current convention and backwards compatibility. Java developers are simply used to the cast, it is commonly occurring pattern (even if it is from necessity). The backwards compatibility part: class Foo { void foo(Object o) { } } class Bar extends Foo { void foo(Integer i) { } } ... Foo x = ...; Integer i = 42; if (x instanceof Bar) { x.foo(i); } Currently this calls Foo.foo, if there was a smart cast it…

That's not correct. Java method dispatch is always dynamic, so x.foo() will always call the foo() method on whatever concrete type x actually is. The declared type of the variable that holds the reference to that object doesn't matter, nor does casting (with a couple exceptions, none of which apply here). But don't trust me, try it! | Welcome to JShell -- Version 11.0.5 | For an introduction type: /help intro jshell>…

That's right, I forgot a method parameter:

  jshell> class Foo { void foo(Object o) { System.out.println("Super"); } }
  |  created class Foo

  jshell> class Bar extends Foo { void foo(Integer i) { System.out.println("Sub"); } }
  |  created class Bar

  jshell> Foo f = new Bar();
  f ==> Bar@7f9a81e8

  jshell> Integer i = 1;
  i ==> 1

  jshell> f.foo(i)
  Super
  
  jshell> ((Bar)f).foo(i);
  Sub

Re: New Features in Java 14

#94

Post by frant-hartm »

burakemir wrote: post #87
frant-hartm wrote: post #85

Earlier quoted context omitted.

Two reasons - current convention and backwards compatibility. Java developers are simply used to the cast, it is commonly occurring pattern (even if it is from necessity). The backwards compatibility part: class Foo { void foo(Object o) { } } class Bar extends Foo { void foo(Integer i) { } } ... Foo x = ...; Integer i = 42; if (x instanceof Bar) { x.foo(i); } Currently this calls Foo.foo, if there was a smart cast it…

Your statement is wrong, in the following sense: at runtime, the call to x.foo() would always start look at the runtime type (which in this case is Bar, or some subclass of it) - otherwise overriding methods would not work. https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...

Yes, I forgot a method parameter there.

Re: New Features in Java 14

#95

Post by LessDmesg »

hcarvalhoalves wrote: post #67
Sharlin wrote: post #15

Earlier quoted context omitted.

In Java you're passed a reference to an object. Might it be null? Can it be null? Who knows! Mostly you're just going to ignore the possibility and hope for the best. In Rust you're passed a reference to an object. Can it be null? No, it simply can't! There does not exist a magic "null" value for references. To represent the possible absence of a value, you explicitly encode it into the type system by using `Option `…

Just changed from having a bottom null type for all types to everything being a boxed Option type. It’s equivalent. The actual difference is the reliance on pattern matching and the compiler enforcing coverage on those languages.

Option types don't have to be boxed and are specifically optimized in Rust and, if I remember correctly, in Haskell. The Nothing is represented much like a null pointer, i.e. with a special value that can't be dereferenced.

Re: New Features in Java 14

#96

Post by viraptor »

diegof79 wrote: post #63
nine_k wrote: post #56

Earlier quoted context omitted.

This goes against the very idea of method signatures in Java an overloads based on them. An attempt to add it will likely bring in way, way more backwards-compatibility pain than any benefits are worth. Writing simple methods with few arguments helps.

You can have named parameters and backward compatibility with method signatures, Groovy does that [1]. Ok, it cheats a little bit because named params are actually a syntax sugar for Maps. But other languages do the same (e.g. Python) and is very useful too. And if you can type check the map (as in Typescript) the functionality is equivalent to named params. [1] http://docs.groovy-lang.org/latest/html/documentation/#…

Python has real keyword parameters, not just a syntax sugar. They're just presented as a dict when you want to see them all. And you can splat that dict when calling.

Ruby before 2.7 has a syntax sugar where keyword parameters are the same as a trailing hash. But that's changing as well.

Re: New Features in Java 14

#98

Post by Sharlin »

hcarvalhoalves wrote: post #67
Sharlin wrote: post #15

Earlier quoted context omitted.

In Java you're passed a reference to an object. Might it be null? Can it be null? Who knows! Mostly you're just going to ignore the possibility and hope for the best. In Rust you're passed a reference to an object. Can it be null? No, it simply can't! There does not exist a magic "null" value for references. To represent the possible absence of a value, you explicitly encode it into the type system by using `Option `…

Just changed from having a bottom null type for all types to everything being a boxed Option type. It’s equivalent. The actual difference is the reliance on pattern matching and the compiler enforcing coverage on those languages.

Huh, what? You don’t need or want most values to be potentially absent.

Re: New Features in Java 14

#100

Post by chaorace »

jfim wrote: post #30
dionian wrote: post #23

Earlier quoted context omitted.

it's always moved slow on purpose... one of the language's greatest features is backwards compatibility and stability it's purposefully dead simple. this is why many of us switched to alternative JVM langs ... Java can't keep up with the innovation other Langs have without breaking its philosophy of slowmoving/backwards compat

To be fair, it moved much faster after the Oracle acquisition. The Java 6 era of no changes whatsoever was slow as molasses. The joke back then was that even C++ got lambdas before Java.

Anonymous inner classes sucked royally. Java 7 rocked my world when it dropped!
Post reply on HN