Wow - raw text but I still have to escape \s, \w and friends in a regex. Call me underwhelmed.
New Features in Java 14
111–120 of 188 posts
Re: New Features in Java 14
#112Earlier 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…
From your blog (5.5 years using scala) it seems that null is a problem in scala:
Scala avoids the biggest pitfall of multiple inheritance elegantly, by only allowing one parent to have a constructor; classes may only be the first parent, and traits can't have constructors that take arguments. Unfortunately this doesn't mean they don't need to be initialized; in particular, vals in a mixed-in trait will be null if you try to access them in an earlier constructor.[2] As with any null, in the worst cases you may not get an error until much later on.
Re: New Features in Java 14
#113Earlier 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 `…
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.
Re: New Features in Java 14
#114Can'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)
Records are coming https://github.com/dotnet/csharplang/projects/4#card-1849391.... Will be in C# 9
Re: New Features in Java 14
#115I 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.
One thing included in JDK 14 that will help alleviate this problem for certain types of applications (e.g. desktop apps) is the jlink/jpackage tools that make it much easier to ship an application with a bundled JDK that installs and behaves like a regular native application. If you bundle the JVM with your shipping app, you can always update to the latest JDK version.
Re: New Features in Java 14
#116I 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 if they could.
Re: New Features in Java 14
#117"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).
It's huge feature. I can't count a number of times where this feature would save a lot of time for me. This feature should really be back-ported to Java 8 and Java 11.
Re: New Features in Java 14
#118negative instanceof is a disaster
I posted a bit about it here http://www.benf.org/other/cfr/java14instanceof_pattern.html
it was first noted https://twitter.com/tagir_valeev/status/1210431331332689920 here
but the main thing is that if the 'taken' conditional is guaranteed to exit, then scope hiding happens, if not, not.
But in java
if (true) { throw new Exception(); }
is not guaranteed to exit.
So: https://github.com/leibnitz27/cfr_tests/blob/master/src_14/o...
In case you don't want to run, as of java (build 14-ea+34-1452) this prints:
Fred
WIBBLE
public class InstanceOfPatternTest10 {
static String s = "WIBBLE";
public static void test(Object obj) {
if (!(obj instanceof String s)) {
throw new IllegalStateException();
}
System.out.println(s);
}
public static void test2(Object obj) {
if (!(obj instanceof String s)) {
if(true) {
throw new IllegalStateException();
}
}
System.out.println(s);
}
public static void main(String ... args) {
test("Fred");
test2("Fred");
}
}Re: New Features in Java 14
#119Earlier 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
At one point “simple” was not really a fair assessment of Java, especially if you had to do multithreaded / concurrent code back when we had broken primitives in the Java 3-5 days. It’s moving along a lot faster now thankfully but if it was going this fast 20 years ago we may not have needed Kotlin or Groovy
I guess one of the reasons was abundance of hardware platforms and operating systems back then. Threads were not very native to UNIXes. Nowadays it's basically x86_64 and ARM with Linux/Windows which are much more mature.
Re: New Features in Java 14
#120Earlier quoted context omitted.
> Java lacks default arguments for functions, which makes that particular API infeasible without adding support for such I really wish Java would add both default arguments for functions, and also support for passing function arguments by name. One of these days...
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.
The JVM has all the machinery required to do this right, though: invokedynamic.
Kotlin provides named arguments and a copy method on data classes/records that uses them. You do indeed have binary compatibility issues with them, but it's not a fundamental problem. It's just that it sits at the intersection of:
- Problems that only affect library writers, rarely a high priority for language designers (Java being a exception)
- Obscure JVM knowledge and new techniques
- Poor Android JVM holding back the ecosystem by discouraging any bytecode techniques that post-date Java circa 2010.