Thats 4MB per texture if its 32 it, 20 of them give you 80MB!!
Most hardware cards will struggle with this amount, largely due to texture caching not working (neighbouring screen pixels will require texels that are outside the current texture cache).
Do you really need this resolution? Shrinking them to 256x256 probably won’t give much noticable degredation of the image (seeing as the rendering resolution to screen will be 1280x1024 max). Also check out S3TC texture compression to cut memory size by 1/4, & look at using the OpenGL libraries instead of Java3D as this should cope better with the dynamic loading of the data.
At a push - have several detail levels of the textures (1024 for the nearest one only, 256 for mid distance, 64x64 for far distance), each one mip-mapped. this is because the texture caching will usually upload an entire mip-map chain when you draw, even if the texture is only drawn to a low resolution. This can reduce the amount of texture upload required significantly.
As an aside, we did this sort of thing on the PS2, as you had to calculate all the mip-mapping data on the CPU. On the one hand this was a pain, but on the other it told you exactly which mip-maps would be needed, so you only uploaded them. Not needing the top 2 mip levels saved you 80% of the texture memory usage per frame!
Hope this helps,
