If you really need a list with primitives, why not just write a class like the arraylist class with the data an int[] instead of an Object[]?
Because it’s annoying? And it’s not that simple when you get to stuff like HashMap<X, Y> because then you have n^2 combinations to worry about.
I’m not suggesting that you write your own versions of every class that uses generics. I’m just saying if someone were really bothered by using an ArrayList for a list of integers then it doesn’t take that long to write one class file (with most of the content copied from the ArrayList source).
Edit: Not to mention that people have already done this, as shown by the libraries linked above.
Having type specialization is a super time saver. There’s no point in writing the (as mentioned) combinatoric number of versions when they are truely identical. Nor is there a point in them existing in expanded form (in a classfile) since they’re simple macro expansions. If you focus on one or two specific examples…sure it’s no big deal. That’s not really the problem.
[quote]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.
[/quote]
My bad, interpreted the SE answer falsely :persecutioncomplex:
Compile time magic seems pretty reasonable to do for such a nice convenience feature.
You would “just” have to automatically swap out data types and replace the functions that the Object versions of the primitives expose with static code or is there a trap hidden somewhere?
… but then, those little things start to break - like [icode]equals[/icode]/[icode]contains[/icode]
[icode]1+2 == 3[/icode] but [icode]1.0f + 2.0f != 3.0f[/icode].
:-\
@VaTTeRGeR: To be fair to do it properly would be a back-compat issue since it would require new VM features.
@basil_: I should have put truly identical in italics. Type macros can get hairy fast.
IMO if java did add support then the syntax shouldn’t be [icode]Foo[/icode]. Generics are bounds on legal types that some pointer has…type specialization is a completely different animal.
Its impossible without rewriting all list instances
//ArrayList
public int indexOf(Object o) {
if(o.equals(elementData[i]))
}
prim types dont’ have equals and hashCode
for adding prims need make [icode].class.equals(o, elementData[i][/icode] in all Lists + objects classes
And plz stop flaming about this)
For ArrayList you can basically use it as a ArrayList anyway
ArrayList<Integer> intTest = new ArrayList<Integer>();
for (int i = 0;i< 10;i++)
{
intTest.add(i);
}
for (int value : intTest)
{
System.out.println("The value is : " + value);
}
List<Integer>#remove(x)
:persecutioncomplex:
But inside it is still an array of objects, so the values are scattered all over memory, instead of a primitive array, with all the values located together.
Hey guys,
Just updating my slides for next week in Malaga and Kiev (if anyone of you might be around let me know :-))
There is some kind of code around now that implements the MemoryRegion ideas, however the API (at least for now) is pretty different from my guesses in the past. Anyhow I guess a couple of you guys will love the API as it gives way more control of what is going on!
public long memory(long index) {
// The scope where the memory region is available
// Implements AutoClosable but `close` can be called manually as well
try (Scope scope = new NativeScope()) {
// Allocate the actual memory area, in this case in the style of a "long-array"
Pointer<Long> ptr = scope.allocate(
NativeLibrary.createLayout(long.class), numElements);
// Get the reference to a certain element
Reference<Long> ref = ptr.offset(index).deref();
// Set a value to this element through the reference
ref.set(Long.MAX_VALUE);
// Read the value of an element
return ref.get();
}
}
The actual commit of this code can be found in the Project Panama repo http://hg.openjdk.java.net/panama/panama/jdk/rev/42bf13af7c8b, http://hg.openjdk.java.net/panama/panama/jdk/rev/b6db50e8621b, http://hg.openjdk.java.net/panama/panama/jdk/rev/7b9181011bf7, http://hg.openjdk.java.net/panama/panama/jdk/rev/443cb527b092
It’d be really interesting if you could share them once done 
Alright, will share the updated deck, however not a lot has changed yet
It looks good. As long as it allows to manually release the native memory, it’s ok for me.
Scope is AutoCloseable therefore you don’t have to use try-with-resource but call close manually. Anyhow I like the idea of a scope as a single scope can have multiple memory regions.
Here’s btw the updated slide deck: http://www.slideshare.net/ChristophEngelbert/a-postapocalyptic-sunmiscunsafe-world
Currently waiting for the recording of the talk to be available, anyhow my fav slide is #71 (http://www.slideshare.net/ChristophEngelbert/a-postapocalyptic-sunmiscunsafe-world#71), I mean who’s not missing Pointer and Reference classes in Java? And EVEN better, OBVIOUSLY the Pointer class have a public static final field named NULL_POINTER 
it’s not java if it’s not bold i guess.
Personally I am looking forward to structures - currently any abstractions for stuff like vectors or matrices are often resource-intensive (unless used sparingly).