FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.0.6002]

EXTRA RELEVANT SYSTEM CONFIGURATION :
ActivClient CAC x64 6.2.0.50

-- LIBRARY VERSION --

CSP Library:
Name: accsp.dll
Version: 5-1-0-20

P11 Library:
Name: acpkcs211.dll
Version: 5-1-0-22

BSI Library:
Name: acbsi21.dll
Version: 5-1-0-11

PIV Library:
Name: acpivapi.dll
Version: 4-4-0-7


A DESCRIPTION OF THE PROBLEM :
An unsandboxed multithreaded swing client will deadlock on startup. At the point when the app deadlocks, the EDT is trying to execute "new Foo()", which results in ClassLoader.loadClass while the main thread is trying to locate a resource file on the local disk using Class.getResource. If the main thread triggers a jar verify of a signed jar (bsi21classes.jar) while the EDT is trying to load a class, the deadlock occurs. If all jars in the classpath are unsigned, like in the previous version of ActivClient, the deadlock does not occur.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Use a classpath order = %programfiles%\ActivIdentity\ActivClient\bsi21classes.jar;%programfiles%\ActivIdentity\ActivClient\bsi21interf.jar;%programfiles%\ActivIdentity\ActivClient\acjsys.jar;app\unindexed unsigned.jars*;app\a folder with resources

2. Create a unsigned unindex jar to load classes from.
3. Create a folder with a file resource.
4. Make one thread call loadClass while the another thread triggers a signed jar verify.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No deadlock.
ACTUAL -
Output is attached seperatly

REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
1. Don't call Class.getResource until most of the classes have been loaded.
2. Synch on the classloader prior to calling getResource.