One of the primary features I'm holding out hope for eventually making it into the language is ValueTypes: http://cr.openjdk.java.net/~jrose/values/values-0.html and the current Valhalla Project: https://wiki.openjdk.java.net/display/valhalla/Main The simplest example of why this would be valuable (edit: this was not an intentional pun), the Optional type could become stack based, such that you could ensure that the…
Or use Scala :)
A categorized list of all Java and JVM features since JDK 8 to 16
101–110 of 243 posts
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#102Earlier quoted context omitted.
Or use Scala :)
Which doesn’t have value types because it should be implemented in the JVM?
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#103One of the primary features I'm holding out hope for eventually making it into the language is ValueTypes: http://cr.openjdk.java.net/~jrose/values/values-0.html and the current Valhalla Project: https://wiki.openjdk.java.net/display/valhalla/Main The simplest example of why this would be valuable (edit: this was not an intentional pun), the Optional type could become stack based, such that you could ensure that the…
I am not sure I understand, why would you want Optional type to never be null? Isn't it being null sometimes — the whole point?
No you have it backwards - the whole point is that Optional is never null. You use empty instead.
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#104Earlier quoted context omitted.
A lot of things are coming straight from C#, so it’s battle-tested there before inclusion I guess.
As someone unfamiliar with C# but interested in how languages impact each-other, could you provide some examples? I know C# was heavily inspired (perhaps not a strong enough word) by Java, but not as familiar with the opposite. Java does seem to absorb from tried and tested ideas. There are a few major features I can think of that have largely come from or been inspired by popular and mature 3rd party libraries (time…
And by the way for the downvoters: there wasn’t any snark, C# itself being at first a copy-pasta from Java, and now taking heavy inspiration from F#. That kind of features transfer in-between languages is a good thing.
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#105Earlier quoted context omitted.
Or use Scala :)
Does Scala have value types?
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#106Earlier quoted context omitted.
Good language ought to discourage (enough) the bad practices. Culture forms slowly, and it's Java fault that the culture managed to produce such excessities as proverbial FactoryFactoryFactory. Edit: I still think Java is a good language, especially later versions, and both original goals and recent advances are quite noble.
I somewhat agree, but Java grew up in a different era when communication about these things wasn't as easy. It's hard to change the direction of something as large and widely deployed as Java. It's happening but it will take time and its always going to dealing with its legacy as there just so much of it out there.
Of course one can show empathy and understand justifications for things they like and simply laugh out "LOL Go No Generics' when they don't.
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#107Earlier quoted context omitted.
How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?
Perhaps this example will make it more obvious: boolean truthy = false; truthy = null; // compilation failure, type mismatch vs. the Boolean type Boolean truthy = new Boolean(false); truthy = null; // compiles just fine The reason Boolean (and other boxed primitive types) exist is because it is an Object (a reference type) and that allows them to be used in things like collections that expect Objects and not primitiv…
var truthy = null; // Compile fails
var nullable? = null; // Compile passes
You don't need value types for this?
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#108Earlier quoted context omitted.
Now we've got Spring, which in my, admittedly limited, experience does a great job of transforming what could have been compile-time errors into run-time errors.
Well said :) . Spring looks so much as to show how useful ideas can be misapplied with catastrophic results. For example, liberate encouraging of dependency injections leads to multitude of interfaces which are only ever implemented once by a production code class, and maybe one more time by a test class, even though Java has all methods virtual and testing could be done without requiring the interface.
https://wiki.c2.com/?RavioliCode
DI is a powerful concept, but Spring projects rely on DI in such a generic way that it often doesn't even make sense for your application. You have to gain intimate knowledge of the abstractions, and inject a bunch of code in a bunch of places just to make it do the very-straightforward thing you were trying to do.
Re: A categorized list of all Java and JVM features since JDK 8 to 16
#109Java gets a bad rap from people that used it late 90's through early 2000's and got burned out by XML and design pattern heavy frameworks but its a lovely language that with a little discipline can be used to create very lean looking code. Go is one of the HN darling languages and I work in Go everyday for work (and generally like it), but I really wish I could reach for Java most days.
"Go is one of the HN darling languages" It's def not the case, I spend too much time here and on Reddit and people are always complaining about Go ( generics, errors, type system etc ... ), if you want the godly language it would be Rust, anything about Rust will be upvoted. As for Java, it's a good language / runtime that is overly complicated behind layers of abstraction. Take Spring for examnple, magic everywhere,…
That is just better half part, sad part is anything negative about Rust will be heavily downvoted. Most of the time I disagree with Java/Go in their thread it would be just fine but not with Rust.