Code using collections available in JDK (correct types of course). Inside class use specific types, but for inter-method communication use interfaces, so you can replace implementations easily.
When you will finishin your application, profile. You will probably find many other places to optimize. If after that, collections will prove to be a problem (most probably because need to creating wrappers for primitives for maps), switch to trove[1] in critical places and profile again.
Be sure to do that as late as possible - trove has very different performance characteristic than jdk collections. For example, trove hashmap memory usage is dependent only on size of it, while in JDK it is a strong function of number of values contained inside. Trove will always use only a few objects, where in JDK you will get at least one extra object per entry. Trove use different collision resolution, so depending on size of map and distribution of hashcodes, it can be few times faster or few times slower[2]
Generally, I have observed trove to be a _bit_ faster and a _bit_ less memory hungry for most cases, and a considerably cheaper garbage-wise for primitive->primitive mappings. I have used it mostly to avoid casting
[1]
http://trove4j.sourceforge.net/[2] Don't believe benchmarks on trove page - they are designed to make trove win by wide marigin
