Finding "lucky numbers" This code is for a problem in which I'm to find the total number of numbers that exist between A and B, of which sum of digits and sum of square of digits are prime.

How can I make this optimal?

import java.util.Scanner;
public class LuckyNumbers {
    static int T,ans[];
    static long A,B;
    public static void main(String ar[]){
        Scanner scan=new Scanner(System.in);
        T=scan.nextInt();
        ans=new int[T];
        for(int i=0;i&lt;T;i++){
            A=scan.nextLong();
            B=scan.nextLong();
            for(long j=A;j&lt;=B;j++){
                if(getLucky(j)){
                    ans[i]++;
                }
            }
        }
        for(int i=0;i&lt;T;i++){
            System.out.println(ans[i]);
        }
    }
    public static boolean getLucky(long j){
        boolean lucky=false;
        long rem,sum=0,sum1=0;
        while(j&gt;0){
            rem=j%10;
            sum=sum+rem;
            sum1=sum1+(rem*rem);
            j=j/10;
        }
        if(isPrime(sum)&amp;&amp;isPrime(sum1)){
            lucky=true;
        }
        return lucky;
    }
    public static boolean isPrime(long sum){
        boolean status=true;
        if(sum!=1){
            for (int i=2; i &lt; sum ;i++ ){
              long n =sum % i;
              if (n==0){
                    status=false;
                    break;
              }
            }
        }else{
            status=false;
        }
        return status;
    }
}
Some thoughts on speed:


Start caching results in isPrime.
Print things as soon as you calculate them, no need to store them back into an array. (This makes debugging easier, too.)

As Leonid pointed out, storing things may be a good idea.  I would keep it an array in that case, not a linked list, as that costs less time.
However, I would simply disable output when profiling, and keep my suggestion for debugging.
On a similar note, consider splitting both the main algorithm and the output into separate functions so that you can easily disable both.  That makes it much easier to check how much each stage of the algorithm (parsing, processing, printing) is taking.

You could try caching rem*rem, as you know there's only ten possibilities.  May be faster, may be slower.
You should take a look at the input you'll be dealing with and figure out what values your program needs to have that could be given beforehand.  What values can the numbers you're checking for primality be?  (I would guess you need up to around 2000, but I'm not sure.)


Some general thoughts:


Add some comments.  What is a lucky number?
Add some blank lines.
Rename getLucky to isLucky or checkIsLucky.  I'd go for the first, but some people will tell you that functions need a verb other than "is".  If Java supports it, you could make it an extension method and then do arr[i].isLucky().
Don't make variables static unless they have to be.  Both T and ans can be local to main.
Make your variable names more meaningful.  In particular, replacing T with numberOfInputPairs (or numInputPairs, at least) would improve matters.
Don't use the same name for two variables, with one letter difference.  Why do you have sum and sum1?  What's the difference between them?
Use the += operator when possible.  sum1 += rem*rem is easier to read than what you have.


To address the question of numberOfInputPairs being too long: let's reformat the code a little and change the name appropriately:

public static void main(String ar[]){
    Scanner scan = new Scanner(System.in);
    int numberOfInputPairs = scan.nextInt();
    int ans[] = new int[numberOfInputPairs];

    for (int i = 0; i &lt; numberOfInputPairs; i++){
        A = scan.nextLong();
        B = scan.nextLong();
        for (long j = A; j &lt;= B; j++) {
            if (getLucky(j)) {
                ans[i]++;
            }
        }
    }

    for (int i = 0; i &lt; numberOfInputPairs; i++) {
        System.out.println(ans[i]);
    }
}


Yes, if no whitespace is added, the longer variable names make a wall of text a bigger wall of text, and convey very little meaning.  However, with just a slight increase in the amount of whitespace, I find that the longer variable name is no less clear and makes it clear what is being done.

(By the way, I think this is partially a language problem: as things are, it is used three times, while a proper for-each loop would mean it would only need to be used once.)

I do not agree with n or T offering that clarity; numPairs would do, too, and is down to personal preference.