ConcurrentHashMap. Map with non-blocking get(), useful for caches which may be populated from a loader thread.

ConcurrentLinkedQueue. Non-blocking queue, useful for multithreaded pipelines where producers and consumers may share a common queue.

General Advice

Always declare using the most general type you need. This isn't so important for locals, but it makes a huge difference for fields, as this allows you to swap the implementation of a datastructure without breaking code, that may otherwise already have dependencies on the explicitly defined implementation. For example:

I added HashMap because I use it a lot, and it's an awesome collection. Does anyone know what it's based on though? I'm not sure there's an actual array involved, even though that's what it's mimicking.

I added HashMap because I use it a lot, and it's an awesome collection. Does anyone know what it's based on though? I'm not sure there's an actual array involved, even though that's what it's mimicking.

I think it's based on an array of linked lists. I wouldn't say it's an awesome collection though. It simply allows you to attach a field to an object without making a field. There's a better way of doing that: with fields... >_>

I advice you to read the links you posted yourself. And no, it wouldn't become slower, the array of the hashmap grows to keep the number of elements in the linkedlists low. And indexing a list by anything else than an integer is a horrible abuse of a (hash)map.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I just took a two-second glance at it, but why not just have a field called "old" in Node?

Why would I litter my classes with unused fields, only for some situation that I might want to make a deep copy?

Besides that doesn't solve anything, because I still have to create all the connections (edges) between the nodes and end up with a properly connected graph.

Would you suggest I'd also add an 'old' field to the Edge class? And how would I connect it all again? Iterating all possible edges everything I need to find a match? I can see the required code explosion and severely degraded performance already. This is exactly what mappings are supposed to do for you!

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I believe I have. The documentation page for the class doesn't offer a lot of insight into it's implementation other than "Hash table implementation of Map", which is just as good as "array-voodoo" to me. Wikipedia doesn't seem to have a much more understandable version of this. I know its speed for basic operations is described, but "constant-time performance" and "LinkedList" don't fit too well with eachother in my head.

Indexing a list by anything else than an integer is a horrible abuse of a (hash)map.

I didn't mean a literal list. I agree that lists work best with integers for positions, but what if my list goes [1, 5, 12, 2, 66, 21, 14078]. You can sort that how you want, but there will always be that big hole of nulls. I would think that pairing up the integers to their respective objects would be easier than having a few thousand nulls in a huge array.

How about this: I like to load all my resources once, and then just refer to them with an Enum. For instance, 10k spaceships don't all need the same little icon in the instance. They all just have the enum-reference, and then I can statically grab the image if it needs to be drawn. The same goes for animations that're all the same.

In this case it's just easier to have an Image-enum representing all available images, than having to look up on a huge list what index in the array each Image is located at.

This usage of mapping is way too complex to patent! My 'nullify references to aid the garbage collector' patent is pending though, although these days it's rather counter productive to nullify anything, as all data must be retained for 18 months.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

No. The LinkedHashMap allows you to have an ordered Iterator (FIFO) method.

Well yes, LinkedHashMap has a special constructor which allows the 'move-the-last-accessed-entry-to-the-front' behaviour which Riven described, which you use for implementing a simple LRU.Look at LinkedHashMap.Entry.recordAccess() where this is implemented.I don't think this sort of behaviour exists in a normal HashMap.

sproingi, that advice is right, exept for ArrayLists imo.You often need ArrayList.trimToSize(), which trims the array to it's size. For example if you have a method putting (not-knowing how much) elements into an ArrayList, and then never or not often changes it again, you could use .trimToSize() to reduce memory usage.

I think my advice is right 99% of the time for ArrayLists too, but obviously if you need the functionality of a specific type, you use the specific type. If you're never going to change the size of an ArrayList, then you should set the size in the constructor and it will only allocate that many elements.

In fact the advice gets even more general for methods. If you have a method that takes an ArrayList<Foo> and does nothing but loop over it, it should take an Iterable<Foo> instead. I don't get that abstract with publicly-readable fields for obvious reasons though.

I think my advice is right 99% of the time for ArrayLists too, but obviously if you need the functionality of a specific type, you use the specific type. If you're never going to change the size of an ArrayList, then you should set the size in the constructor and it will only allocate that many elements.

In fact the advice gets even more general for methods. If you have a method that takes an ArrayList<Foo> and does nothing but loop over it, it should take an Iterable<Foo> instead. I don't get that abstract with publicly-readable fields for obvious reasons though.

Consider the following scenario:

You have a directory and you want to search all the files inside them recursively, and add then to an ArrayList.You can't set the size in the constructor, since you don't know the size.You can only trim it to size after you have found all the Files.

The thing you could do is return a simple List<File> of Files in the end after you got all the Files... Little src code to make it clear:

privatestaticvoidgetFilesRecursive(Filedir, ArrayList<File> list) {// For each File in the directory "dir":for (Filefile : dir.listFiles()) {// If it's a Directory, call this method with the File "file" as directory:if (file.isDirectory()) {getFilesRecursive(file, list); } else { // Else add it to found files, since it is a file, not directory:list.add(file); } }}

Sure, using the ArrayList implementation internally in the local and returning the abstract List is 100% legit. It's hard to boil that down to one-liner advice of course, but those declarations are also perfectly good field declarations too.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org