Live data from Hacker News

New Features in Java 14

blogs.oracle.com

131–140 of 188 posts

Re: New Features in Java 14

#131

Earlier quoted context omitted.

Looks like a bug. But anyway should be easily detectable by a static analysis and reported as a warning, so not a big deal in practice, even if working as intended.

Nope - the if condition is not considered in flow analysis. Read the end: https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm... "14.21. Unreachable Statements It is a compile-time error if a statement cannot be executed because it is unreachable. This section is devoted to a precise explanation of the word "reachable." The idea is that there must be some possible execution path from the beginning of the con…

I still don't understand why reachable or unreachable changes the binding from names to local variable/field. The process of identifier resolution should happen before reachability analysis.

Is there some bug or mail list thread with reaction from Java developers?

Re: New Features in Java 14

#132

Earlier quoted context omitted.

Nope - the if condition is not considered in flow analysis. Read the end: https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm... "14.21. Unreachable Statements It is a compile-time error if a statement cannot be executed because it is unreachable. This section is devoted to a precise explanation of the word "reachable." The idea is that there must be some possible execution path from the beginning of the con…

I still don't understand why reachable or unreachable changes the binding from names to local variable/field. The process of identifier resolution should happen before reachability analysis. Is there some bug or mail list thread with reaction from Java developers?

I haven't raised mine, as I consider it to be a refinement of the bug noted in https://twitter.com/tagir_valeev/status/1210431331332689920 (Don't know if java devs have responsed to that.)

(again, reachability analysis of unrelated code changes semantics.)

The problem is that this IS defined behaviour - the scope of the instanceof-assigned variable is dependent on whether or not the taken if-statement is provably exiting.

This is intended to allow

  {
    if (!(obj instanceof String s)) return;

    // s exists now.
  }
But it's not been thought through.

Re: New Features in Java 14

#133

Earlier quoted context omitted.

Nope - the if condition is not considered in flow analysis. Read the end: https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm... "14.21. Unreachable Statements It is a compile-time error if a statement cannot be executed because it is unreachable. This section is devoted to a precise explanation of the word "reachable." The idea is that there must be some possible execution path from the beginning of the con…

I still don't understand why reachable or unreachable changes the binding from names to local variable/field. The process of identifier resolution should happen before reachability analysis. Is there some bug or mail list thread with reaction from Java developers?

It is discussed here.

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

Re: New Features in Java 14

#134
post #113
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 `…

I know what an Optional is, the problem is that this pattern of wrapping stuff in Optionals seems to appear a lot, which means that in practice you have to do this little dance like you would in Java or, as others pointed out, try your luck with unwrap() and hope it goes well. In practice , it doesn't make coding much different.

You seem to forget all the cases in Java where you didn't expect null to happen, but for some reason something was null and you get a NPE. Sure, if you check all values for null already the difference to now is not very big, but no one I know does this. Everyone has some intuition whether something "can" be null or not. Rust (and other languages without null) formalize the notion of "this cannot be null", so you don't have to depend on your intuition anymore - and cannot be wrong about it.

Regarding unwrap: If you tell the compiler "I know what I'm doing" and you don't know what you are doing then no one can help you. It's the same as putting casts everywhere when the compiler yells at you about incompatible types: If you lie to the compiler it will do your bidding, but your code will run into errors at runtime that you could have prevented at compile time. Again: No one can help you here.

Re: New Features in Java 14

#135
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…

The key difference is that in your second example you can just forget about the else branch, while in Rust you must explicitly handle the None case, otherwise it won't compile.

If you don't care about the else case you can use if let: https://doc.rust-lang.org/rust-by-example/flow_control/if_le...

Re: New Features in Java 14

#136
post #69

Earlier quoted context omitted.

It's mostly FUD: it's only relevant for the Oracle JDK; it doesn't apply to OpenJDK (or the other open distributions by other orgs).

It doesn't help that multiple Oracle/Sun folks—including people like McNealy—said under oath that they don't believe that the licensing permits you to make commercial use, even if you opt for the GPL version.

At the time Google screwed Sun, the GPL version did not cover the deployment into embedded platforms, only desktop and servers.

OpenJDK license is another matter.

Re: New Features in Java 14

#137
post #133

Earlier quoted context omitted.

I still don't understand why reachable or unreachable changes the binding from names to local variable/field. The process of identifier resolution should happen before reachability analysis. Is there some bug or mail list thread with reaction from Java developers?

It is discussed here. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...

It's a discussion of a simple use-case where variable is only available inside positive if match (actually pretty logical behaviour). It does not touch unreachable code modifying lexical analysis (what really causes confusion).

Re: New Features in Java 14

#138
post #72
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.

Lombok is really not that complex and it not close to using a different language.

Re: New Features in Java 14

#139

Earlier quoted context omitted.

I still don't understand why reachable or unreachable changes the binding from names to local variable/field. The process of identifier resolution should happen before reachability analysis. Is there some bug or mail list thread with reaction from Java developers?

I haven't raised mine, as I consider it to be a refinement of the bug noted in https://twitter.com/tagir_valeev/status/1210431331332689920 (Don't know if java devs have responsed to that.) (again, reachability analysis of unrelated code changes semantics.) The problem is that this IS defined behaviour - the scope of the instanceof-assigned variable is dependent on whether or not the taken if-statement is provably exi…

IMO they should treat it exactly like they treat uninitialized variables.

    void test1(boolean b) {
        String s;
        if (b) {
            return;
        } else {
            s = "test";
        }
        System.out.println(s);
    }
This code compiles.

    void test2(boolean b) {
        String s;
        if (b) {
            if ("a".equals("a")) {
                return;
            }
        } else {
            s = "test";
        }
        System.out.println(s);
    }
This code does not compile. But it does not mean that println will try to resolve s to something else. I think that they should have gone to a similar route, where declared variable will be available for entire lexical block where `if` was used, but initialized only inside matched branch. Usage in other code would error with "variable might not have initialized" consistently how it works now.

Of course that would require to shadow previous declaration for consecutive `if`-s. But it would be much more obvious and understandable. Actually the whole construction would be just a syntax sugar almost expressible with current Java constructions:

        /*
        if (o instanceof String s) {
            System.out.println(s.length());
        }
        //System.out.println(s.length()); // variable might not have initialized
        if (o instanceof Number s) {
            System.out.println(s.intValue());
        }
         */
        String s;
        if (o instanceof String) {
            s = (String) o;
            System.out.println(s.length());
        }
        //System.out.println(s.length()); // variable might not have initialized
        Number s$; // no variable shadowing in Java now, but it could work
        if (o instanceof Number) {
            s$ = (Number) o;
            System.out.println(s$.intValue());
        }
        //System.out.println(s$.intValue()); // variable might not have initialized
and would be directly expressible if Java would allow variable name shadowing which is a good thing as proven by Go and Rust (although that would be incompatible change for old code, but allowing variable shadowing for patterns would not be incompatible change, because old code does not have pattern variables).

Of course I did not think about this problem for too long and probably missed something important, so that's just my 2 cents. I guess, developers took that path for a reason.

Basically they want to following code to work:

    String s;
    void test(Object o) {
        if (o instanceof String s) {
            System.out.println(s); // local variable o
        } else {
            System.out.println(s); // this.s
        }
    }
and I'd argue that this code should not compile! It's bad code. If developer wants to use `this.s` he should explicitly write that.

Re: New Features in Java 14

#140
post #5

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

Well, what I meant is that they're solving the unhelpful messages :) The root of the problem is still there. Only languages without Null and everything that entails have truly solved the problem.
Post reply on HN