Avoid 3D, because you would need to know how to make 3D models or find good ones, you would need to know how to load such models (often an epic task in itself, sadly), and how to draw them on the screen (e.g. OpenGL or DirectX takes a lot of work for little gain, and even an engine like jMonkeyEngine requires knowledge of how to utilize the engine, along with basic 3D knowledge). Blitting 2D images on screen and moving them around is far simpler than dealing with vertices, materials, view matrices, transforms, etc. etc. I think you get the point.
Stick with the built-in Java libraries and classes: Graphics2D, ImageIO, AWT mouse and keyboard listeners, Canvas, Java Sound API, and so on. The benefits of sticking with these instead of finding some other library include: you already know them (to some extent), you know they're well tested and stable and generally make sense, online documentation and resources are abundant, and they are portable so you don't have to worry about installing extra libraries with native libraries and all that.
Build up a little library of code snippets ahead of time. These would include things like loading an image, drawing the image to a position on screen, scaling the image and other effects, playing a sound, looping background music, bounding box collision detection, drawing text. Also have a skeleton application which opens a Frame (or Applet), adds a Canvas to it, and the canvas's paint and repaint methods should be overridden, and a thread should be looping the canvas repaint method (or a timer calling it). You can learn these things if you search around for
Java 2D game programming. Assuming you have access to your university's library, you should have a number of good Java game books at your disposal; check them out and skim through them for the above-mentioned snippets, and others I missed.
Practice source control and division of work with your team ahead of time. Are you going to use Subversion, Git, Mercurial, or something else? Are everyone's computers set to the same up-to-date version of Java? Create your repository, commit/push some files, make sure everyone has the repository checked out and ready to go on your system. Maybe commit a 'hello world' app and make sure everyone is able to pull and modify and commit it; and make sure you know how to handle merging (whether you avoid it entirely with good communication or pair programming, or you know how to use a merge tool). Or, if you aren't familiar with source control, make sure you figure out a solution that works; whether it's pair programming while the third person does art or sounds, or something else, just make sure to be organized from the start or you'll waste tons of time.
Bookmark links to websites which provide free media. There have been quite a number of these type sites listed in other questions here; sites like freesound are perfect for quickly finding useful media to use in your game when you don't have the time to make it from scratch. Bookmark this site of course, so you can ask a question if you get stuck on something. Bookmark forums such as the gamedev.net forums so that you can search them for answers. If you opt to use a third-party library, bookmark their website. Organize these bookmarks into folders and grab as many as possible, and make sure to share them so that all three of you have the same useful library of bookmarks. It doesn't take a lot of time to go around and collect these bookmarks and organize them by type/subject, but it saves you a lot of time when you don't have to remember all those websites in the middle of your project.
For more suggestions, see the answers to my question "How to prepare for a game development competition?".
To address the rest of your question... The general advice is: don't aim high. However, it can vary widely depending on how prepared you are (i.e. my above suggestions) and your skills in Java. This is largely a personal judgement based on your history, but since none of you have history of making games (and therefore can't judge the time necessary), aim really really low. Come up with a really basic idea which can be easily implemented in 2D without any advanced concepts (e.g. avoid pixelwise collisions, crazy physics calculations, particle effects, etc.). But then create a prioritized list of the features of the game, in as much detail as possible (e.g. break each feature into as many separate tasks as possible). This way, you simply work your way down the list as far as possible, and if you don't get to some low-priority tasks, it shouldn't be a big deal. This has to be done carefully (you still need a functional game at the end of the time, so there is a minimum set of tasks which need to be done and some tasks depend on other tasks), but in general I think this is the best approach when you don't know how long things will take.