Upgrading to Java 21? You'll want avoid these features.

Many new features have been added to Java between 18 and 21, but some features are also on the way out. Let's review a few key features that have been deprecated or removed and alternatives for them!
Article ➱ inside.java/2023/12/17/sip093/
Tags: #OpenJDK #Java #Java21 #InsideJava

[@bluesdog88]

I don't thhink that cup has any Java ;)

[@gradientO]

nullable cup

[@karaal44]

👌

[@x0kosmus0x]

Hi can you check the link to the article? I'm getting a 404 Page.
Thanks

[@delabassee]

@x0kosmus0x The link is fixed, sorry for that.

[@x0kosmus0x]

​@@delabassee Thank you

[@64aashishchaudhary5]

Huh.. That was cool

[@gsestream]

well you should extend and update the built-in platform-independent java opengl/vulkan bindings, for example making (accelerated) VolatileImage/Graphics2D draw calls buffered, not drawing one image/line/op at a time but an array of images/shapes/ops with one call, transferring the parameter data of the image calls at once (assuming the VolatileImages are already loaded in the GPU memory. also other operations like matrix math in arrays would be simply accelerated in the same way in the GPU, no complex code transfer interface or platform specific libraries. Just design the usage interface in pure Java in the way it can be used for all kinds of GPU drawing/computations. and I specifically dont mean the current approach of JOGL or platform specific libraries like JavaFX, LWJGL or any of those kinds of libraries. Or just making the opengl/vulkan basic drawing functions directly accessible on default JVM of java without any JNI libraries. make it the easy simple way, not the complex burdening way you try to do it now with JOGL. yes the JVM should be the translation layer, to opengl/vulkan, not the gpu to trying to interface directly with java code, or there being non-standard native libraries alongside/as-plugin/inside the JVM.

[@gsestream]

also you might want to fix the non-stable behaviour of Arrays.sort() vs TreeSet, where Arrays.sort() complains about breaching the contract of a custom Comparable implementation, when the TreeSet sort does not complain. maybe the Arrays.sort() requirements are wrong/incorrect (-ly implemented).

[@gsestream]

and why does MyClass[] myclasstemplatearray = new MyClass[5]; give error of being generic array, when its very type specific. this is clearly an error in the compiler and/or language syntax checker. omg it actually does not compile even manually, and not with the Eclipse GUI with syntax checking. any type of valid object should be able to put in arrays, like its able to be used in other type of Object structures. ie a typed template object is a normal Object and therefore should be able to be put in arrays like normal Objects. Java specification limits the use of the template class objects in arrays unnecessarily.

[@gsestream]

The method compareTo(T) in the type Comparable is not applicable for the arguments (Comparable)? it literally says same type is not same type! it literally thinks T is exactly "T" and not IndexSort, same thing as in arrays, typed template processing does not compute correctly in Java specification currently.
public static class IndexSort implements Comparable {
public int index; public Comparable value;
public IndexSort() {};
public IndexSort(Comparable valuei) {this.value=valuei;};
@Override public int compareTo(IndexSort o) {
return this.value.compareTo(o.value);
}
}

[@vytah]

@@gsestream To answer some of your questions:
- Arrays.sort and TreeSet are completely different - in fact, TreeSet does not do any actual sorting, but it builds a tree, so it has no way to detect a broken comparison implementation. A broken comparison could leave the sorted array in a completely incorrect state, including duplicated elements or extra null elements, so detecting it reveals the errors faster.
- Java generics are erased, so MyClass[] would simply be MyClass[], with no runtime info about what the type parameter was. new MyClass[] does not compile because you could implicitly upcast it to Object[] and then store MyClass in it, and the type system warns you by not pretending it can uphold the weak guarantees of the generic types. Java arrays are both mutable and covariant, and this makes the type system unsound; however, usually it's not completely bad as you get ArrayStoreException, but for storing MyClass in MyClass[] via an Object[] reference you would not get one and the program would crash only much later. In short: Long[] l = {null}; Object[] o = l; o[0] = Short.valueOf(0); compiles and correctly immediately crashes, MyClass[] l = {null}; Object[] o = l; o[0] = new MyClass(); if it compiled, would not crash immediately, would corrupt the array and cause a hard-to-debug crash later. This is not a big problem with things like generic lists, since they're invariant, not covariant, so you cannot cast them to another list type implicitly, and doing so explicitly requires two casts. So if you need idiomatic code, use ArrayList; if you need performance, use MyClass[] and accept all the drawbacks of having to maintain data integrity yourself.
- The compareTo method takes T and not Comparable because... how could you do anything with it without casting then? You should have written IndexSort

[@gsestream]

hey about those generic classes, you can currently use Object[] arrays to make a generic array, so I hope you will allow specific generic array creation by the new operator in the future, yes this bypass works, the generic classes are normally accessible in the Object array after an unchecked cast, as objects and the cast type objects. no errors. only suppression warnings.

[@gofudgeyourselves9024]

Koi isko samjaho khali cup se chai pe raha hai, mai toh bol bolke thak gaya