Hello Jacob,
I have seen this question quite a number of times, which prompted me to add
it to my FAQ.
http://jqa.tmorris.net/GetQAndA.action?qids=80&showAnswers=true

I have also included a code sample below that demonstrates what you want to
achieve.
As a note, if you have a policy of not being permitted to have compile-time
warnings, it may be in your interest to learn about generics.

Also note that there are some valid use cases that force a compile-time
warning, due to the contrived nature of the Java generics implementation, so
you may seek to have this policy reviewed. These forced use cases are the
result of the introduction of failure to maintain a conversion between
arrays and parameterised types (without a warning) - as an example, take a
look at the java.util.ArrayList implementation, which is backed by an
array - you will note that there is a forced compile-time warning. You
discover these nitty details when you implement the spec. after a JSR
"expert" group has been onto the case :) I did make this issue known well
before the spec. was released, but the most plausible response I got was
"oops".

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import static java.lang.Class.forName;

class X
{
   X(final String s)
   {

   }
}

final class Main
{
   private Main() throws UnsupportedOperationException
   {
       throw new UnsupportedOperationException();
   }

   public static void main(final String... args) throws
       ClassNotFoundException,
       NoSuchMethodException,
       InstantiationException,
       IllegalAccessException,
       InvocationTargetException
   {
       final Class<?> c = forName("X");
       final Class<? extends X> xc = c.asSubclass(X.class);
       final Constructor<? extends X> ctor =
xc.getConstructor(String.class);
       final X x = ctor.newInstance(args[0]);
   }
}

--
Tony Morris
http://tmorris.net/

Java Questions and Answers
http://jqa.tmorris.net/

Ha ha!  Then you loose!

I'm not sure about the particular example you mention -- I don't know a
(working) way to avoid the warning myself, but that doesn't mean there isn't
one[*].

But the real problem here is not javac, but the way your organisation works.
Find the person responsible for this absurd rule and fire him/her (and,
perhaps, also his/her manager).  Or if the condition was imposed by a customer,
find the salesthing which accepted that clause in the contract and fire it.

   -- chris

[*] Well, I suppose you could compile with -source 1.4

Unchecked means the compiler cannot guarantee safety at compile time.
The truth is it can't. It has absolutely no idea what A will be/do. If
you want the compiler to be able to check, it wants to see the code at
compile time.

Further this code makes no sense to me. If type A is known at compile
time, why are you dicking around with Class.forName. You only do that
when you DON'T know the class name, just an interface it implements..

In this case, you can use Class.asSubclass:

   Class<A> clazz = Class.forName("A").asSubclass(A.class);

As Tony pointed out, there are perfectly valid (and sometimes
unavoidable) constructs which will produce unchecked cast warnings.
Read up on the @SuppressWarnings annotation, and note that Sun's
compiler didn't support it until 1.5.0_06.

I'm assuming that the code you posted is a contrived example.  If not,
Roedy's comment is right on; there's no reason to use Class.forName for
a known type.

HTH

As pointed out, a better example should be

  class A implements B {
    public A(String a);
  }

  Class<A> clazz = (Class<A>) Class.forName("A");
  Constructor<A> ctor = clazz.getConstructor(String.class);
  B b = ctor.newInstance("hello world");

Though I may understand *why* the compiler complains, I
have a feeling that a warning from the compiler is a strong
hint to modify the code so that the warning disappears.
What use has a warning if it is always there? But I guess
it boils down to the definition of the term "warning", and I
might be influenced by past (and present) experience with
C/C++ compilers as Chris suggests.

But my second question was not adressed. Why doesn't the
compiler complain in this case:

  class A implements B {
    public A();
  }

  Class<?> clazz = Class.forName("A");
  B b = (B) clazz.newInstance();  // Why is this safe?

Thanks!