HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

"Hi, everybody!" the large programmer/teacher announces as he bounces into a class full of aspiring Java programmers. "Welcome to Java."

My name is John Tabbone. I teach Java at NYU's Information Technologies Institute. ITI is a professional program and the students who enroll in my course typically have a diverse skill set. The usual makeup of a class includes C++ programmers, VB and PB developers, Cobol/Mainframe people and a few people whose only programming experience is seeing the new Java commercials. We run the gamut. But beneath the variety of technical backgrounds is the common desire to learn about Java.

People take my class for one of two reasons: They are anticipating a life change or they need to learn something specific for a project they are working on. Regardless, I have found that to learn Java, there is a need to understand principles. Even the seasoned C++ programmers often need a review to see how the principles apply to Java. So that is what I am going to focus on in this column: the principles needed to be a productive Java developer, and how to apply these principles to Java.

So exactly what can you expect from this column? Here are some of the major topics I'd like to address:

  • Object-Orientation
  • Setting up Java (focusing on packages and classpaths)
  • Event models explained once and for all
  • Some widely misunderstood technical topics (threads, file IO, GridBagLayout, etc.)
I intend to write only about the latest versions of Java. It is impossible to be productive in a new technology when your knowledge is outdated. Finally, I'd like to structure this column similar to how I run my class. That means I need feedback and participation. Read my bio for my e-mail address and feel free to use it. One day I hope to do a column with your letters in it.

And let me add this: I have never met a person who was incapable of learning Java. Many people struggle with it, but ultimately they attain a level of expertise that they are satisfied with. Don't be intimidated by the hype. Java has been billed as an exotic, high-tech, esoteric language and many people think it is, therefore, out of their reach. Don't get anxious, don't sell yourself short and above all, don't get frustrated. Ninety percent of Java is based on clearly defined principles. Your hard work will be rewarded.

So let's start by answering some of the general questions I'm often asked about Java.

What is Java? I've seen the commercials, but I still don't know.

Java is a programming language - a tool designed to develop computer software. Most people associate Java with the World Wide Web. This is because one of Java's most unique features is its ability to create applets. A Java applet is a program that can be transferred from the Web site (the server) you might be connected to down to your browser (the client). Once the applet has been transferred, it runs in your browser using a special program called a Java Virtual Machine. The Virtual Machine is a software implementation of hardware. It is not a real machine, like your computer, but software that emulates a computer and runs on your machine. Complicated? Press on!

I don't understand what you mean by clients and servers. Can you explain?

Client/server refers to a concept in system architecture. The easiest way to think of it is to recall your experience in a fast food restaurant. You are a client. You want a sloppy-burger. whom do you ask? The guy with the mop? No. You go to the counter and ask the server. At this point, some kind of transaction will take place. You will request something (a sloppy-burger). The server may state the terms of the transaction (the cost, how many burgers you will receive, do you want fries with that). You may agree or disagree. Or maybe when you get to the server, the transaction arrangements are already defined and you just plunk your money down and take whatever the server gives you. Regardless, the server will fulfill the request in the best way possible and you can go on your way.

The same system works over the Web when using Java. Your browser (the client) makes a request to a server for images, HTML and Java applets just as you might order a sloppy-burger, fries and a shake from a counter person. The concept. is simple, don't overcomplicate it in your head!

OK, I understand client-server, but once the applet is in my browser, how and why does it run?

Let's continue the analogy. Once you get your food, you will sit down somewhere and eat it. You have, built into you, a digestive system that knows what to do with a sloppy-burger. It will accept the input (i.e., the sloppy-burger) and turn it into output (i.e., energy). Similarly, most browsers have a Java Virtual Machine built into them. The Virtual Machine knows how to digest an applet file (the input) and turn it into output (i.e., execute it).

I understand the analogy, but can you explain specifically the process involved in getting an applet to run in my browser?

The applet is stored on the server in bytecode format. Java bytecodes are special instructions that describe how the applet will work, what functions it will perform, how it will look, etc. When you compile your source code (the stuff you write) using javac, javac will produce bytecode, which in Java has a .class file extension and is often referred to as a class file. It is the class file that your client (browser) will request from the server. Once the class file arrives in your browser from across the network, your browser will recognize it and submit it as input for the Java Virtual Machine your browser is equipped with. The VM will then execute the byte code; remember, bytecode is instructions. It is your program.

But why use bytecode and a Virtual Machine? Why doesn't the server just send over a regular program file and not use a VM? Or, why doesn't the server just send over my source code? Why go to the trouble of creating a class file?

Good questions! Let's address the first one. The VM provides two major enhancements to the system. the first being a measure of security. You can be pretty sure that if you eat a sloppy-burger and your digestive system is working well that you will not wind up with a piece of tomato in your nervous system. The input is confined to the digestive system. Similarly, the VM prohibits an applet's interaction with other parts of your computer system and we can be reasonably sure that, under normal circumstances, an applet will not be able to meddle with your file, or memory, system. (you have obviously noticed the caveats I used: an applet can be given special permission to operate on other systems in your computer. stay tuned to future columns for further explanations).

Secondly, the VM provides cross-platform capabilities for Java. Imagine that my digestive system was somehow compromised and could not function correctly. If I had a transplant, I could still enjoy a sloppy-burger, regardless of where the donor system came from. I could still process input and produce output The sloppy-burger does not have to change. The lesson here? A VM operating on one platform can process the same input and produce the same output without changing the applet. What this means to us developers is that if we write our code in Java, we don't have to recompile them for different machines. We can rely on the fact that we are writing for a Java VM and the VM will process input and output (for the most part) in the same way on all platforms.

So, why doesn't the server just send source code to the client? Why is it compiled into byte-code?

Primarily because bytecode is more compact than source code. A bytecode transfer over the network will take less time.

OK I'm getting a feel for client/server Java. Anything else I should know?

Of course! First of all, we have just scratched the surface. These are the principles of how Java implements these things, but there is a lot of technical detail that makes up this system. Secondly, applets are only one form of Java programs. The other is a Java application. An application cannot be transferred over the network as an applet can. The plus side is that an application can interact with your computer's other systems to provide full-featured programs (like word processors, spreadsheets, etc.)

Also, the one big caveat I have to mention is that Java bytecode is interpreted by the VM. This means that your computer can't run Java class files without a VM, so to run any Java program you also have to run the VM (actually, you run the VM which runs the program). This adds overhead to bytecode execution, which typically slows things down.

So, Java programs are slow. What did you say the advantages of Java are again?

I think the advantages outweigh the downside. Reliable cross-platform code has been difficult to develop so far. Distributing applets over the Web is a convenient way of moving applications around the world. And finally, there are a few features of Java that make the development cycle run fast and smoothly.

What are they?

Well, for those of you who know another language and are new to Java, you will be happy to know that there are no pointers in Java programming. Pointers provide a way for programmers to work directly with memory. My guess is that 90 percent of all bugs come from pointers. Second, and what I think is most important, is that Java is an object-oriented language.

What does object-oriented mean?

A good question, since oo (as practionitioners shorthand it) is the key to all wisdom and the subject of my next column.

But don't think you're getting off that easy! Your assignment is to write down what you know about Java and what you want to know about Java. Please be very concise. Send this to me. I may not be able to respond personally, but I will consider your input. Please include the phrase JDJ in the subject line of your e-mail. Also, I want you to read ten more articles that describe Java. Get them from this magazine, from the Web or wherever you can find them. Write a synopsis of each article: what do you understand? What is not clear? Consider these articles before you submit your material.

Finally, for those of you who would like to press ahead, I want you to consider the term system'. What does it mean to be a system? Write down some systems that you have a personal interest in; perhaps it is a new order entry system at work, or maybe you are a medical researcher interested in DNA replication. Or perhaps, like me, the fast-food system really turns you on. Write about these systems (as many as you like) in a fair amount of detail. Hold on to it for next month's column.

John Tabbone smiles, gathers his things, and bounces out of the room. "See you next time!" he says, while overhearing one student say to another, "I didn't know we'd have to do homework."

About the Author
John V. Tabbone is a lecturer at New York University's Information Technologies Institute, where he teaches two Java programming courses and advises on curriculum development. He has been a professional Java programmer since early 1996 and continues to consult on and develop systems for a variety of New York-based businesses. You may e-mail him with questions and comments at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.