I don't think there is any difference, other than when you use "new" you have to know the name of the class at compile time. You can use newInstance to instantiate a class that you don't determine until runtime, thus making your code more dynamic. I'm sure someone else can probably explain this better.
Dwayne is correct. The only additional difference I can think of is that the snippets may throw different exceptions. Why do you want to know?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Well, the other difference is that new foo() will execute much faster than the alternative. (Fifty times as fast in a test I just ran, with a very simple foo class.) Reflection is great for certain applications where at compile time you don't know the name of the class/method/whatever you're dealing with - but it's not worthwhile in most other situations. It's slow, cumbersome to use, and harder for other programmers to understand. At least, compared to normal invocation methods.
You can use newInstance to instantiate a class that you don't determine until runtime, thus making your code more dynamic. Absolutely! I would type a passionate speech about the importance of Java reflection abilities, but Ted Neward in his classical work "Understanding Class.forName()" already said it better than I could: "This use of dynamic runtime loading is the heart of Java Application Servers like the Java2 Enterprise Edition reference implementation, Enterprise JavaBeans, and the Servlet Specification. In each one of these architectures, at the time the application server is compiled, it knows nothing about the code that will be attached to it. Instead, it simply asks the user for a classname to load, loads the class, creates an instance of the class, and starts making method calls on that instance. (It does so either through Reflection, or by requiring that clients implement a particular interface or class, like GenericServlet in the Servlet spec, or EJBObject in the EJB spec.) Use of dynamic run-time loading isn't restricted solely to server-side architectures, however. Web browsers must use it in order to be able to load applets specified by name by a remote web page, as well. RMI uses it to dynamically load stubs and/or skeletons for remote objects, and JNDI and JDBC will use it to load, at runtime, the exact driver necessary (given by the user's appropriate ".properties" file) to perform the work asked. In each case, a ClassLoader is asked to load a class by name that may not have existed within the JVM before this moment." Dwayne is correct. The only additional difference I can think of is that the snippets may throw different exceptions. I believe, instantiating a class via Reflection is slower than "directly", but unless you need to make billions of instances, it shouldn't matter that much. Is there any thing to do with the classloader or the VM? If I am not mistaken, when you instantiate something with a new() keyword, the class is being loaded by the same class loader that loaded a class that issued "new()" , With reflective instantiation you can specify explicitly which class loader you want to use (for example, one of overloaded forName() methods takes an instance of ClassLoader as a parameter).