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

81–90 of 188 posts

Re: New Features in Java 14

#82

Post by nine_k »

lmm wrote: post #72
nine_k wrote: post #57

Earlier quoted context omitted.

Lombok solves this for Java.

Using Lombok ends up being just as much effort as using a different JVM language, and the rewards are smaller.

The learning curve is way less steep, and you can introduce it into an existing project with zero impedance mismatch.

Re: New Features in Java 14

#83

Post by oaiey »

wereHamster wrote: post #80

> Pattern Matching for instanceof Why is the cast even necessary? Isn't the cast only part of the type checker and thus unnecessary with a smarter type checker? For example TypeScript can do it, if you have code following an if condition that checks the type of the variable, you can use that said variable as if it were of that type without any further assertions necessary, eg. let x: unknown; if (typeof x === "string…

This kind of flow analytics are pretty new IMHO. C# supports these e.g. for nullable checks. But I think Java and C# are designed a bit too early for having these kind of flexibility with the variable type. Also consider that changing the type also has other consequences like invoking other virtual methods (e.g. C# new operator on methods) which can be confusing because a type change above is not explicit.

PS: just came to my mind: that is a breaking change (in C#) due to the new operator exanple. Will never come (for C#). Maybe Java does not have this issue but most likely they have a similar problem

This is an awesome feature for typescript. Love their work there.

Re: New Features in Java 14

#84

Post by Thorentis »

redact207 wrote: post #18

"switch expressions", "text blocks". I haven't used Java for 15 years but it's one of the most mature languages out there. I'm surprised it's only just getting these pretty standard features now.

I don't think switch expressions are pretty standard at all.

Switch statements are standard, and Java has had them for a long time. Switch expressions are different in that the switch "statement" now returns a value that can be assigned to a variable.

Re: New Features in Java 14

#85

Post by frant-hartm »

wereHamster wrote: post #80

> Pattern Matching for instanceof Why is the cast even necessary? Isn't the cast only part of the type checker and thus unnecessary with a smarter type checker? For example TypeScript can do it, if you have code following an if condition that checks the type of the variable, you can use that said variable as if it were of that type without any further assertions necessary, eg. let x: unknown; if (typeof x === "string…

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 would call Bar.foo, possibly breaking existing code.

EDIT: Added method parameter.

Re: New Features in Java 14

#86

Post by koreth1 »

frant-hartm wrote: post #85
wereHamster wrote: post #80

> Pattern Matching for instanceof Why is the cast even necessary? Isn't the cast only part of the type checker and thus unnecessary with a smarter type checker? For example TypeScript can do it, if you have code following an if condition that checks the type of the variable, you can use that said variable as if it were of that type without any further assertions necessary, eg. let x: unknown; if (typeof x === "string…

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> class Foo { void foo() { System.out.println("Super"); } }
    |  created class Foo

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

    jshell> Foo f = new Bar();
    f ==> Bar@58651fd0

    jshell> Bar b = new Bar();
    b ==> Bar@5419f379

    jshell> f.foo();
    Sub

    jshell> b.foo();
    Sub

    jshell> ((Foo)b).foo();
    Sub

Re: New Features in Java 14

#87

Post by burakemir »

frant-hartm wrote: post #85
wereHamster wrote: post #80

> Pattern Matching for instanceof Why is the cast even necessary? Isn't the cast only part of the type checker and thus unnecessary with a smarter type checker? For example TypeScript can do it, if you have code following an if condition that checks the type of the variable, you can use that said variable as if it were of that type without any further assertions necessary, eg. let x: unknown; if (typeof x === "string…

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...

Re: New Features in Java 14

#88

Post by justlexi93 »

Pattern Matching for instanceof. Non-Volatile Mapped Byte Buffers. Helpful NullPointerExceptions. Switch Expressions (Standard) Packaging Tool (Incubator) NUMA-Aware Memory Allocation for G1. JFR Event Streaming. Records (Preview)

Everything looks promising for me.

Re: New Features in Java 14

#89

Post by hrgiger »

This blog post doesnt cover all interesting changes, at least for me.[0]

For me most interesting upcoming changes are

JEP: 352: Non_Volatile Mapped Byte Buffers, JEP 345: NUMA-Aware Memory Allocation for G1 and JEP 370: Foreign-Memory Access API (Incubator). Especially FMA api [1] examples seems most promising but shipped with panama and I am not sure about the maturity yet: https://github.com/zakgof/java-native-benchmark

I wonder how GraalVM stands in this picture that beside of being polyglot, it has AOT and auto vectorization futures and I dont know if those are already/will be shipped also with openJDK

[0] https://jaxenter.com/java-14-update-news-163585.html [1] https://openjdk.java.net/jeps/370

Post reply on HN