Java - Table of Contents

long    plainLong = 100;
Long    javaLong = new Long(plainLong);

String s = "100";

try {
   long l = Long.parseLong(s.trim());
   System.out.println("long l = " + l);
} catch (NumberFormatException nfe) {
   System.out.println("NumberFormatException: " + nfe.getMessage());
}

Long.toString(long l) is used to convert in the other direction, from long to String

SimpleDateFormat formatter = new SimpleDateFormat("'_'MMM'-'dd'-'yyyy'_'HH:mm:ss");
currentDate = formatter.format(new Date());

Long         contractId = 0;
Collection   contractIdCollection = null;

try {
   int maxContract = contractIdCollection.size();
   Iterator iterator = contractIdCollection.iterator();
	
   for (int i = 0; i < maxContract; i++) {

      contractDa = (ContractDa)iterator.next();

      contractId = contractDa.getId();
   }
} catch (Exception exception) {
   System.out.println(exception.toString());
}

Original article : http://www.fawcette.com/javapro/2002_09/online/errors_jstreet_09_13_02/page2.asp

Note that several exceptions are unchecked, and as such, behave like errors: NullPointerException, ClassCastException, and IndexOutOfBoundsException are all subclasses of RuntimeException. RuntimeException and all of its children are always unchecked.

So what should you do about all these nasty unchecked exceptions? You could catch the exceptions in the method where they might occur, but this is a haphazard solution. Doing so solves one problem, but it leaves the rest of the code open to disruption by other unchecked exceptions. There's a better way, thanks to a nifty little method provided by the ThreadGroup class:

public class ApplicationLoader extends ThreadGroup { private ApplicationLoader() { super("ApplicationLoader"); } public static void main(String[] args) { Runnable appStarter = new Runnable() { public void run() { //invoke your application (i.e. MySystem.main(args)} } new Thread(new ApplicationLoader(), appStarter).start(); } //We overload this method from our parent //ThreadGroup , which will make sure that it //gets called when it needs to be. This is //where the magic occurs. public void uncaughtException(Thread thread, Throwable exception) { //Handle the error/exception.
//Typical operations might be displaying a
//useful dialog, writing to an event log, etc.
}

This technique rocks. Think of all those times you perform an operation in your GUI, and an unchecked exception happens. Often, you leave the GUI in an unusual state (dialogs still open, buttons disabled, cursors in the wrong state), but with this technique, you could return the GUI to its natural state, inform the user of an error, and feel good about yourself because you wrote a high-quality application.

But this technique isn't just for GUIs. Server applications prone to excessive resource usage can use this technique to free resources at a global level, often preventing the VM from entering an unstable state. Catching errors early and often, and dealing with them smartly, can make the difference between a great programmer and an average one. And by virtue of your having read this far, we know which one you want to be.

long startTime = System.currentTimeMillis(); 
... 
long endTime = System.currentTimeMillis(); 
double theTime = (double) ((endTime - startTime)/1000);
System.out.println("Time -----> : " + theTime);

Be sure to give the absolute path name starting from where the Java^TM Virtual Machine¹ (JVM) is running.

Message msg = new MimeMessage(session); 
   msg.setFrom( aDefaultFromAddress ); 
   InternetAddress[] address = {aToAddress}; 
   msg.setRecipients(
        Message.RecipientType.TO, address); 
   msg.setSubject( pSubject ); 
   msg.setSentDate(new java.util.Date()); 
   // create and fill the first message part 
   MimeBodyPart mbp1 = new MimeBodyPart(); 
   mbp1.setText(pMessage); 
   // create the second message part 
   MimeBodyPart mbp2 = new MimeBodyPart(); 
   // attach the file to the message 
   FileDataSource fds=
            new FileDataSource(pFileName); 
   mbp2.setDataHandler(
              new DataHandler(fds)); 
   mbp2.setFileName(pFileName); 
   // create the Multipart 
   //and its parts to it 
   Multipart mp = new MimeMultipart(); 
   mp.addBodyPart(mbp1); 
   mp.addBodyPart(mbp2); 
   // add the Multipart to the message 
   msg.setContent(mp); 
   Transport.send(msg); 
 

Servlet:

import java.util.HashMap;
import java.io.*;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


public class HelloServlet extends HttpServlet {
   
    public void service(HttpServletRequest request, 
          HttpServletResponse response)  
            throws ServletException, IOException {

	// getting the parameters
        String name = request.getParameter("name");
        String age = request.getParameter("age");

	//putting them in a hashmap
        HashMap hm = new HashMap();
        hm.put("name", name);
        hm.put("age", age);

	//returning them
        try {
            ObjectOutputStream p = new 							
	       ObjectOutputStream(response.getOutputStream());
            p.writeObject(hm);
            p.flush();
            p.close();
        }catch (Exception e) {
            e.printStackTrace();
        }
    }
}

This is the class that calls the servlet:

import java.net.*;
import java.util.*;
import java.io.*;

public class Hello {
    public static void main(String args[]) {

        ObjectInputStream is;
        URL url;
        String  uri = 
          "http://Server name:port/HelloServlet";
        HashMap hash = new HashMap();    
        try {
            //calling the servlet by passing params
            url =  new URL(uri +"?&name=MyName&age=25");
            
            // open input stream and read the hashmap
            // returned by the servlet
            
            is = new ObjectInputStream(url.openStream());
            hash = (HashMap) is.readObject();
            
            // print it out
            System.out.println(hash);
        } catch (Exception e) {
            e.printStackTrace(System.err);
        }
    }
}

Question:  

If object A calls a method in object B, is there a way for object B to find the class name of object A, without passing a string or this to the method?

Answer 1:

String callingClassName = sun.reflect.Reflection.getCallerClass(2).getName();

Answer 2:

JDK 1.4+ you could just say "new Thread().getStackTrace()[1].getClassName()", with a warning to check that getStackTrace actually returns an array with some elements, or you could end up throwing ArrayOutOfBoundsException unexpectedly

Answer 3:

You can get the name of the class by processing the call stack printed to a stream by the printStackTrace() method:

import java.io.*; public class A { public static void main( String args[] ) { B.methodB(); } } class B { public static void methodB() { StringWriter sw = new StringWriter(); new Throwable().printStackTrace( new PrintWriter( sw ) ); String callStack = sw.toString(); int atPos = callStack.indexOf( "at" ); atPos = callStack.indexOf( "at" , atPos ); int dotPos = callStack.indexOf( "." , atPos ); System.out.println( "name of the class that called this method - " + callStack.substring( atPos + 2 , dotPos ) ); } }

DateFormat df=DateFormat.getInstance(); 
Date myDate=df.parse(d); 

Where d...date in the string is in (UTC) format.

I'm getting the following errors:

UnparsedDateException 

Answer:

The trick is to use the java.text.SimpleDateFormat class. One of the constructors takes a "format control" string as a parameter. This string determines the textual output format when the SimpleDateFormat object is used to format a Date object. This string also defines the expected format for a text string as far as parsing is concerned.

The short code snippet below expects a date in the "yyyy-mm-dd" format and will reformat it to the "mm/dd/yyyy" format.

import java.text.SimpleDateFormat; 
import java.util.Date; 

public class DateFormatTest 
{ 
  public static void main( String[] cmdArgs ) 
                            throws Exception 
  { 
    SimpleDateFormat sdfInput = 
       new SimpleDateFormat( "yyyy-MM-dd" ); 
    SimpleDateFormat sdfOutput = 
       new SimpleDateFormat ( "MM/dd/yyyy" ); 
    String textDate = "2001-01-04"; 

    Date date = sdfInput.parse( textDate ); 
    System.out.println( sdfOutput.format( date ) ); 
  } // main 
} // class DateFormatTest 

If you prefer, you can replace the last two lines of code with

System.out.println( sdfOutput.format(
            sdfInput.parse(textDate))); 

public class Singleton {
    private static final Singleton INSTANCE = 
                              new Singleton();

   // Private constructor supresses 
   // default public constructor
    private Singleton( ) {
    }

    public static Singleton getInstance( ) {
        return INSTANCE;
    }
 }

If you want to make it serializable, then change the declaration to:

public class Singleton implements Serializable

and add this method:

    private Object readResolve() 
             throws ObjectStreamException {
        return INSTANCE;
    }

The readResolve method serves to prevent the release of multiple instances upon deserialization.

The following is one example of the use of the tokenizer. The code:

     StringTokenizer st = new StringTokenizer("this is a test");
     while (st.hasMoreTokens()) {
         println(st.nextToken());
     }

prints the following output:

     this
     is
     a
     test 

See Also:

StreamTokenizer

By Frank Jennings

Original Article : http://www.sys-con.com/java/articlenews.cfm?id=1824

The other day I was trying to terminate this unprecedented application server from my console window by using CTRL-C. The application did get the idea that I didn't want to see any more of it, but I guess it was trying to save the settings, flush streams, close database connection, update log files, write preferences, check data files - all when I was waiting patiently. It was in a dangled state and didn't respond even when I killed the PID. I never felt paranoid with JVM Shutdown hooks until that moment. Do not use Runtime.runFinalizersOnExit, for performing a cleanup operation during improper JVM shutdown, because this will result in finalizing of objects, which is being manipulated by different concurrent threads. This is unsafe and will lead to deadlock.

Here is the proper implementation of shutdown hook. We create a shutdown hook, which performs the last minute panic operation, and monitor the cleanup period using a hook timer. Whether our application performs cleanup or not, the hook timer forcibly shuts down the application by invoking Runtime.halt. This is because when the JVM is about to be shut down all the hooks are started randomly without any order.

public class Jcs9{

public static class panicHook extends Thread{

   panicHook(){
   /** Note the empty constructor
   * Do not start this thread with this.start()
   * as the hook is already started
   */
}

public void run(){

   /** Add your clean-up operation here **/
   System.out.println("Shutdown Hook started......");
   while(true){}

}
}


public static class hookTimer extends Thread{
   hookTimer(){
   /** Do not start this thread with this.start()
   * as the hook is already started
   */
}

public void run(){

/** Monitor the Hook Period **/
try{
   this.sleep(3000);
} catch (Exception e){}

   System.out.println("Hook Period exceeded....Forcing Shutdown!!");

   /** Do not use Runtime.removeShutdownHook(Thread) here! as the
   * shutdown process is already started.
   **/

   /** Forcing all hooks to exit **/
   Runtime.getRuntime().halt(0);
   /** System.exit(0) has no effect while the
   * hooks are active! so dont even try.
   */
   }
}

public static void main(String ar[]) {

   Runtime rtime=Runtime.getRuntime();

   /** Register the hook with the JVM **/
   Thread phook=new panicHook();
   rtime.addShutdownHook(phook);

   /** Register the Timer with the JVM **/
   Thread thook=new hookTimer();
   rtime.addShutdownHook(thook);

   System.out.println("Try interrupting me dude.....");
   while(true){}
}

}

Improper implementation of shutdown-hook turns me off and I, in turn, turn off the JVM's interaction with the OS signals with the java -Xrs switch. So the application can't perform its cleanup during improper shutdown. Some revenge!