"Java 14 is scheduled for release on March 17" So it didn't quite arrive yet.
You know, candidate/preview releases have been available for some time, if you can't wait to test these new features:
New Features in Java 14
141–150 of 188 posts
Re: New Features in Java 14
#142Earlier 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.
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.
Rust refuses to compile, because an Option type is a different type than T, so if you try to use it like one, you get a type error.
Re: New Features in Java 14
#143BankTransaction amount is a double? transactionDate is a LocalDate? Please nobody copy paste that class.
What's the problem with using LocalDate to store a date (without time)?
There's no timezone.
LocalDate is appropriate for things like user interfaces, where you're modelling an intuitive/vague concept of date-ness only meaningful in some wider human context, or where the actual time at which that day starts just doesn't matter or is unknown. For instance it may be a good type to use for annotated historical events, where the day the event happened is the most accurate you can get.
For a bank transaction where they're international by nature and usually need to be ordered temporally against each other, it's an inappropriate type. The time zone in which the date should be interpreted is important. But really for transactions you'd be better off using Instant, at least internally. Time matters too.
Re: New Features in Java 14
#144Earlier quoted context omitted.
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.
I don't know what you're referring to, but FSF does not allow the GPL be used in such a way that the four freedoms are compromised by the licensor imposing additional restrictions.
Re: New Features in Java 14
#145Earlier quoted context omitted.
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
hopefully yes, I'm following the Records v2 issue on github :D
Re: New Features in Java 14
#146I wonder about records - they would be great for simplified implementation of immutability, but they seem to not provide a way to copy with a subset of modified fields - like in Scala: case class Person ( firstName: String, lastName: String, age: Int ) you could create an instance like this: val emily1 = Person("Emily", "Maness", 25) and then create a new instance by updating several parameters at once, like this: //…
It is very cumbersome to not having the 'copy' or equivalence so that a lot of functional languages have similar things:
F#: let updated = { old with prop = newValue }
Elixir: update = %{ old | prop: newValue }
Even JavaScript have similar stuff: const update = { ...old, prop: newValue }
Re: New Features in Java 14
#147It's good to see Java is becoming better and iterates faster.
However, I found it's weird that hosted languages like Kotlin, Clojure or Scala are more approachable for me as they are working fine with JDK 8 like 'libraries'. They're much easier to upgrade than upgrade JDK itself.
Re: New Features in Java 14
#148Earlier quoted context omitted.
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.
I don't know what you're referring to, but FSF does not allow the GPL be used in such a way that the four freedoms are compromised by the licensor imposing additional restrictions.
Except that there are plenty of dual licenses with GPL-exception clauses and Java was one of them back then.
It is up to the courts and copyright holder to decided what to do with their IP.
Re: New Features in Java 14
#149Would be great if Records were actually bonafide value types lol as in not allocated on the heap. Otherwise it’s just nice syntactic sugar like data classes in Kotlin
All in good time, value types is in progress. Available to try here: https://wiki.openjdk.java.net/display/valhalla/Minimal+Value...
It’s been 6 years since Valhalla was announced why it’s still in prototype befuddles me. If anything, getting value types out the door will have significant performance improvements and least barrier of entry for current java / jvm based programmers.
Re: New Features in Java 14
#150Earlier quoted context omitted.
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.
Rust refuses to compile, because an Option type is a different type than T, so if you try to use it like one, you get a type error.
Java would also refuse to compile using an Optional where T is expected.
Java and Rust are practically the same regarding the differences between Optional and T (java), and Option and T (rust). Optional in Java has the `.get()` method which corresponds to the `.unwrap()` method in Rust. And in both are different different types than String in their respective languages.
But in Java you can have an Optional that's null, not just empty. So that's three states - null, wrapping null, or wrapping a value.
I'd say the big difference is that in Rust you can have places that refuse nulls (e.g. using T instead of Option), so you have well defined points of control/checking. That, combined with the difficulty in recovering from a panic (the equivalent of a null pointer exception when trying to unwrap a value that's missing) and the Result type, are Rusts real strength wrt. missing values.