Tuesday, January 25, 2011

Java's File Names and Class Names

Java is picky about the file names you use.

Each source file can contain one public class. The source file's name has to be the name of that class. By convention, the source file uses a .java filename extension (a tail end of a file name that marks the file as being of a particular type of file.)

So, for a class declared as such:

public class HelloWorld{
...

The file it is stored in should be named HelloWorld.java.

The capitalization should be the same in both cases. Some operating systems don't notice whether file names are capitalized or not. It doesn't matter, you should be in the habit of using the correct capitalization in case you work on a system that does care about capitalization.

When you compile your file with javac, you pass the full file name to javac:

javac HelloWorld.java

Let's say we save the file under a different name. We write the following program:

public class HelloThere{
public static void main(String arg[]){
System.out.println("Hello There.");
}
}

Then we save it as HelloWorld.java, and try to compile it:

>javac HelloWorld.java
FileName.java:1: class HelloThere is public, should be declared
in a file named HelloThere.java
public class HelloThere{
^
1 error


Java lets us know that it won't compile until we rename the file appropriately (according to its rules.)

So let's rename the file. Let's call it HelloThere.javasource. Seems a bit more explicit than just .java, right? Let's run the compiler:


>javac HelloThere.javasource
error: Class names, 'HelloThere.javasource', are only accepted
if annotation processing is explicitly requested
1 error

Java's still not happy with us. Annotation processing? That's when we include extra information in the program about the program itself. We're not bothering with that just now. So we should just name the file HelloThere.java, and not get fancy with our file names.

But, under the right circumstances, javac does allow file name extensions other than .java. That's why we always type in the full file name, including .java, when we use javac. We say 'javac HelloThere.java', not just 'javac HelloThere'. Javac can't assume that we mean a .java file, though that's what it will usually be.

The Class File

Once we make javac happy with a proper file name, and a program with no errors, javac produces a new file. This file will have the original file name, but with .java replaced with .class. This is your bytecode file, the file that the Java Virtual Machine can run.

When we run the program with Java, we're running the .class file. In the case of HelloThere, we're running the HelloThere.class file. But we don't type in the full file name. Why?

Unlike javac, java requires a .class file. That's all it will work with. There's no opportunity to have a different extension to the file name. So it assumes the .class part of the file name. But that's not the whole story.

If you add .class yourself, here's what you'll get:

>java HelloThere.class
Exception in thread "main" java.lang.NoClassDefFoundError:
HelloThere/class
Caused by: java.lang.ClassNotFoundException: HelloThere.class
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

Pretty ugly. What we're actually doing when we type "java HelloThere" is telling Java to run the class HelloThere. Java assumes that it will find this in a file called "HelloThere.class", so that's what it's looking for first.

We're not telling Java to run the file HelloThere.class, we're telling it to run the class HelloThere, which it expects to find in the file HelloThere.class.

But what if we ask for another class that doesn't have its own .class file?

Just for fun, let's change HelloThere.java like this, and see what happens:
public class HelloThere{
public static void main(String[] arg){
System.out.println("Hello.");
}
}

class HelloZoik{
public static void main(String[] arg){
System.out.println("Zoiks!");
}
}

After we edit it, we compile with 'javac HelloThere.java' and hold our breath.

Hurray! No errors!

Now we have a second class, HelloZoik, in the HelloThere.class file. Can Java find it?

Let's try:
 java HelloZoik
Zoiks!

It worked! Java found our class inside HelloThere.class.

This shows it's not the file name that we're calling with the 'java' command, it's the class name.

If Java doesn't find the class inside a file with the same name as the class followed by .class, it'll look in the other .class files available.
StumbleUpon

Tuesday, January 4, 2011

Should I Still Learn Java?

With all the controversy surrounding Java thanks to the purchase of Sun by Oracle, the lawsuits flying back and forth over the Java Community Process, the Apache Foundation, Android, and all the rest, does it still make sense to learn Java?

After all, the demise and abandonment of Java is being predicted practically every day.

I say Yes, now is the time to learn Java. No matter what your programming skill or background, Java is a valuable language to learn, it will be used and useful for a long time to come.

Never a Dull Moment

The Java language has been a-swirl in controversy since its public announcement. It has not become "the" language in many of the areas it originally claimed to be "the" language to use, but yet it has become popular in many other areas. In fact, Java is neck and neck with the language C for being the most popular computer language:

TIOBE Software Community Index (of most popular programming languages.)

langpop.com Programming Language Popularity Rankings.

Devtopics.com Most Popular Programming Languages.

Why Popularity Matters

Why does popularity matter? Because it entrenches a programming language, not just for now, but for many years to come. In fact, every language that has ever become deeply entrenched is still with us, so there's no way of knowing just how long popularity will keep a programming language alive.

When I was first learning to program, the big languages were assembly (the "real" programmer's language of the time), BASIC, FORTRAN, and COBOL. Every single one of those is still a viable language today. Though if you'd asked me then, I would never have thought COBOL would still be with us today. I would never have believed how popular it is, either.

But COBOL was re-invented in the late 80's. And there were a lot of big-money installations running on it. ADA failed to displace it. It's still here, and it's still a valuable part of a programmer's resume for many jobs.

FORTRAN is a language I expected to re-invent itself. It had already done so by the time I learned it (I first programmed in the original FORTRAN, but FORTRAN IV was already in common use.) But with the promulgation of Pascal, Modula-2, and C in the 80's I figured FORTRAN would be pushed into the recesses of obscurity. I was wrong.

Modula-2 was mishandled by the company that owned the rights to it, so it never took off as well as it might have. Pascal took off even though it was never intended to be anything but a classroom language. C took off since it didn't have Modula-2's licensing disadvantages and it had enough of its advantages to become the "next generation language" of its day.

Modula-2 is still with us, but it's insignificant among languages today. Because it never got popular. The others I mentioned got popular, and they're still popular today. Yeah, even Pascal. You could learn Pascal today and do a lot with it (though I don't recommend it unless you want the academic challenge of broadening yourself as a programmer.) I still write software in Pascal, though mostly for my own use, and only for older computer systems.

The key to a programming language's longevity is popularity. Once a language becomes sufficiently popular, for all practical purposes it will never die.

Java is that popular.

The Many Javas

Java has become deeply ingrained into the modern computer infrastructure. Not only does the Java Virtual Machine support a lot more languages than Java itself, but Java has spawned other languages so close to itself that if you know Java you can pick up the other languages without significant effort. C# is the most popular of these spin off languages.

Plus, there are different versions of Java. The Mobile Edition, used on cell phones, smart phones, and PDAs, is a major programming language for these platforms. Each of these platforms has its individual programming suite, and associated language. Their second language, the Esperanto of the portable world, is Java. Programmers that want their software to move easily between platforms often choose to write their code in Java.

The use of Java on servers is rife as well. Java Enterprise Edition became the most popular use of the Java language when Java was still struggling to be used as an applications programming language over a decade ago. Some say that Java on the server saved the Java language. Certainly this is what makes Java a good language to learn for professional reasons.


The Most Important Reason

The most important reason to ignore all the hullabaloo about Java's impending demise and not worry about learning it is that:

  • it is a good language that's fairly easy to learn,

  • expressive enough to do a lot of different things effectively,

  • easy to develop sophisticated modern programs in

  • without too much work for an individual or small group of developers,

  • gives access to all the important parts of the machine (graphics, sound, filesystem, peripherals)

  • and what you learn travels well to other languages when you go on to learn them.



It's not going to go away any time soon. There's too much momentum. There's no need to worry. Ever since the launch of Java I've heard that it's going to be gone or unusable tomorrow. History shows that just doesn't happen to popular programming languages.

If you learn Java now, you may still be using it 20 years from now. Or 30.

When I sat down to a card punch to write my first program 38 years ago as I write this, the computer lab know-it-all came to look over my shoulder.

"FORTRAN!" he said. "Why are you wasting your time with that language? It's a dead, old language. Did you know it's the oldest computer language? If you really want to be a programmer, you should start right out in BAL*! That's what real programmers use, and you're going to be behind if you waste your time on anything else."

FORTRAN doesn't make the "top 10" in programming languages much any more, but it gave me a good start. It's still among the most popular languages, around #20, or just out of the top 10 if you only count general purpose programming languages (that is, not counting scripting languages, query languages, application-specific languages, and so on.)

And learning FORTRAN never kept me from learning structured languages, AI languages, Object Oriented languages, and so on. Even though my first program included the "dreaded" GO TO statement.

There's never been a better time to learn to program. And there's never been a better time to learn Java (the language is in the best shape it's ever been!)

*Basic Assembly Language, a version of assembly language for IBM computers.
StumbleUpon