Ans : Following steps makes easy to learn java.

1. Start with a java tutorial provided by sun.

2. And get basic book that covers all language fundamental, U can get several java book online too..( See our Related Doc or Related books for more info.)

3. You can also get a compile from sun site to write and test sample programs.

Ans : Latest version is J2SE™ v1.3, still u can find updated at www.javasoft.com

Ans :  Java is Y2K compliant in release JDK 1.1.6 and later. See, Prior to this release there were certain corner case bugs that had to be fixed. The Date class, as you can see from the discussion, contains more than enough resolution to represent dates in this century and the next and the last. The SimpleDateFormat when parsing a 2 digit year could cause problems.

Ans : No, no, a thousand times no. Java does not have pointers, no way. Java does have references. A reference is an abstract identifier for an object. It is not a pointer. A reference tags a particular object with a name in the Java virtual machine so that the programmer may refer to it. How exactly the virtual machine implements references at the level of machine code is VM-dependent and completely hidden from the programmer in any case. Most VMs including Sun's use handles, not pointers. A handle is a pointer to a pointer. At the level of machine code in the CPU a reference is an address in memory where the address of the object is stored. This way the objects can be moved around in memory and only the master pointer needs to be updated rather than all references to the object. This is completely hidden from the Java programmer, though. Only the implementer of the virtual machine needs to worry about it. Indeed, this is not the only way references can be implemented. Microsoft's VM actually does use pointers rather than handles. Other schemes are possible. 

Ans : Of all the misconceptions about Java, this is the most egregious. Far from not having pointers, in Java, object-oriented programming is conducted exclusively with pointers. In other words, objects are only ever accessed through pointers, never directly. The pointers are termed "references" and they are automatically dereferenced for you.

Java does not have pointer arithmetic or untyped casting. By removing the ability for programmers to create and modify pointers in arbitrary ways, Java makes memory management more reliable, while still allowing dynamic data structures. Also note that Java has NullPointerException, not NullReferenceException.

A linked list class in Java might start like this:

public class LinkedList {
public LinkedList head;
public LinkedList next;
public Object data;
public LinkedList advanceToNext(LinkedList current) { ...
}

Another choice for a linked list structure is to use the built-in class  java.util.Vector which accepts and stores arbitrary amounts of Object data (as a linked list does), and retrieves it by index number on demand (as an array does). It grows automatically as needed to accommodate more elements. Insertion at the front of a Vector is a slow operation compared with insertion in a linked list, but retrieval is fast. Which is more important in the application you have!.

Note: java.util.Vector is thread safety.. so it is slow. If you are not worried about thead safety, it is better to user java.util.List.

Ans : Some popular IDEs include: 
 

Apptivity (Progress)  Blue J (free)  Bluette (free)  Chicory (free)  CodeWarrior Professional  Freebuilder (free)  GRASP (free)  Grinder  Java WorkShop (Sun)  Javelin, Visual Object Development for Java  JBuilder (Inprise)  JDE for emacs  Jirvana (free)  JPadPro  Kawa (Webcetera)

Metamata   NetBeans (Swing-based)  PARTS alpha (ObjectShare)  PowerJ (Sybase)  SilverStream   Simplicity for Java  Super Mojo (Penumbra)  SuperCede (Asymetrix)  teikade (PFU Ltd)  Together/J (Object Intl Inc.)  Visaj (Imperial SW Tech)  VisualAge (IBM)  Visual Cafe (Symantec)  Visual J++ (Microsoft)  Xelfi 0.94

Ans : On a Solaris system, you can use the pkginfo command, like this:

pkginfo -l SUNWjvrt

It will give a reply like this:

PKGINST: SUNWjvrt
NAME: JavaVM run time environment
CATEGORY: system
ARCH: sparc
VERSION: 1.1.6,REV=1998.07.30.16.21
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
...etc

You may also try

java -fullversion

Although that's not an officially-supported command option, and has
gone away in JDK 1.2. Try also

java -version

Ans : They are functionally equivalent, with minor differences in the handling of default classpath and options supported. To reduce confusion, the jre command was removed in JDK 1.2. Instead there is a "java" command in both bin and jre/bin.

jre.exe is the java launcher that comes with the Java Runtime Environment. It ignores the CLASSPATH environment setting in favor of its own internally generated default and whatever is supplied on the cmd line using -cp or -classpath. It's intended to be a bit simpler for those who are only ever running Java programs, not developing them.

java.exe is the java launcher that comes with the JDK. It uses the CLASSPATH environment setting as a starting point and then tacks on its own internally generated entries.

They both serve the same purpose and that's to start a Java VM, have it run a Java application, then terminate. The source for jre.exe is provided in the JDK. The source to java.exe is provided only in the JDK Source distribution.

Ans : The first way is
javac *.java

Another way is
javac -depend tip.java

where "tip.java" is a class "at the tip of the iceberg", i.e. that depends on (uses) all the other classes. Typically, this may be your main class. However, "-depend" is known to be buggy and cannot be relied upon. It also doesn't issue compile commands in parallel to make use of multi-processor systems.

Without the "-depend" option, the standard "javac files" doesn't look beyond the immediately adjacent dependencies to find classes lower down the hierarchy where the source has changed.

The -depend options searches recursively for depending classes and recompiles it. This option doesn't help when you have dynamically loaded classes whose names cannot be determined by the compiler from the dependency graph. E.g. you use something like
Class.forName(argv[0]);

The author of the code using those classes should make sure that those classes are mentioned in a Makefile.

Ans : Compiling into native code destroys portability, which is one of the main benefits of Java. If you want to create a native executable because you wanted to make it easy to distribute and use programs, consider a Jar file instead.
Some companies make products that do this. See the webpages for Symantec , Supercede , and Tower Technology . The first two are targeted to Windows. Tower Technology supports several flavors of Unix. Also, there is a native Java compiler from IBM, known as the HPJ (High Performance Java) compiler. One user has reported that it created a 2Mb executable from a 12K java file, and did not run any faster. See  http://www.alphaworks.ibm.com/ 

See also Instantiations JOVE , the paper about the Toba project , Network World, "Vendors Rush To Speed Java Performance", Feb 9 1998, at http://www.nwfusion.com/news/0209java.html 

Compiling to native code takes away the most significant benefit of Java: portability of executables. Further, if you want your Java DLL (or .exe) to interact with C++, you'll have to specify which specific C++ compiler and/or actually compile some sort of linkage via the appropriate C++ compiler. C++ does not have a standard ABI, so there is a big problem with interoperability. Every C++ compiler uses a different object model, a different way of laying out class members, and a different way of "mangling" names for the linker. C is much simpler. The only question here is how structures are "packed" (i.e., are integers aligned on four-byte bounds?). All the C++ compilers can interact with C code, thanks to 'extern "C"' declarations. Consider carefully why you want to compile to a native executable, and whether there is a Java way to accomplish your goal. There may be a good reason for compiling to native code, but it needs to be thought through.

Ans : Sun's javac Java compiler is written in Java. Sun's java JVM interpreter is written in Java with some C, C++ for
platform-specific and low level routines.Sun's Java Web Server is written in Java.

Other companies have chosen other approaches. IBM's Jikes compiler (which is praised for its speed) is written in C++, but of course each version only runs on one platform. Jikes versions have been prepared for IBM AIX, Linux Intel (glibc), Win95/NT and Solaris Sparc at http://www.alphaworks.ibm.com/formula/jikes. 

Ans :  In JDK 1.1.x you use the commandline option "-Dnojit". In JDK 1.2/2 you use "-Djava.compiler=none"

One reason for turning off the JIT is to get more information about any exception that is thrown in your code.

Ans :  javac foo.java > errorfile doesn't work.

 javac writes errors to stderr, The problem is that DOS doesn't allow stderr to be redirected (as command.com is very poor software). So you have to use a special error redirection mechanism in the compiler:
javac -J-D javac.pipe.output=true myfile.java > errors.txt

In JDK 1.2, you can use: javac -Xstdout You typically use this when a compilation produces a lot of error
messages, and they scroll off the DOS window before you can read them.

Alternatively, you can get a scollbar to appear on a DOS window by changing the properties with the "Layout" tab. Change the Screen Buffer Size Height: to some multiple > 1 of the Window Size Height. E.g. use a buffer height of 100 and screen height of 25 (the default). This will give you three buffers of scroll "history." The DOS limitation is improved in NT, where you can write javac myfile.java 2> errors.dat 

Ans : Environment variables are not used in Java, as they are not platform-portable. The Mac doesn't have environment variables, for example. A Windows 95 application not started from a DOS window does not have environment variables. Use properties instead. It was a design error in JDK 1.0 that programmers had to set the CLASSPATH environment variable. This should have been set in a property file

Create your own properties file (see java.util.Properties) or specify them with the -D option when you invoke the interpreter or JRE. Additionally, on some systems you can set a property from the command invocation line like this:

java -Dfoo=$foo MyClass (Unix)

or

java -Dfoo=%foo% MyClass (Win95/NT)

This sets the "foo" property to the value of the environment variable foo, and makes it available in the System properties. Make sure you do not leave any spaces after the -D or around the = sign. Inside the program you get the value with:

String env = System.getProperty("foo");

More simply, just put the environment variable on the command line and read it as arg[0].

java MyClass %FOO% ; Win32
java MyClass $FOO ; Unix

Finally, you could execute a Runtime process to get the environment variables if you are on a platform that has them.

import java.io.*;
import java.util.Properties;

public class Main {
public static void main(String[] argv) {
Properties envVars = new Properties();

try {
envVars.load( // use "set" on Windows
Runtime.getRuntime().exec("/bin/env").getInputStream());
} catch (Throwable t) {t.printStackTrace();}

System.out.println("\n\n" + argv[0]
+ " = <" + envVars.get(argv[0]) + ">");
}
}

This is not a Pure Java approach as it builds platform-specific
knowledge into the program. See Question 10.6 for more details. On
Unix, the command that prints environment variables is "/usr/bin/env".
On Windows95, it is "set"

Ans  : Control-C is used on some OS's to break into a running program interactively and terminate it. On Unix Control-C is sent to the process as a signal. If a C program declares a handler for that signal, the program will be able to continue even if Control-C is sent to it. Control-C is not a Java concept, and there is no way to do this in pure Java. You can write the signal handler in C however, and impose the handler by calling the C routine through the Java Native Interface.

Ans : The naming conventions are straightforward:

1 .  Package names are guaranteed uniqueness by using the Internet domain name in reverse order: com.javasoft.jag - the "com" or "edu" (etc.) part used to be in upper case, but now lower case is the recommendation.
2 .  Class and interface names are descriptive nouns, with the first letter of each word capitalized: PolarCoords. Interfaces are often called "something-able", e.g. "Observable", "Runnable", "Sortable".
3 .  Object and data (field) names are nouns/noun phrases, with the first letter lowercase, and the first letter of subsequent words capitalized: currentLimit.
4 .  Method names are verbs/verb phrases, with the first letter lowercase, and the first letter of subsequent words capitalized: calculateCurrentLimit.
5 .  Constant (final) names are in caps: UPPER_LIMIT. Other sites:
6 .  Check out the section "Naming Conventions" in the language specification:  
7.  Also take a look at Doug Lea's draft coding standards:  

Ans : OK, so that’s really two questions. One of the priorities in creating the Java language was to keep the language simple. Or more specifically, the goal was to avoid a lot of the complexities of C++. One of the common complaints about coding is the work you must do to manage your memory, not to mention the consequences if you don’t do it properly. Studies have shown that up to 50% of a programmer’s time, when using non-garbage-collected languages such as C and C++, goes into managing memory storage. And, a significant amount of debugging time goes toward tracking down memory-related bugs.

The beauty of the Java Virtual Machine is that it takes care of memory management for you. This process is called automatic garbage collection. A low-priority thread periodically scans your applet’s memory for unused objects and recycles the memory they were using. It does this by keeping track of what parts of your program are using memory, and determining when those chunks of memory are no longer needed. Many programmers mistakenly think that garbage collection is inherently slower than manual memory management. This impression stems from the fact that up until now, most mainstream languages that used garbage collection were interpreted and thus inherently slow themselves. In fact, a well-implemented garbage collector is on average as fast if not faster than the best implementation of manual memory management. A well-implemented garbage collector can be faster than manual memory management because it can reclaim unused memory in one fell swoop instead of in hundreds of small increments.

As for multi-threading, we just saw one very good use of multiple threads. Aside from garbage collection, today’s fast microprocessors can easily support multiple threads of execution, allowing more flexible and robust solutions to many classical programming problems. For example, any asynchronous task, which requires polling of a state flag, can be spun off into a separate thread allowing the main thread of execution to continue unabated without worrying about the result of the task.

Ans : The real question is, “How fast is Java in relation to other programming languages?” The answer is, Java falls somewhere in between the speed of static languages such as C/C++ and dynamic languages such as SmallTalk. Preliminary benchmarks show that Java byte codes typically execute at about 50% of the speed of well written C code for processor intensive tasks. The bottom line is that Java is significantly faster than dynamic languages such as SmallTalk and interpreted languages such as Visual Basic. The secret to Java’s speed is the design of the virtual machine instruction set. The instruction set is close enough to most native CPU instruction sets that there is very little overhead in translating from Java byte codes to native instructions. Future versions of the Java byte code interpreter will be able to translate from Java byte codes to native machine code on the fly (also known as “just-in-time compilation”), which will result in even greater execution speed.

Ans : As we mentioned before, Java applets are built on AWT. AWT provides two levels of security. On the first level, AWT prevents applets from having free access to your computer’s file system. So, for example, it would be extremely difficult for someone to write a Java applet which did any damage to your computer’s files. The second level of security involves a byte code verifier in the Java virtual machine. The verifier checks to see if any of AWT’s security classes have been overridden or if anything in the applet will make the browser crash. If both conditions are met, it allows the non-offending applets to run in your browser. Otherwise, it rejects them. While a good concept, the verifier can be fooled; be careful.