I can’t imagine too many instances where you should need to perform a cast like this:
String x = (String) thing.foo();
IMHO most organized code should either return an interface/abstraction with all of the necessary methods to call or only return a specific type.
Admittedly since the advent of generics, casts are vastly rarer than they used to be in real code.
Cas 
Same state as last time, still no proposal to make this predictably freed. I’m also still waiting to see how this will work. AutoClosable would A way, probably not the best though.
Type specialization but yeah it kind of ends up in the same result + the specialized type will have the type information (as far as it looks at the moment, no type erasure as with generics) It most probably will finally be fixed (if you consider it a bug - I do :D)
Don’t get me started on type-eraser. Although there are some evil tricks it allows.
Didn’t I hear that type erasure may eventually go as well and we’d get those “fully reified types” all the cool kids go on about?
Cas
With type specialization the type will be branded into the class itself whenever the classloader / JVM has to spin a specialized version of the template class. Therefore it will look like type erasure goes away. I really hope generics will be completely reworked to type specialization but I have no overview of the impact on old code, so probably not =(
Non-final static fields will be treated differently, as each (specialized) class will have its own static fields, unless they decide not to copy them during specialization.
Oh really, they’re copied? Seems like I missed that part. Thanks!
So basically if I type ArrayList it’ll actually create int[]s instead of Integer[]s internally?! COUNT ME IN!!!
Wait… I am going to look up ArrayList<> and see if I can’t fork it to make it support explicitly
You can’t specialize on a primitive.
They’re working on that for a future release as part of Project Valhalla, perhaps it’ll be in Java 10.
That said, you can of course implement your own IntArrayList, or if you don’t mind a dependency, use one of the multitude of already well tested primitive collections, such as Tove, HPPC, or even Guava or Apache Commons Primitives.
Or, especially if you’re already using the library for other things, use libgdx’s collections.
So yeah, they didn’t add support for using native data types with generics.
I already knew that, but I wanted to fork the source code to remake ArrayList<> because I am one of those people who love the lowest level of code I can get my hands on and modify it for redundancy.
What I really wanted was it to be ArrayList and Vector.
It doesn’t support Concurrent checks, as you shouldn’t be using ArrayList with threads.
Made a huge improvement to rangeCheck()
private void rangeCheck(int len) {
if(length + len >= data.length)
data = Arrays.copyOf(data, data.length + growth * (int)Math.max(len % growth, 1));
}
i dont know… any arraylist-like primitive implementation is good, if it provides required behaviour - it’s just a bit code to glorify a primitive array.
if you need concurrent access to an array just wrap it with a lock. see how ABQ is implemented.
i think this is the wrong thread to discuss code like this.
A good reason for allowing primitives, is solely from converting Integer to int, as I believe was discussed.
// While this is fine
final ArrayList<String> stuff = new ArrayList<String>();
final String[] array = new String[stuff.size()];
stuff.toArray(array);
// This is the problem
final ArrayList<Integer> stuff = new ArrayList<Integer>();
final Integer[] array = new Integer[stuff.size()];
stuff.toArray(array);
// Now you need to convert to int[]. Have fun.
@Hyroque
B B B B B B B Backwards compatibility strikes again!
I would like to have this too though.
Backward compat doesn’t enter into the picture. It requires either type specialization at compile time or VM black magic that’s equivalent to specialization.