As everyone's already said, display lists are deprecated since many years back. Vertex buffer objects is the way to go nowadays.
There's a reason why voxels are generally kept pretty big. Storing volume information requires huge amounts of memory usually. Consider a simple case where you want a 500 voxel view distance and you have a maximum height of 200 voxels. To allow the player to look around properly, you'd need to have all voxels within a 500 radius circle around the player loaded in. This is essentially a 1000x1000x200 volume of voxels, or two hundred MILLION voxels. Storing each voxel as an object will use at least 8 bytes per voxel (even an empty Java object uses 8 bytes), so you're already talking about 1000*1000*200*8 bytes, which is equal to 1.5GBs of memory right there. Let's say you want smaller voxels, so you cut each voxel into 8 smaller voxels. Well, now you have 8 times as many voxels, so that's 12GBs of memory you have now. There are a lot of tricks for reducing the memory usage of voxel worlds, and this should be your first focus (after you got basic rendering working).
Tessellation isn't really something you can use for voxel worlds effectively to get smaller voxels. Due to how most voxel world rendering techniques work, both the smallest and biggest piece of geometry you can render is a single voxel's face. The nature of voxel worlds makes it very hard to combine multiple voxels into a single surface without handling a lot of special cases, so it's an optimization that is rarely done. Tessellation allows you to dynamically divide one triangle or quad into more triangles or quads. This isn't really what you want to do in your voxel world, because it would require you to merge voxels ahead of time, then dynamically subdivide them again to get the original voxels back, which like I said is really hard to do. This means that tessellation doesn't really fill much of a function in voxel worlds. If none of what I just said makes sense to you, you should consider reading up more on tessellation and what it's actually used for nowadays, what its advantages and disadvantages are, etc.
Realistic physics can be a big challenge to do for big worlds. Again, memory usage can be a big issue, but performance is a more likely problem here as well. If you're hellbent on having physics, I'd recommend taking a look at the Bullet physics engine, as that's your best bet at achieving realistic physics. Still, it's definitely not an easy task.
Indeed, shaders are a must for the OpenGL 3 pipeline, because you literally need to have a shader program to be able to render anything at all. That is unless you use the compatibility profile, which is basically just the ability to use the older stuff that they removed from OpenGL 3 in OpenGL 3, which means... that it's not really OpenGL 3 in the first place. It sounds like you need to get some basic rendering working in the OpenGL 3 pipeline before you should start with your voxel world. Don't worry though; rendering a voxel world isn't that complicated once you actually got your first couple of triangles rendered properly.
If you want to target consoles, then Java is definitely the wrong platform for you. Although there are ways to run Java games on consoles, there's currently no known way of achieving hardware acceleration for the graphics (or OpenGL at all), so they're essentially limited to simple 2D graphics. You need to look elsewhere if you want to run your games on consoles, probably the Unity engine and Unreal engine. If you just want to run your game on phones and tablets (as well as PC), then Java is a great choice. LibGDX is the go-to library for that, but LWJGL is seeing initial support for Android right now. Exciting times!
I don't want to be negative, but you may want to take a step back and try to figure out what is actually achievable for you at your current skill level. It's good that you're trying to learn more to achieve your goals, so don't let me discourage you from continuing, but maybe consider starting with the basics and working yourself up from there at least.