Edison’s Cup of Java (4/8/2007) - series 3 of 999

creativecommons

Ah, so you came back for more! Then I must say your passion to learn or perhaps curiosity motivated you to come spend some time with me for this “jump over the river” Java cup session. Having said that iterates my fair early warning that this topic will not be as specious as it looks. This article will be the deciding factor whether you will be more motivated to continue on in attaining a Java skill level-up or you go back to your “wish I can Java” day dream.Just to set things straight, I will stand pat with my principle to remain creative and thus up to a certain degree maintain my originality. For after all, since my chosen IP copyright is creative commons, my goal is to share to you my approach or my very own signature strategy in learning Java. Therefore, I will not rewrite or worse plagiarize what has been written by somebody else—the bane of many other bogus technical writers. Instead, if I see it fit, I will refer you to pages that will benefit both you and me.

Having that cleared out of my throat, let’s move on into achieving our goal.Go ahead and open your installed offline Javadoc by clicking on index.htm. You can also access it online through http://java.sun.com/javase/6/docs/.

The page welcomes you with a section called “platform at a glance”. My bet is you are already intimidated and overwhelmed by the sight of it. Don’t be. As the section is appropriately labeled, “at a glance”, just give it a quick look. You can come back to it a million times later as may be needed because that is what we experienced Java developers do. For the newbies, going directly to what you will mostly need is like going through finding a needle in a haystack—for there are multitudes of links out there in the Java jungle that could easily get you astray—the key is always knowing what and where to find it—keep in mind however that anything about the Java language specifics, your starting point will always be the Javadoc or for a more wider breadth, consider going direct to java.sun.com. Going forward, click the Java cup of this session which is the lang and util base libraries—its sugar-free! But if you wanted some optional creamer and sweetener, we will also cover lightly the Java LAF or Look & Feel libraries aka JFC or Java Foundation Classes a bit later.

Key concept to Sun and many of its technologies is the idea that everything can be contained. Like our Solar system is contained via the Milky Way or the Galaxy, every Sun Solaris OS instance has its own containment system, and so does every Java object or component groupings—whose containment system is generically called a package. The smallest package in Java is equivalent to a folder or directory of a filesystem. A package may contain multiple folders. A package may be uncompressed normally on development phase while it may also be in compressed form such as a ZIP or a JAR (Java archive) when deployed or when in production phase. Speak of tactical edge; the JAR is the selling point that sets it apart from any other competing language, for its behavioral properties manifest the very intent of mobile codes (platform independent)—and nothing else comes closer.

I have covered a mile of disclaimers, expectation settings, and fundamental preparations already but we just barely touched the tip of the iceberg for this topic. So now allow me to serve it to you, like so.

The java.lang

This package contains most of the fundamental core Java objects or classes that you will eventually use as base objects and the APIs for your application.

A high 60% of our code processing and object manipulations will be the String object because of our inherent need for a human-readable form of information, this is closely followed by Math as many of our number crunching and natural computer instructions or operations need will be provided by this base object. At the root of all these is the Object class which all other objects in Java extend. The Object class is a superclass or parent of everything in the Java object hierarchy.

Have you ever tried or considered developing the code that will handle multiple threads of execution in other languages such as in C/C++? The requirements are daunting since you have to evaluate and strategically choose the right algorithm with the appropriate context switching protocol that will suit your needs—this will definitely require a whole lot of codes. In Java, this is achieved only through a base object called Thread, a simple task which can comprise only five lines of codes, at most, when used.

Understanding Threads requires at least a chapter to discuss, so let me condense this into just a couple of paragraphs. By default, there is however at least one thread that gets executed—the mother of all threads—the JVM. All other application specific threads that extends the object Thread or implements Runnable may run as sub-threads orbiting the mother thread. Threads give your applications the capability to multi-task in a time-sliced fashion.

Before going forward from this point, I will have to validate that you have read the suggested core classes, for from hereon; it will be mostly practice for this section.

Recall the first String object you have stumbled on in this topic so far. Can you? You bet, it’s the String [] args signature passed to the generic method main in our MyFirstCupOfJava program. Suppose we modify it with the objective of displaying the String objects found added as arguments in the command line, the code that we could possibly come up will be something like this,

public class MySecondCupOfJava {
public static void main(String [] args) {
System.out.println(”Hi, World!”);
if(args.length == 0)
{
System.out.println(“Sorry, found no String objects passed as arguments in Command line”);
}
else
{
System.out.println(”These are the String objects I have read from the command line…”);
for(int i=0; i
{
System.out.println(args[i]);
}
}
}
}

Yes you have observed it right. I missed discussing an object called System in my previous Java cup session. That was deliberate. The reason I withheld discussing it earlier was more for propriety, nothing more, and nothing less. The topic was out of scope in the earlier section, so we will touch on it here instead.

System does a whole lot of useful things; among most notable is its function as an excellent facility for the standard I/O (input and/or output). Its existence can be attributed to its console/terminal mode character/text-based I/O legacy. To output any character into any GUI-based window that simulates the console, we have the System.out.println(Java object); w/c can print any Java object, from null or empty (which will be interpreted as a new line), to binary, or to any context that we as humans can evaluate or understand. System.out is a façade for the PrintStream object. For input, a call to System.in is similar to instantiating the InputStream to read the stream of input characters that typically is coming from the keyboard, unless specified otherwise. For outputting an error message we may use the System.err utility which is also a façade for the PrintStream. System.err is seldom used as it has not much significant distinction from the System.out facility.

The second logical line from the example source above is a form of filter that handles a probable abnormal situation, in this case, a possible zero or no arguments passed. Our handler will output to the console an intuitive statement that conveys the error and thus gives us an excellent hint what the root cause was. As a developer or programmer, it is not intuitive enough to simply use System.out.println() even if it functionally works the same using System.err.println() is recommended for contextual readability. Go ahead and improve the source by using the suggestion. As an added note, there are several variants of the print method; I assume you have already noticed this in the System.out and PrintStream pages of the Javadoc.

Other use of the System object is a call for current system time in milli or nanoseconds granularities. There are also quite a handful of development/test phase benefits in using exit() to do an abrupt application run-time termination. Then peeking and tweaking system properties can also be quite useful to determine application identity and signatures—simply ensure that your calling method has the appropriate access control that can be configured through the SecurityManager object.

Now that we’ve covered such a wide tract for an article, the other major section shall be discussed on another part. We have learned so far that in order for us to jump start our goal to learn Java, we should begin knowing how to use the Javadoc. Then be familiar with its objects such as the java.lang package. The java.util package will be covered on the next part or series. I hope to see you here again next time.