Checking if a number fits in a primitive type
String input;
for(int times = 0; times &lt; t; times++) {
    // Ask for the number
    input = in.next();


There's no need to declare input outside of the loop. It has no advantage at all as you don't need to keep it between iterations. Always minimize the scope.



       // If the longValueExact() returns a greater number than the long max value, then it throws an ArithmeticException


As pointed in a comment, I misread longValueExact as longValue. Updated the answer, so that both are covered.

For longValue, this isn't true and the Javadoc says it pretty clearly:


  if this BigInteger is too big to fit in a long, only the low-order 64 bits are returned


For longValueExact, the following is said


  If the value of this BigInteger is out of the range of the long type, then an ArithmeticException is thrown.


So checking for exception is correct. If it gets thrown, the number doesn't fit in long and obviously in no smaller type either.



        if(number.longValueExact() &lt; Long.MAX_VALUE &amp;&amp; number.longValue() &gt; Long.MIN_VALUE) 
        {
            System.out.println("* long");
        } 


By definition, there's no long bigger than the biggest long, is it?

So this test is a tautology.



Using longValueExact makes the program correct. With longValue, it wouldn't work and instead of testing if a number fits in a type, you test if its lowest 64 bits do.

Still, letting an exception be thrown for a normal program flow is extremely inefficient as the JIT assumes that exceptions are well... exceptional. Moreover, filling their stacktrace is pretty complicated and slow, as they actually don't exists in an optimized code.

In order to get a faster code, you need to do it the other way round: Convert to BigInteger and then compare. As a bonus to speed, you get compatibility with Java 7.



You should also fix your spacing and braces. Let your IDE do it, it's free.