same package different folders

you can have test classes and the source code classes in same package but in different folders. Thats cool, look at the example

C:\myApps/mycode/mainsource/com/tamaash/tds/dblayer/someclass.java
package name - com.tamaash.tds.dblayer for someclass.java

C:\myApps/mycode/test/com/tamaash/tds/dblayer/testsomeclass.java
package name - com.tamaash.tds.dblayer for testsomeclass.java

There will be two entries in the classpath.
C:\myApps/mycode/mainsource [and] C:\myApps/mycode/test

Throwing Exception in Java

Just a note of caution while throwing Exceptions, You can;t throw them from a catch Block.
A good article on Exception is here - http://www.artima.com/designtechniques/exceptionsP.html

Java Annotations - Starting Java 5.0

Other APIs require “side files” to be maintained in parallel with programs. For example JavaBeans requires a BeanInfo class to be maintained in parallel with a bean, and Enterprise JavaBeans (EJB) requires a deployment descriptor. It would be more convenient and less error-prone if the information in these side files were maintained as annotations in the program itself.

The Anwer --- Java Annotations...

The Java platform has always had various ad hoc annotation mechanisms. For example the transient modifier is an ad hoc annotation indicating that a field should be ignored by the serialization subsystem, and the @deprecated javadoc tag is an ad hoc annotation indicating that the method should no longer be used. As of release 5.0, the platform has a general purpose annotation (also known as metadata) facility that permits you to define and use your own annotation types. The facility consists of a syntax for declaring annotation types, a syntax for annotating declarations, APIs for reading annotations, a class file representation for annotations, and an annotation processing tool.

?: Shorthand for if-then statement

Example

Object = (Service != null)
? serviceobj.setValue(10)
: serviceobj = new ServiceClass();

Enum in Java 5.0

In 5.0, the Java™ programming language gets linguistic support for enumerated types. In their simplest form, these enums look just like their C, C++, and C# counterparts:

enum Season { WINTER, SPRING, SUMMER, FALL }

But appearances can be deceiving. Java programming language enums are far more powerful than their counterparts in other languages, which are little more than glorified integers. The new enum declaration defines a full-fledged class (dubbed an enum type). In addition to solving all the problems mentioned above, it allows you to add arbitrary methods and fields to an enum type, to implement arbitrary interfaces, and more. Enum types provide high-quality implementations of all the Object methods. They are Comparable and Serializable, and the serial form is designed to withstand arbitrary changes in the enum type.

POJO

POJO: Plain Old Java Object
Usually used in the context of frameworks, such as EJB, where there is too much bloat.

Class Def not found problem

there are 4 reasons you might want to check,

1. u might have to specify pacakagepath.class name while running the class using java command

2. check if the running version of JVM in ur machine, if you have compiled in Java1.4 and running on Java 1.5 you might face this problem.

3. This occurs because the classpath is not setup or referenced correctly.

Executing your program using this command should correct the problem:
java -classpath . helloworld

4. Most importantly please check your Classpath in the System-Env Variables in Windows, the CLASSPATH veriable should look like this %CLASSPATH%.;C:\Your\Path;. If it is not like that, then you will have only on path in your classpath, and hence you are having tought time figuring out why it is not working for your class. but if you try with java -classpath /your/path option it works, this is bcoz when you specify tht it over rules all other paths, but thts the only path there.

Activating Apache for CGI

ScriptAlias
The ScriptAlias directive tells Apache that a particular directory is set aside for CGI programs. Apache will assume that every file in this directory is a CGI program and will attempt to execute it, when that particular resource is requested by a client.

The ScriptAlias direcive looks like:

ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/
The example shown is from your default httpd.conf configuration file, if you installed Apache in the default location. LOOK IN MY WEB for details apache

ANT Out Of Memory

set ANT_OPTS=-Xmx512M [or] export ANT_OPTS=-Xmx512M

JUNIT Elements Discovered

"<"target name="target-name" depends"mothertarget" if="someproperty"">"

When i run ant target-name ... following things will happen
1. The target's dependent taget is run first
2. Then there will be a check to see if "someproperty" is set, it dose not matter whether it is set to true or false or some junk value. And it can be set as a "proeprty element in the same build.xml or it can be set in build.properties file too.
3. if "someproperty" is set to some value, then the target "target-name" is run other wise only the target on which it depends would have ru, but the current target will be skipped

"<"antcall">"

This Element can be used to call any target with in the same build.xml file.
My Tip : This is very useful in cases where you want conditional invoking of a target.
here is an example: You want to build and test only if a property is set, other wise you want to just test. You can achieve this by doing the following.

BEFORE conditional build and test is implemented

"<"target name="testall" depends="build-all">"
....
"<"/target">"

AFTER conditional build and test is implemented

"<"target name="condition_check" if="build_and_test_is_set">"
"<"antcall target="build-all">" "<"/antcall">"
"<"/target">"

"<"target name="testall" depends="condition_check">"
....
"<"/target">"

java Object not found Error in Eclipse

While building in Eclipse if you encounter Java Object not found error, then check in the Project Properties to see if you have selected the Jre/Jdk, and select it and save the project properties, this error is due to that.

java -Xbootclasspath

http://java.sun.com/developer/onlineTraining/Programming/JDCBook/collect.html
Jan 11, 2006
Tutorials & Code Camps
Chapter 7 Continued: Collecting Evidence



Training Index
[<] [CONTENTS] [NEXT>>]
The first step in trying to solve any problem is to gather as much evidence and information as possible. If you can picture a crime scene, you know that everything is checked, cataloged and analyzed before any conclusions are reached. When debugging a program, you do not have weapons, hair samples, or fingerprints, but there is plenty of evidence you can gather that might contain or ultimately lead to the solution. This section explains how to gather that evidence.
Installation and Environment
Class Path
Class Loading
Including Debug Code
Installation and Environment
The Java platform is a fast-moving and changing technology. You might have more than one release installed on your system, and those releases might have been installed as part of another products installation. In an environment with mixed releases, a program can experience problems due to changes to the platform in a new version or release.
For example, if classes, libraries, or Windows registry entries from previous installations remain on your system after an upgrade, there is a chance the new software mix is causing your problems and needs to be investigated and ruled out. Opportunities for problems related to mixed software releases have increased with the use of different release tools to deliver the Java platform software.
The section on Version Issues at the end of this chapter provides a complete list of major Java platform release and version information to help you rule out software release issues. This next section highlights the most common problems you are likely to encounter. Class Path
In the Java 2 platform, the CLASSPATH environment variable is needed to specify the application's own classes only, and not the Java platform classes as was required in earlier releases. So it is possible your CLASSPATH environment variable is pointing at Java platform classes from earlier releases and causing problems.
To examine the CLASSPATH, type the following at the command line:
Windows 95/98/NT:echo %CLASSPATH%
Unix Systems:echo $CLASSPATH
Java classes are loaded on a first come, first served basis from the CLASSPATH list. If the CLASSPATH variable contains a reference to a lib/classes.zip file, which in turn points to a different Java platform installation, this can cause incompatible classes to be loaded.
Note: In the Java 2 platform, the system classes are chosen before any class on the CLASSPATH list to minimize the possibility of any old broken Java classes being loaded instead of a Java 2 class of the same name.
The CLASSPATH variable can get its settings from the command line or from configuration settings such as those specified in the User Environment on Windows NT, an autoexec.bat file, or a shell startup file like .cshrc on Unix.
You can control the classes the Java1 Virtual Machine (VM) uses by compiling your program with a special command-line option that lets you supply the CLASSPATH you want. The Java 2 platform option and parameter is -Xbootclasspath classpath, and earlier releases use -classpath classpath and -sysclasspath classpath. Regardless of which release you are running, the classpath parameter specifies the system and user classpath, and zip or Java ARchive (JAR) files to be used in the compilation.
To compile and run the Myapp.java program with a system CLASSPATH supplied on the command line, use the following instructions:
Windows 95/98/NT:
In this example, the Java platform is installed in the C:\java directory. Type everything on one line: javac -J-Xbootclasspath:c\java\lib\tools.jar;c:
\java\jre\lib\rt.jar;c:\java\jre\lib\i18n.jar;.
Myapp.java
You do not need the -J runtime flag to run the compiled Myapp program, just type the following on one line: java -Xbootclasspath:c:\java\jre\lib\rt.jar;c:
\java\jre\lib\i18n.jar;. Myapp
Unix Systems:
In this example, the Java platform is installed in the /usr/local/java directory. Type everything on one line: javac -J-Xbootclasspath:/usr/local/java/lib/tools.jar:
/usr/local/java/jre/lib/rt.jar:
/usr/local/java/jre/lib/i18n.jar:. Myapp.java
You do not need the -J runtime flag to run the compiled Myapp program, just type the following on one line: java -Xbootclasspath:/usr/local/java/jre/lib/rt.jar:
/usr/local/java/jre/lib/i18n.jar:. Myapp
Class Loading
Another way to analyze CLASSPATH problems is to locate where your application is loading its classes. The -verbose option to the java command shows which .zip or .jar file a class comes from when it is loaded. This way, you will be able to tell if it came from the Java platform zip file or from some other application's JAR file.
For example, an application might be using the Password class you wrote for it or it might be loading a Password class from an installed integrated development environment (IDE) tool.
You should see each jar and zip file named as in the example below:
$ java -verbose SalesReport
[Opened /usr/local/java/jdk1.2/solaris/jre/lib/rt.jar
in 498 ms]
[Opened /usr/local/java/jdk1.2/solaris/jre/lib/i18n.jar
in 60 ms]
[Loaded java.lang.NoClassDefFoundError from
/usr/local/java/jdk1.2/solaris/jre/lib/rt.jar]
[Loaded java.lang.Class from
/usr/local/java/jdk1.2/solaris/jre/lib/rt.jar]
[Loaded java.lang.Object from
/usr/local/java/jdk1.2/solaris/jre/lib/rt.jar]
Including Debug Code
A common way to add diagnostic code to an application is to use System.out.println statements at strategic locations in the application. This technique is fine during development, providing you remember to remove them all when you release your product. However, there are other approaches that are just as simple, do not affect the performance of your application, and do not display messages that you do not want your customers to see. The following are two techniques that overcome the problems with simple System.out.println statements.
Turning Debug Information On at Runtime
The first alternative to the classic println debug statements is to turn on debugging information at runtime. One advantage to this is you do not need to recompile any code if problems appear at the testing stage or on a customer site.
Another advantage is that sometimes software problems can be attributed to race conditions where the same segment of code behaves unpredictably due to timing between other program interactions. If you control your debug code from the command line instead of adding println debug statements, you can rule out sequence problems caused by race conditions coming from the println code. This technique also saves you adding and removing println debug statements and having to recompile your code.
This technique requires you to use a system property as a debug flag and include application code to test that system property value. To turn on debug information from the command line at run time, start the application and set the debug system property to true as follows:
java -Ddebug=true TestRuntime
The source code for the TestRuntime class needs to examine this property and set the debug boolean flag as follows:
public class TestRuntime {
boolean debugmode; //global flag that we test
public TestRuntime () {
String dprop=System.getProperty("debug");
if ((dprop !=null) && (dprop.equals("yes"))){
debugmode=true;
}
if (debugmode) {
System.err.println("debug mode!");
}
}
}
Creating Debug and Production Releases at Compile Time
As mentioned earlier, one problem with adding System.out.println debug statements to your code is finding and removing them before you release the product. Apart from adding unnecessary code, println debug statements can contain information you do not want your customers to see.
One way to remove System.out.println debug statements from your code is to use the following compiler optimization to remove pre-determined branches from your code at compile time and achive something similar to a debug pre-processor.
This example uses a static dmode boolean flag that when set to false results in the debug code and the debug test statement being removed. When the dmode value is set to true, the code is included in the compiled class file and is available to the application for debugging purposes.
class Debug {
//set dmode to false to compile out debug code
public static final boolean dmode=true;
}
public class TestCompiletime {
if (Debug.dmode) { // These
System.err.println("Debug message"); // are
} // removed
}
Using Diagnostic Methods
You can use diagnostic methods to request debug information from the Java VM. The following two methods from the Runtime class trace the method calls and Java VM byte codes your application uses. As both these methods produce a lot of output, it is best to trace very small amounts of code, even as little as one line at a time.
To enable trace calls so you will see the output, you have to start the Java VM with the java_g or java -Xdebug interpreter commands.
To list every method as it is invoked at runtime, add the following line before the code you wish to start tracing and add a matching traceMethodCalls line with the argument set to false to turn the tracing off. The tracing information is displayed on the standard output. // set boolean argument to false to disable
Runtime.getRuntime().traceMethodCalls(true);
callMyCode();
Runtime.getRuntime().traceMethodCalls(false);
To see each line as bytecodes as they are executed, add the following line to your application code: // set boolean argument to false to disable
Runtime.getRuntime().traceInstructions(true);
callMyCode();
Runtime.getRuntime().traceInstructions(false);
You can also add the following line to your application to dump your own stack trace using the dumpStack method from the Thread class. The output from a stack trace is explained in Analyzing Stack Traces, but for now you can think of a stack trace as a snapshot of the current threads running in the Java VM. Thread.currentThread().dumpStack();
Adding Debug Information
Local variable information is not included in the core Java platform system classes. So, if you use a debug tool to list local variables for system classes where you place stop commands, you will get the following output, even when you compile with the -g flag as suggested by the output. This output is from a jdb session: main[1] locals
No local variables: try compiling with -g
To get access to the local variable information, you have to obtain the source (src.zip or src.jar) and recompile it with a debug flag. You can get the source for most java.* classes with the binary downloads from java.sun.com.
Once you download the src.zip or src.jar file, extract only the files you need. For example, to extract the String class, type the following at the command line: unzip /tmp/src.zip src/java/lang/String.java
or
jar -xf /tmp/src.jar src/java/lang/String.java
Recompile the extracted class or classes with the -g option. You could also add your own additional diagnostics to the source file at this point. javac -g src/java/lang/String.java
The Java 2 javac compiler gives you more options than just the original -g option for debug code, and you can reduce the size of your classes by using -g:none, which gives you on average about a 10 percent reduction in size.
To run the application with the newly compiled debug class or classes, you need to use the bootclasspath option so these new classes are picked up first.
Type the following on one line with a space before myapp.
Win95/NT Java 2 Platform:
This example assumes the Java platform is installed in c:\java, and the source files are in c:\java\src: jdb -Xbootclasspath:c:\java\src;c:\java\jre\lib\rt.jar;c:
\java\jre\i18n.jar;. myapp
Unix Systems:
This example assumes the Java platform is installed in c:\java, and the source files are in c:\java\src. jdb -Xbootclasspath:/usr/java/src;
/usr/java/jre/lib/rt.jar;
/usr/java/jre/i18n.jar;. myapp
The next time you run the locals command you will see the internal fields of the class you wish to analyze.
[TOP]
_______1 As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.
copyright © Sun Microsystems, Inc