But since I'm only doing such in class constructors, class initializers, and static initializers, should I still be concerned with allocation, de-allocation, re-allocation, et cetera?
It depends. When stuff like that is done mostly in initialization phases, you have to consider that probably the JVM has just started to execute that code for the first time. By that fact alone it will work quite slow, and if you add on top array trashing, it will work slower than it should.
Its not that the reallocations themselves are that bad, after all the JVM manages its own preallocated heap, you probably heard a few times that an allocation in the JVM is "just a pointer bump", its just that you put reallocations in places where they might have more impact in startup time.
If the code is "hot" code though (ie, has been run at least a few hundred times), the VM might be able to inline the resizing and notice it allocates an array, puts stuff there, then reallocates another array, then copies back the contents, and eliminate the intermediary array in the process. Its something plausible, but I haven't read anything about such thing so I wouldn't expect it to do it. And even if its done, its probably done by the C2 compiler after a couple thousands calls rather than a few hundred (HotSpot does tiered compilation now so C1 and C2 compilers kick in at different stages in the same code).
You can only be 100% sure by checking the assembly output after a couple tests. Or you could just properly size your collections beforehand