Hi All,
people wants to call a function when user paste in the text box, below sample code will help you to achieve the required.By using the jquery it can be too simple -
Example there is sample text box -
< input type="text" id="inpux-box"/>"
$(function(){
$('#inpux-box').bind('paste', function (e) {
setTimeout(function(){textOnKeyPress();}, 50);
});
});
function textOnKeyPress(){
//write ur logic here
}
In the above example if user paste anything in the text box then it will call the function textOnKeyPress().Here setTimeout functions says the after 50 milisecond call the textOnKeyPress(), in this function u can get the pasted value also
if user want to prevent the paste function then he/she can use below code
$(function(){
$('#inpux-box').bind('paste', function (e) {
return false;
});
});
Friday, 16 December 2011
Sunday, 17 July 2011
Program for reversing a array Without using another array
Class ReverseArray{
public static void main(String args[]){
char inputArray[]=args[0].toCharArray();
reverseArray(inputArray);
String outputString=String.copyValueOf(inputArray);
System.out.println(outputString);
}
private static void reverseArray(char[] inputArray){
for(int i=0;i<(inputArray.length)/2;i++){
char temp=inputArray[i];
inputArray[i]=inputArray[inputArray.length-1-i];
inputArray[inputArray.length-1-i]=temp;
}
}
}
Here user run :java ReverseArray shakti
output will be : itkahs
public static void main(String args[]){
char inputArray[]=args[0].toCharArray();
reverseArray(inputArray);
String outputString=String.copyValueOf(inputArray);
System.out.println(outputString);
}
private static void reverseArray(char[] inputArray){
for(int i=0;i<(inputArray.length)/2;i++){
char temp=inputArray[i];
inputArray[i]=inputArray[inputArray.length-1-i];
inputArray[inputArray.length-1-i]=temp;
}
}
}
Here user run :java ReverseArray shakti
output will be : itkahs
Monday, 4 July 2011
Class Loader in java
Classloader allows JVM to load classes. Regular Java applications running from command line involve three classloaders – Bootstrap, Extensions and System-Classpath classloaders. The three class loaders have a parent child relationship among themselves
1. Classes in the list of bootstrap classes— These are classes that embody the Java platform, such as the classes in rt.jar.
2. Classes that appear in the list of extension classes— These classes use the Extension Mechanism Framework to extend the Java platform, with archive files (.jar, .zip, etc.) located in the /lib/ext directory of the runtime environment.
3. User classes—These are classes that do not use the extension mechanism architecture identified using the -classpath command-line option or the CLASSPATH environment variable.
Classloader problems, when they occur are difficult to debug. There are only three basic principles to understand.
Classloader hierarchy illustrating the delegation.
The first principle is Delegation Principle. According to this principle, if a particular class is not loaded already, the classloaders delegate the requests to load that class to their parent classloaders. This delegation continues until the top of the hierarchy is reached and the primordial classloader loads the class. The System-ClassPath classloader loads a class called MyApp. MyApp creates a new instance of java.util.Vector. Assume that java.util.Vector has not been loaded already. Since System-Classpath classloader loaded the MyApp class, it first asks its parent, the extension classloader to load the class. The extension classloader asks the Bootstrap classloader to load java.util.Vector. Since java.util.Vector is a J2SE class, the bootstrap classloader loads it and returns. Consider a slightly different scenario. In this case, MyApp creates a new instance of MyClass, another application specific class. Assume that MyClass has not been loaded yet. As usual, when the System-Classpath classloader receives the request to load the class, it delegates it to its parent. The request finally reaches the Bootstrap classloader. It cannot find the class. Hence its child, Extensions classloader tries to load it. It cannot find it either. Finally the request comes back to the System-Classpath classloader. It finds the class and loads it. This explains the alternative path when everything is not a happy day scenario.
Classloader hierarchy illustrating the delegation when classes cannot be found
Classloader hierarchy and classes visibility.
The second principle is the Visibility principle. According to this principle, Classes loaded by parent classloaders are visible to child classloaders but not vice versa. What this means is that a class can only see other classes loaded by the ClassX’s classloader or one of its parents. The reverse is not true i.e. a class loaded by ClassX’s parent classloader cannot see ClassX. An example will make things clearer. Look at above figure. Four classloaders are shown- ClassLoaders A, B, X and Y. Class A is the topmost Classloader. ClassLoader B is its child. ClassLoaders X and Y are B’s siblings. Each of them loads classes with same names i.e. A, B, X and Y. A is the only class visible as far as other classes loaded by ClassLoader A are concerned. As far as classes loaded by ClassLoader B is concerned, A and B are the visible classes. Similarly for classes loaded by ClassLoader X, classes A, B and X are visible, but not class Y. Sibling classloaders cannot see each other’s classes.
The third principle is the class Uniqueness Principle. According to this principle, when a classloader loads a class, the child classloaders in the hierarchy will never reload the class. This follows from the delegation principle since a classloader always delegates class loading to its parents. The child classloader will load it (or try to load it) only if the parent hierarchy fails to load the class. Thus the uniqueness of the class is maintained. An interesting scenario emerges when both parent and child classloaders load the same class. You might think how is this feasible after all. Isn’t this contradicting the class uniqueness principle? To answer this question look at figure again. Let us assume that none of the classes have been loaded anywhere in the hierarchy. Let us also suppose that X, loaded by ClassLoader X, forcefully uses its classloader to load B. This can be done as shown in example below by using an API such as Class.forName(). The code shows such a scenario. Using Class.forName()
01 public class X
02{
03 public X() {
04 ClassLoader cl = this.getClass().getClassLoader();
05 Class B = Class.forName(“B”, true, cl);
06 }
07 }
In the constructor for X, the class B is loaded by explicitly using Person’s parent classloader, i.e. the parent of the classloader that loaded Person. By doing so, the delegation is overridden and B is loaded by ClassLoaderX – the classloader of X. Now suppose that another class loaded by ClassLoader B tries to access B, it cannot find it and hence follows the delegation principle. Since the delegation principle only consults the parents, ClassLoader B also eventually loads Class B. When some other code tries to compare two objects of type B – each loaded by different classloaders, it gets a ClassCastException
1. Classes in the list of bootstrap classes— These are classes that embody the Java platform, such as the classes in rt.jar.
2. Classes that appear in the list of extension classes— These classes use the Extension Mechanism Framework to extend the Java platform, with archive files (.jar, .zip, etc.) located in the /lib/ext directory of the runtime environment.
3. User classes—These are classes that do not use the extension mechanism architecture identified using the -classpath command-line option or the CLASSPATH environment variable.
Classloader problems, when they occur are difficult to debug. There are only three basic principles to understand.
Classloader hierarchy illustrating the delegation.
The first principle is Delegation Principle. According to this principle, if a particular class is not loaded already, the classloaders delegate the requests to load that class to their parent classloaders. This delegation continues until the top of the hierarchy is reached and the primordial classloader loads the class. The System-ClassPath classloader loads a class called MyApp. MyApp creates a new instance of java.util.Vector. Assume that java.util.Vector has not been loaded already. Since System-Classpath classloader loaded the MyApp class, it first asks its parent, the extension classloader to load the class. The extension classloader asks the Bootstrap classloader to load java.util.Vector. Since java.util.Vector is a J2SE class, the bootstrap classloader loads it and returns. Consider a slightly different scenario. In this case, MyApp creates a new instance of MyClass, another application specific class. Assume that MyClass has not been loaded yet. As usual, when the System-Classpath classloader receives the request to load the class, it delegates it to its parent. The request finally reaches the Bootstrap classloader. It cannot find the class. Hence its child, Extensions classloader tries to load it. It cannot find it either. Finally the request comes back to the System-Classpath classloader. It finds the class and loads it. This explains the alternative path when everything is not a happy day scenario.
Classloader hierarchy illustrating the delegation when classes cannot be found
Classloader hierarchy and classes visibility.
The second principle is the Visibility principle. According to this principle, Classes loaded by parent classloaders are visible to child classloaders but not vice versa. What this means is that a class can only see other classes loaded by the ClassX’s classloader or one of its parents. The reverse is not true i.e. a class loaded by ClassX’s parent classloader cannot see ClassX. An example will make things clearer. Look at above figure. Four classloaders are shown- ClassLoaders A, B, X and Y. Class A is the topmost Classloader. ClassLoader B is its child. ClassLoaders X and Y are B’s siblings. Each of them loads classes with same names i.e. A, B, X and Y. A is the only class visible as far as other classes loaded by ClassLoader A are concerned. As far as classes loaded by ClassLoader B is concerned, A and B are the visible classes. Similarly for classes loaded by ClassLoader X, classes A, B and X are visible, but not class Y. Sibling classloaders cannot see each other’s classes.
The third principle is the class Uniqueness Principle. According to this principle, when a classloader loads a class, the child classloaders in the hierarchy will never reload the class. This follows from the delegation principle since a classloader always delegates class loading to its parents. The child classloader will load it (or try to load it) only if the parent hierarchy fails to load the class. Thus the uniqueness of the class is maintained. An interesting scenario emerges when both parent and child classloaders load the same class. You might think how is this feasible after all. Isn’t this contradicting the class uniqueness principle? To answer this question look at figure again. Let us assume that none of the classes have been loaded anywhere in the hierarchy. Let us also suppose that X, loaded by ClassLoader X, forcefully uses its classloader to load B. This can be done as shown in example below by using an API such as Class.forName(). The code shows such a scenario. Using Class.forName()
01 public class X
02{
03 public X() {
04 ClassLoader cl = this.getClass().getClassLoader();
05 Class B = Class.forName(“B”, true, cl);
06 }
07 }
In the constructor for X, the class B is loaded by explicitly using Person’s parent classloader, i.e. the parent of the classloader that loaded Person. By doing so, the delegation is overridden and B is loaded by ClassLoaderX – the classloader of X. Now suppose that another class loaded by ClassLoader B tries to access B, it cannot find it and hence follows the delegation principle. Since the delegation principle only consults the parents, ClassLoader B also eventually loads Class B. When some other code tries to compare two objects of type B – each loaded by different classloaders, it gets a ClassCastException
Saturday, 11 June 2011
Java Static import
First lets understand what does “java import” does to your java program!
Consider the java import statements:
1) import package.ClassA;
2) import package.*;
Java statement (1) gives you a license to use ClassA inside the whole program without the package reference. That is you can use like ClassA obj = new ClassA(); or ClassA.getStatic(); Java statement (2) allows you to use all the java classes that belong the imported package in the above manner. That is without the package reference.
If you don’t use import statement, you can still use the classes of that package. But you should invoke it with package reference whereever you use.
That is like, package.ClassA obj = new package.ClassA(); – looks very ugly isn’t it?
Now coming to the static import part. Like the above ugly line we have been unknowingly using (abusing) the java static feature.
Consider the java example: double r = Math.cos(Math.PI * theta);
How about writing the same java code like: double r = cos(PI * theta); – looks more readable right?
This is where static import in java comes to help you.
import static java.lang.Math.PI;
import static java.lang.Math.cos;
Do the above static imports and then you can write it in the more readable way!
Java Static Import
The normal import declaration imports classes from packages, so that they can be used without package reference. Similarly the static import declaration imports static members from classes and allowing them to be used without class reference.
Now, we have got an excellent java feature from java 1.5. Ok now we shall see how we can abuse this!
Can i static import everything?
like, import static java.lang.Math.*; – yes it is allowed! Similarly you do for class import.
Please don’t use this feature, because over a period you may not understand which static method or static attribute belongs to which class inside the java program. The program may become unreadable.
General guidelines to use static java import:
1) Use it to declare local copies of java constants
2) When you require frequent access to static members from one or two java classes
Consider the java import statements:
1) import package.ClassA;
2) import package.*;
Java statement (1) gives you a license to use ClassA inside the whole program without the package reference. That is you can use like ClassA obj = new ClassA(); or ClassA.getStatic(); Java statement (2) allows you to use all the java classes that belong the imported package in the above manner. That is without the package reference.
If you don’t use import statement, you can still use the classes of that package. But you should invoke it with package reference whereever you use.
That is like, package.ClassA obj = new package.ClassA(); – looks very ugly isn’t it?
Now coming to the static import part. Like the above ugly line we have been unknowingly using (abusing) the java static feature.
Consider the java example: double r = Math.cos(Math.PI * theta);
How about writing the same java code like: double r = cos(PI * theta); – looks more readable right?
This is where static import in java comes to help you.
import static java.lang.Math.PI;
import static java.lang.Math.cos;
Do the above static imports and then you can write it in the more readable way!
Java Static Import
The normal import declaration imports classes from packages, so that they can be used without package reference. Similarly the static import declaration imports static members from classes and allowing them to be used without class reference.
Now, we have got an excellent java feature from java 1.5. Ok now we shall see how we can abuse this!
Can i static import everything?
like, import static java.lang.Math.*; – yes it is allowed! Similarly you do for class import.
Please don’t use this feature, because over a period you may not understand which static method or static attribute belongs to which class inside the java program. The program may become unreadable.
General guidelines to use static java import:
1) Use it to declare local copies of java constants
2) When you require frequent access to static members from one or two java classes
Saturday, 28 May 2011
Difference between TreeSet And HashSet
TreeSet internally uses the compare to check dulicate and HashSet internally use the hashCode() and equals().
The below Example shows the difference--
import java.util.HashSet;
import java.util.TreeSet;
public class Test {
public static void main(String[] args) {
HashSet hashSet=new HashSet();
TreeSet treeSet=new TreeSet();
A a1=new A();
a1.setI(1);
A a2=new A();
a2.setI(1);
hashSet.add(a1);
hashSet.add(a2);
treeSet.add(a1);
treeSet.add(a2);
System.out.println("Size of HashSet is "+ hashSet.size());
System.out.println("Size of TreeSet is "+ treeSet.size());
}
}
class A implements Comparable{
private int i;
public int getI() {
return i;
}
public void setI(int i) {
this.i = i;
}
@Override
public boolean equals(Object o) {
if(o instanceof A){
A a=(A)o;
return a.i==this.i;
}else
return false;
}
@Override
public int hashCode() {
return i;
}
public int compareTo(A o) {
return 1;
}
}
OutPut will be:
Size of HashSet is 1
Size of TreeSet is 2
The below Example shows the difference--
import java.util.HashSet;
import java.util.TreeSet;
public class Test {
public static void main(String[] args) {
HashSet hashSet=new HashSet();
TreeSet treeSet=new TreeSet();
A a1=new A();
a1.setI(1);
A a2=new A();
a2.setI(1);
hashSet.add(a1);
hashSet.add(a2);
treeSet.add(a1);
treeSet.add(a2);
System.out.println("Size of HashSet is "+ hashSet.size());
System.out.println("Size of TreeSet is "+ treeSet.size());
}
}
class A implements Comparable{
private int i;
public int getI() {
return i;
}
public void setI(int i) {
this.i = i;
}
@Override
public boolean equals(Object o) {
if(o instanceof A){
A a=(A)o;
return a.i==this.i;
}else
return false;
}
@Override
public int hashCode() {
return i;
}
public int compareTo(A o) {
return 1;
}
}
OutPut will be:
Size of HashSet is 1
Size of TreeSet is 2
Sunday, 23 January 2011
Send mail with attachment in java using java Mail Api
import java.util.Properties;
import javax.mail.*;
import javax.mail.internet.*;
import javax.activation.*;
public class MailSend
{
public static void SendMail(String to)throws MessagingException
{
Multipart mailBody = null;
MimeBodyPart mainBody;
MimeBodyPart mimeAttach;
String myFile="="insert attachment file path";// example: "c://myfile.txt";
DataSource fds;
String subject="Thanks";
boolean bodyIsHTML=false;
String body="thanks for registration";
String from="abc@gmail.com";
Properties props=new Properties();
props.put("mail.transport.protocol","smtp");
System.setProperty("mail.smtps.auth", "true");
props.put("mail.smtp.host","smtp.gmail.com");//localhost
props.put("mail.smtp.port",25);
props.put("mail.smtp.auth","true");
props.put("mail.smtp.starttls.enable","true");
Session session=Session.getDefaultInstance(props);
session.setDebug(true);
//create message
Message message=new MimeMessage(session);
mailBody=new MimeMultipart();
message.setSubject(subject);
if(bodyIsHTML)
message.setContent(body,"text/html");
else
message.setText(body);
mainBody=new MimeBodyPart();
mainBody.setDataHandler(new DataHandler(body, "text/plain"));
mailBody.addBodyPart(mainBody);
//Adding a single attachment
fds=new FileDataSource(myFile);
mimeAttach=new MimeBodyPart();
mimeAttach.setDataHandler(new DataHandler(fds));
mimeAttach.setFileName(fds.getName());
mailBody.addBodyPart(mimeAttach);
message.setContent(mailBody);
//Addressthe Messsage
Address frmAdd=new InternetAddress(from);
Address toAdd=new InternetAddress(to);
Address ccAdd[]={new InternetAddress("xyz@xyz.com"),new InternetAddress("xyz@xyz.com"),new InternetAddress("xyz@xyz.com")};
message.setFrom(frmAdd);
// In case of Bcc use BCC
message.setRecipient(Message.RecipientType.TO,toAdd);
message.addRecipients(Message.RecipientType.CC, ccAdd);
//Send Message
Transport transport = session.getTransport();
//Transport transport=session.gettransPort();
transport.connect("smtp.gmail.com", 25,"xyz@xy.com","password");
transport.sendMessage(message,message.getAllRecipients());
}
public static void main(String a[])
{String s="abc@gmail.com";
try{
SendMail(s);
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
Here i m adding the sample code which is working for meMailSend.java
Want To earn click on Earn upto Rs. 9,000 pm checking Emails. Join now!Paisa
Sending Mail Using Java Mail API
import java.util.Properties;
import javax.mail.*;
import javax.mail.internet.*;
import javax.activation.*;
public class MailSend
{
public static void SendMail(String to)throws MessagingException
{
String subject="Thanks";
boolean bodyIsHTML=false;
String body="thanks for registration";
String from="SendermailId";//abc@gmail.com
Properties props=new Properties();
props.put("mail.transport.protocol","smtp");
System.setProperty("mail.smtps.auth", "true");
props.put("mail.smtp.host","smtp.gmail.com");
props.put("mail.smtp.port",25);
props.put("mail.smtp.auth","true");
props.put("mail.smtp.starttls.enable","true");
Session session=Session.getDefaultInstance(props);
session.setDebug(true);
//create message
Message message=new MimeMessage(session);
message.setSubject(subject);
if(bodyIsHTML)
message.setContent(body,"text/html");
else
message.setText(body);
//Address the Messsage
Address frmAdd=new InternetAddress(from);
Address toAdd=new InternetAddress(to);
// if u send to some user to cc then use below code
//here xyz is the address of recivers
Address ccAdd[]={new InternetAddress("xyz@m.com"),new InternetAddress("xyz@m.com"),new InternetAddress("xyz@m.com")};
message.setFrom(frmAdd);
// In case of Bcc use BCC
message.setRecipient(Message.RecipientType.TO,toAdd);
// In case of cc use CC
message.addRecipients(Message.RecipientType.CC, ccAdd);
//Send Message
Transport transport = session.getTransport();
transport.connect("smtp.gmail.com", 25,"abc@gmail.com","password");
transport.sendMessage(message,message.getAllRecipients());
}
public static void main(String a[])
{String s="reciever email address";
try{
SendMail(s);
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
Subscribe to:
Posts (Atom)