In this case it would probably be something like:

mountain.getDouble("latitude")

With at least two advantages: I'm pretty sure what getDouble will do, as opposed to getLatitude which may query google maps for all I know, and it can be processed in abstract ways. You can have operations which work on any structure: serialization, encription, logging, persistence, hash codes, sorting, raporting and a lot more.

Edit: It also makes for easier code reuse. You make something that works with mountains but could work just as well with houses, you don't have to play with class hierarchies to use it on both.

If java has one thing going for it, it's the tooling. Refactoring, eclipses compile errors as you type + quick fixes etc are the only reason to stay in java.

If you program like you are suggesting you lose the only reason to use java, and have to enforce your code using unit tests in a verbose language. No thanks.

In throwing away type safety, you're trading fewer characters for much more fragile code.

The Scala example in the comments demonstrates that you can have your cake and eat it too:

case class Mountain (val name: String, val latitude: Int, val longtitude: Int, var country: String)

It's concise and type-safe, and can readily be used with more powerful aggregate constructs.

And property-esqe syntax would be even nicer:

    mountain.latitude