Consider this simple test program:

  public class test {

      public static void main(String[] args) throws Exception {

          String[] s = new String[] { "123" };
          String clName = s.getClass().getName();
          test.class.getClassLoader().loadClass(clName);
      }
  }

This runs fine on JDK 1.5, but throws this exception on JDK 6.0:

Exception in thread "main" java.lang.ClassNotFoundException: [Ljava.lang.String;
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at test.main(test.java:7)
Posted Date : 2006-06-05 21:54:58.0

Change classLoader.loadClass(className) into Class.forName(className, false, classLoader).
The workaround for applications that depend on this is to set the system property  sun.lang.ClassLoader.allowArraySyntax to true (ie: -Dsun.lang.ClassLoader.allowArraySyntax=true).

Please see the evaluation in 4976356 and 6500212. As stated, it was purely accidental that it ever worked. The original intention was to disallow array syntax in jdk5. When changed in jdk5 it caused problems for some applications and so, to give them time to remove their dependency, it was defered to jdk6. Unfortunately this wasn't documented in the compatability notes for that release.
Posted Date : 2009-08-17 08:29:18.0

This bug is very severe. We need it to be fixed ASAP.

Fix it soon...........

This issue block the possibility  of using myfaces tomahawk in a jsf web project.

I think I found a work around to this bug, which appears to be related to the native code of the underlying JVM.  Bascially when the loadClass(clName) failed, catch the ClassNotFoundExcecption and do a Class.forName(clName).  That seems to work quite nicely.

How about just using the documented workaround for this change (which appears to be the result of a deliberate policy decision, not a bug at all.

Add the following to your java command line args and the code sample above works fine:

-Dsun.lang.ClassLoader.allowArraySyntax=true

Very significant bug. It breaks serialization of objects with string arrays. Please vote for it.

Waiting for the fix...

I tripped over this, and thought: JDK6 has broken something.

Now that there is a documented workaround, I think that it could be considered "fixed", as we now have two options:

1) Add -Dsun.lang.ClassLoader.allowArraySyntax=true if you want to use a library for which you don't have the source with JDK6

2) Change loader.loadClass( name ) to Class.forName( name, false, loader ) if you own the code.

If Sun are not intending to fix this to be compatible without the flag, then I think it would be great if we could have a clear statement here to close off this bug

This is indeed related with bug 6554519.

This is a very severe bug. Please fix it.

This problem has effected some little older libraries. Everyone should change the library codes etc to cover this? (Neale 's suggestion will not work) because this will make huge amount of previously written code unusable.

This bug forces us to use version 1.5.0 for Java develop. We make jsf development and use tomahawk in our developments. Is it considered to be fixed sometime in the near future??

This is a big problem for us...

Waiting for the fix...

Can someone give a simple example on using class.forName to fix this? i have a remote call to a bean on jboss with returns a String []. 

People who are "waiting for the fix" clearly have not read the evaluation, I guess. :-)

If you are using Hibernate (directly or though JBoss JPA),  be aware of this:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2990

This bug occured after security update of our companies client. Before that, everything was fine with JDK 1.6. The Workarround setting the -Dsun.lang.ClassLoader.allowArraySyntax=true Systemproperty doesn't seem to work in our case.
It seems that we are forced to switch back to 1.5, which has got certain backdraws for us.

Hi,
getting exception using jdk1.6+jsf1.1
plz provide me proper solution

java.lang.ClassNotFoundException: [Ljava.lang.String;
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1362)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1208)
	at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:615)
	at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:402)
	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:328)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3764)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
	at org.apache.catalina.core.StandardService.start(StandardService.java:448)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Jul 9, 2008 4:38:14 PM org.apache.catalina.core.StandardContext listenerStart

Forced back to 1.5.
Need fix

This bug also prevents us from using Web Start to launch our application. It is critical and Please fix this ASAP. Thank you

Can we get an estimated version in which this bug will be fixed.

Thanks.

I think i wont be fixed ? after one year

Please fix it.
The work around works for a command line, but how to set 
-Dsun.lang.ClassLoader.allowArraySyntax=true in a jnlp file?
I've tried with <property name="key" value="overwritten"/>  and this doesn't work. (maybe I did something wrong)

Very significant bug. It breaks serialization of objects with string arrays. Please vote for it.

We use Java Web Start and -Dsun.lang.ClassLoader.allowArraySyntax=true won't work with it.  Please fix this bug.  Please vote for this bug.

Can you guys at least add "sun.lang.ClassLoader.allowArraySyntax" to the list of secure properties that can be passed into a Webstart application using the java-vm-args attribute? So that Webstart apps could get around the issue like this:

<j2se version="1.6.0_05+" 
          java-vm-args="-Dsun.lang.ClassLoader.allowArraySyntax=true" ...

sun.lang.ClassLoader.allowArraySyntax is not included in this list of secure properties for Java 1.6: http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources

This makes JDK 1.6 useless in EJB3 projects. Please FIX!

Is there any difficulty in fixing this bug? 
At least, is there any difficulty to include sun.lang.ClassLoader.allowArraySyntax is not included in list of secure properties for Java 1.6?  (to also have a workaround in WebStart)

In case of  having any difficulty in fixing this bug,  can we have more information about this bug? (e.g. Is it a strategical problem or a technical one?)

I think this is still not fixed. It's really bad.

Not to be an ass, but if you read http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 it's pretty clear that this isn't a bug but rather users making assumptions not guaranteed by the specification and getting burnt when the implementation changes.

Why don't you just correct the user code in question to use Class.forName(className, false, classLoader) as mentioned in the "workaround" section? It sounds like the only correct way to accomplish what you're asking for.

I have this same problem, at first I had a problem with loading javac, finally got that to work and now this problem.  I would like to try the work around, however I have no idea where to change the classLoader.  Can you help?

Please tell me how and where to change classLoader.

Thanks,