Learning Java in stages

This page is in response to questions like this one:

Hi. I'm writing a JSP which talks to a database using JDBC, then responds with XML to the applet which is querying it. I've downloaded a servlet engine, and it says I need to get my CLASSPATH setting right. What's a CLASSPATH setting?

By the way, I'm new to Java.

Okay, that's a bit extreme, but you get the idea. Many people are trying to dive straight into the deep end of Java, using not one but several APIs they don't know, at the same time, in a language they don't know. (In the case of JSPs, it may well be a programming language they don't know embedded in a markup language they don't know either.)

I tend to respond to such questions by telling people to learn from the ground up. I sometimes do this rather overzealously, and I've put people's backs up before now. That's why I'm writing this page - to explain in a cool, calm, collected and hopefully inoffensive way just why posting the above question isn't likely to get you many pleasant responses on newsgroups.

Why don't you just answer the questions?

Firstly, it's not out of malice. It's not out of contempt or condescension. It's in a spirit of hoping to help you learn faster so you don't even need to ask as many questions in the future - and so that the questions you do ask will be more appropriate ones, hopefully with a narrower scope.

I could just answer each question like this that comes up. Some people still do. In my experience, however, if you answer one basic question in a complex system, you'll be asked another basic question by the same person within a couple of days. It may well be the same basic question in a very slightly different context - it'll be obvious to those who know the basics that it's the same question, but from the point of view of the poster it may look entirely different, all because they didn't learn the basics first.

Trying to teach people the basics of Java on the newsgroup isn't very productive to start with - textbooks are generally much better for learning Java itself, with occasional questions for specific areas which aren't understood being appropriate for the newsgroup. Now trying to teach people the basics of Java if they don't really believe they need to learn the basics of Java (let alone learn them before moving onto complex systems) is even less productive. It wastes the time of those reading and then ignoring questions, it wastes the time of anyone prepared to keep answering questions, and it even wastes the time of the person asking the questions. I far prefer to try to persuade people to learn Java in what appears to be the long-winded way, but which is actually the way most likely to get them to the results they need in the shortest time. I'm not trying to be nasty or anything like that - I'm trying to benefit everyone.

What's wrong with diving in at the deep end?

Even if it works first time, chances are it's not working nearly as well as it would if you knew details about each layer. And frankly, the chances of it working first time are very slim. They're pretty slim for someone who does know the details of each layer - but then the difference comes when it doesn't work first time. Suppose you get a syntax error somewhere: someone who knows Java fairly well could probably work out what the syntax error is quickly, without knowing the details of the API it's talking to. As someone who doesn't know Java, however, you don't know whether it's something specific to the API you're using, something that's generic to Java, or something else you've set up wrongly in some completely different place.

This is where building up one piece of knowledge at a time comes in extremely handy. Usually, one of the responses to me suggesting this is that the poster doesn't have time to learn Java before learning JSPs or whatever. In fact, I'd say they probably don't have time not to learn Java before learning the other APIs. It's like trying to learn to conduct an orchestra to play a symphony without learning to read music first. Yes, you could memorise every detail of the music, watch other people conduct the same symphony and copy their movements, etc - but it makes much more sense to learn to read music, then learn what conducting motions mean what, then apply one bit of information to the other. Chances are it will take you a lot less time to do so, and you'll end up with a better performance at the end of the day. The same is true for Java. Writing an enterprise application by trying to find snippets of code which do similar things to what you want to do is a painful business, and you won't end up with a maintainable app. Furthermore, when things go wrong you won't understand how it's meant to work, so you've got no chance of working out why it's not in fact working that way.

So, what should I learn first?

My suggestion for everyone is to learn the basics of Java itself first. Write strictly console applications - first use just the classes in the java.lang package, then learn how I/O and the collection classes work (ie you can import classes from java.io and java.util. Almost everything will need to use classes from these three packages in the end, and you should be able to find lots of exercises to do which will only require these. Try a bit of polymorphism, maybe declare and implement your own interface - the basic language features. This should also help you learn the basic tools (either your IDE or the command line tools provided by the JDK). You will hopefully get some idea of how the JVM finds classes, etc.

Most apps these days require some knowledge of threading - so try writing a few very simple multi-threaded apps. By "very simple" I mean as simple as having one thread counting up to a hundred and another one counting down from a hundred. Really basic stuff - you should know how to do everything you need other than the threading before you start the threading bit. Once you've got two or more completely independent threads working, try some inter-thread communication with synchronized blocks, wait and notify. If you really don't think you need any of this, of course, (eg you're just writing a single-threaded mathematical model) then you can skip this. GUIs and server-side Java will almost certainly require some understanding of Java's threading model though.

If you're going to write a GUI app, now would be a good time to start learning GUI stuff - but learn the GUI side of things on its own, without trying to make it do what your final app will need to. Isolate each bit of GUI functionality and try to get that working with entirely dummy data. If you're not going to write a GUI in the near future, it's probably best to avoid learning about them at all for the moment - they're pretty confusing, IMO, and you've probably got better ways to spend your time.

If you want to write an applet, now's the time to learn that - after you've got the hang of basic GUI applications. There are various extra rules that come with applets - mostly to do with security, but you also have to learn how different browsers handle different things. You'll need to decide whether to target your applet at plugins or at the VMs which come with the users' browsers - and that can make a huge difference in terms of the rest of your code.

Whatever APIs your app needs - servlet, JSP, JDBC etc - should be learned now. Learn each in isolation, having learned any underlying technologies first - for instance, if you need to write a JSP, you should write and test some simple servlets first, as it'll be much easier to understand what a JSP is doing when you understand that it's converted to a servlet first. The "in isolation" bit is important - write minimal programs for each API. For instance, when learning JDBC, try a console app first which just lists a ResultSet - don't go straight for a servlet trying to talk to a database at first.

When you run into problems, isolate them as far as possible - if you can write a short example program which demonstrates the problem but doesn't do anything else, that's great. Chances are you'll find the problem while you're writing and pruning such a program - but if you don't, you'll be much more likely to get help on the newsgroups if you post that program.


Back to the main page.