On 23 Sep 2015, at 08:55, Tagir F. Valeev <amae...@gmail.com> wrote: > Hello! > > Quite interesting feature. Isn't it a typo here? > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html > > 419 if (!Float.isNaN(a[aFromIndex + i]) || !Float.isNaN(b[aFromIndex + i])) > 487 if (!Double.isNaN(a[aFromIndex + i]) || !Double.isNaN(b[aFromIndex + > i])) > > Seems that it should be b[bFromIndex + i], not b[aFromIndex + i] in > both cases. >
Oops, well spotted, thanks. Testing for NaNs can be tricky, now i need to work out why the tests did not capture that! > As for methods like compare(byte[] a, int aFromIndex, int aToIndex, > byte[] b, int bFromIndex, int bToIndex) > > Is it better to introduce two to-indices instead of single length > argument (like in System.arraycopy)? Because that’s the style of usage in Arrays, and AFAICT the common style used by apps/frameworks that have rolled their own array comparators. > Six method arguments looks > a little bit crowded. > > As for method count, it would be really nice and user-friendly were it > be possible to add methods to the array types themselves, so users can > write: > > byte[] b1; > byte[] b2; > > int mismatchPos = b1.mismatch(b2); > Comparator<byte[]> cmp = byte[]::compareTo; > > This somehow works with clone() method (I guess, there is some very > special code in javac for this). There could be some special abstract > classes like java.lang.ByteArray with private constructor (using > this[idx] to access elements) and all byte[] arrays could extend them, > so JDK developers could add new methods to arrays without modifying > the compiler. Well, that's just my fantasies about the better > world… > Perhaps it’s closer than you think, although further away than you might like :-) There are some experiments in Project Valhalla [1]. We would like all arrays to extend from a common array super type, from which we can then hang off further methods. That’s part of the Arrays 2.0 story. You correctly guessed there is currently something special going in javac and the VM. I think it might be quite simple to extend javac. The tricky work is more likely in the VM to hook in the array super type and it's methods (perhaps patching into the underlying array class's v/itables). Paul. [1] http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/73ae1e2cbb20
