It's great that you are driven. You'll get there eventually.
I have some comments on the design of the Point class. It's not about what you CAN do, it's about what you SHOULD do.
Your Point class contains setters for the x and y fields. While setters are unavoidable in some cases, for many types they are actually harmful.
When you think about the points (2, 3) and (4, -1) in 2D coordinate space, you think of them as two fixed objects, right? "Setting" the x coordinate of (2, 3) to 1 doesn't really make sense. Instead, you just think about a new point with coordinates (1, 3).
The reason it's harmful is because you might pass an instance of type Point to another object that assumes that the point will never change. Then when you do change the coordinates of the point, the object that depends on the Point will have been corrupted.
Secondly, use names that are as descriptive as possible. A distance() method without parameters didn't make sense to me until I looked at the implementation. Methods should be clear in their purpose without having to look at their implementation.
Override the toString() method if you can to give your objects a good textual representation for debugging. Override the hashCode() and equals() methods if your class represents a value type: Objects of a value type represent a fixed value that can be compared to another object of the same type, such as the number 7.3, the character 'K' or the point (4, 2). Your Point class is an ideal candidate if you drop the setters.
Make your classes and members as private as possible. Lose the habit of writing public everywhere. Only raise the visibility of a class or method if you really need it outside of the package or class you declared it in.
Make your classes final. This prevents them from being subclassed. Subclassing is a powerful tool, but it comes with a lot of unforeseen challenges that are hard to deal with if you haven't carefully designed your class. The easiest thing is to just prevent it.
Here's an updated version of your class.