I am writing some compression algorithms for huge data sets that
have to be as fast and compact as possible,
Given that limited knowledge I would have to assume that Java is a
*very* poor choice. True, using JNI is more of a pain than not using
JNI, but I suspect it is the right choice in this case. Or, as you
mentioned, forgetting Java entirely and using C/C++, possibly even
with inline assembler, since I'm guessing the Intel architecture will
cover a significant chunk of the platforms you will deploy on.
If you must use Java for part of it, work with NativeByteBuffers to
get your data across the JNI boundary.
If JNI absolutely isn't an option, your going to have to suck it up
and work around the limitations of generics (obviously). But Java
isn't really doing anything wrong in the example you have sited.
It's just a quirk of the generics design that allows you to fall into
that trap.
Good luck!
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
