So my first question is: How would I rewrite, or create a new, paint method that I can have executed immediately?[/quote]
Use a BufferStrategy. It allows you to "blit" to an off-screen image like you would normally using an API like SDL and doesn't restrict you with Swing's obnoxious threading issues with regards to paint() and repaint(). That is, you can flip() your buffer whenever you like, thus controling the rendering speed yourself (for the most part, but it is an improvement since Swing tends to ignore repaint() requests at random). Furthermore, the surface is almost guaranteed to be hardware accelerated and Java will handle all the details for you. Here's a simple example: http://gpsnippets.bl...gy-in-java.html

Would it be a bad idea to put all the ArrayLists inside a Vector so that I can just loop through the vector and then each ArrayList so that I don't have to call them by name? [/quote]
First, a Vector is just a synchronized ArrayList so there's not any particular need to use them. If you're having synchronization issues, I'd look at an alternate strategy (synch blocks, copy-on-write, etc.) instead to avoid any potential overhead.

Second, to answer your specific question - not really. I mean, it's not ideal or anything but you aren't going to fail miserably if you do it until you start generating a lot of objects. If it works well enough for you, more power to you.

That said, if you are having issues or want something that's a bit more scalable, I'd look into an alternate partioning scheme such as a basic quadtree or similar. The key issue is that most of those objects don't move - things like doors and static platforms don't actually change their positions. You can track an offset into your level and compute the "drawing" coordinates from that without needing to store those objects, drastically cutting down the objects you need to iterate over on a per-frame basis.