Java has great free and Free development tools like Eclipse and NetBeans. You can also get the community edition of IntelliJ, or a paid edition.
Java, and its development tools, run on every desktop: Mac, Linux, Windows.
If you know Java, then you've already got a leg up on doing Android development; and doubly so if you use Eclipse or IntelliJ.
If you want to develop complex web applications, then Java is the way to go. You can write a large web application in a dynamic language, but maintenance will become a long term problem in a gigantic code base. There is a reason that Java is used for very large websites. (Not to confuse large with high traffic.)
Java is used in high speed trading.
Java is used in the SIM card of your phone. Your bluray player.
Once you are familiar with running Java on the JVM (Java Virtual Machine) you'll discover that there are dozens of other languages that run on the JVM with complete interoperability with other JVM languages. This is because of the common runtime and type system, and because of GC. With GC in the underlying runtime, the entire contract of who is responsible to dispose of what goes away. Did this library create that data structure? Maybe, but nobody has any responsibility to keep track of it and dispose of it.
The JVM is an industrial strength platform. You can have heap sizes of dozens or hundreds of gigabytes. With a dozen gigabytes you can have GC pause times under 10 ms with little to no tuning. If you need hundreds of gigabytes in a single heap with 10 ms GC times, then contact Azul systems who can sell you their Zing JVM. Which brings up the fact that JVMs (like everything in the Java world) has multiple vendors. Don't want to run Tomcat, then use Jetty, or one of several other choices.
Your favorite language compiler emits JVM bytecode which the JVM compiles into native code. It has an extremely aggressive global optimizer. The JVM compiler can optimize globally, something that compilers like GCC cannot do. The JVM can inline other methods into YOUR method. But the JVM can also dynamically reload classes. So what happens if class A is reloaded, but your method now has stale inlined code from Class A? The JVM will de-optimize your method so it is back to running as interpreted JVM bytecode. Now if your method (still) is one of the CPU hotspots, then the JVM will re-compile your method back to native code again. The overall application never stops. The only methods that get compiled to native code are the ones that dynamic profiling proves to be ones that would make a difference to aggressively compile. Call me when you other language runtime can do all that.
Java is where the jobs are. Look for yourself.
There is much more. But I'll stop.