"Helpful NullPointerExceptions": One of the biggest pain points of Java, probably the biggest. Good that it's being finally solved;
I wish C# would do the same (all the other features seem to be in C# already if not borrowed from C#).
New Features in Java 14
101–110 of 188 posts
Re: New Features in Java 14
#102Earlier 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.
In Java the Option of T type blows up the same way a NullPointerException does if you try to use the Option's value when it contains none.
I agree. In Java at least the semantics are practically identical.
I can't comment on Rust. I suspect it does a slightly better job.
Crystal is another language where there is no null. It's quite cool.
Re: New Features in Java 14
#103Earlier quoted context omitted.
Why not do what JS does? val emily2 = { ...emily1, age: 30 }; This has many advantages, one being that it provably and declaratively creates a copy, which is not the case with the builder. In fact the obsession with methods (and hence the implied state) is what makes Java a terrible misfit for functional paradigms such as immutability.
I don't understand what you mean by provably. The Java example does the exact same thing as the JS version: create a shallow clone with a different age. Do you mean the builder might do something different? // Java val emily2 = emily1.toBuilder().age(30).build() As far as adding the spread operator to Java, I think you'd have to require a Spreadable interface to use it or limit usage of the spread operators to record…
If a tool analyzed the JS AST, it could conclude (with fairly trivial analysis) that emily2 is a shallow clone of emily1. No such guarantee is possible with the Java version.
Re: New Features in Java 14
#104"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.
C++ has had non-null references for decades.
Re: New Features in Java 14
#105Earlier quoted context omitted.
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.
Not in Haskell, FYI. Maybes are boxed.
Re: New Features in Java 14
#106Earlier 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.
Yes, but in teams where there is no hope of switching to another JVM language like Kotlin, Lombok can reduce boilerplate by enormous amounts.
It's a compromise.
Re: New Features in Java 14
#107Can't understand the need for records when C# solves the problem of boilerplate with regular classes and some syntactic sugar.
It's an easy and zero-boilerplate way to have immutable data-only structures with some useful tidbits like structural comparison, meaningful hashcodes etc.
I say this as a C# developer that would desperately want them supported in C# and was super pissed off when they were discarded from C# 8.0 (I actually need them right now, they would save me a whole day of typing today)
Re: New Features in Java 14
#108Earlier quoted context omitted.
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.
I have no faith that Java will ever solve the problem after their bungled introduction of the Option type. Step 1 to migrating away from null would be to introduce a working Option type - one that could contain any valid Java value (which includes null for the time being) and where chaining behaviour worked the way you expect (i.e. that doesn't violate the monad laws, even when nulls are being thrown around). People…
It's not really clear from your description as to what's wrong with Optional type. When Java would introduce value classes, I could imagine Optional class to be automatically transformed by a JIT to a nullable instance removing all overhead. Why do you want to keep null inside Optional? That would be absolutely non-intuitive design.
Re: New Features in Java 14
#109> 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…
It starts to get more complex than you might think. Suppose I declare x to be of interface type A and then pattern match it to a disjoint interface type B. Now unless I get depresse that with a cast or a new variable name then I need to express it as some kind of intersection type and this may need to extend into the bytecode and vm.
It might even be an intersection between an object and an interface type, and for historical reasons those have different bytecodes for invoking methods!
Flow typing is really cool, but it can make things way more complex.
Re: New Features in Java 14
#110I 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.