Learning Java

Okay, so here I am, learning Java. I've put it off for many years. Learning Java has always been compelling, but more along academic lines: As pervasive as it is, I should just know it.

I tend to need to write stuff fairly quickly (misc tools don't need to be particularly well-written). So, I usually script my way out of trouble. When I need a GUI app, or just need to show additional polish, I reached for DevStudio - Microsoft makes those one-off apps easy.

My goals are pretty simple: learn enough to

• Administer java application containers
• Diagnose Java application problems
• Understand it well enough to use a high-level language (Groovy, JRuby) effectively
  

I'm not unfamiliar with configuring Java containers, but I'm in no way an expert. I like the overall...explicitness?...of it. So far, I haven't seen anything that I couldn't really pull off on other platforms (Apache or IIS), and there is a cost of initial complexity.

However, as the overall configuration becomes more complex, java containers simplify things - all that explicitness pays off. Part of the appeal, given my current path, is that I can take a couple of these java based OSS projects (OpenNMS, ActiveMQ, Solr), and stuff them all into one JVM. Or not. (and I really look forward to learning how many problems doing it causes :) )

One thing Java got right was that it was all-Java right from the beginning. If you were coding a Java EE app, you were writing in Java. Microsoft's decision to foster backward-compatibility by encouraging interop wrappers around existing Win32 dlls has been a huge headache. While appserver admins were wrestling with classpaths (and arguing with devs about the location of physical files which are being written to), MS admins were building dozens of small machines because native.dll from vendor A's ".NET application" collided with native.dll from vendor B, who actually went out of business three years ago. I've dumped too many things into VMs because of that crap.

MS and it's ecosphere has certainly gotten better, but there's still sticking points (do we really need a Global Assembly Cache?).

What about the language? Surely I can't talk about "Learning Java" without talking about the language!

Well, I can't talk much; I've only been at it for about eight hours. A nice chunk of that was spent learning about classpaths, and changing the location of where apps were writing files on the physical disk. I'm being all old-skool about it, too. I've got Notepad++, the JDK, and a couple of powershell scripts as my dev environment. I know there's better and easier ways to do get things done, and I'll get to using them eventually. For now, I want to know what's going on under the covers.

For my first trick, I created a bunch of unnecessary abstraction ultimately resulting in getting some rows from a database, and dumping them to the console.

Why do I have to declare my potential exceptions? If the compiler knows enough to know that I didn't declare an exception when I should have, why doesn't it just stick it in there for me?

I thought it was neat that I didn't necessarily have to include, er, import namespaces. (At least I didn't need to with the Postgres adapter; I don't know all the rules to this, yet.) It was neat until I had to start adding "throw ClassNotFoundException" on all of my functions, anyway.

Having one general abstraction for databases is nice, too ("java.sql.*", vs. "SQL and OLEDB" everything). In fact, there's some nice generalizations for just about everything to accomodate that EE specification.

Anyway, I'm having fun, and I'll keep y'all posted.