Somehow, the JCE continues to amaze me. It claims to support the AES
cypher, yet the following code throws a NoSuchAlgoritmException:
import java.security.NoSuchAlgorithmException;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
public class CypherTest {
public static void main(String[] args) throws
NoSuchAlgorithmException, NoSuchPaddingException {
Cipher aes = Cipher.getInstance("AES");
System.out.println(aes);
}
}
Results in:
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot
find any provider supporting AES
at javax.crypto.Cipher.getInstance(DashoA12275)
at CypherTest.main(CypherTest.java:10)
But wait, there's more. If i explicitly get my Providers, and list their
Services, i can clearly see Cipher.AES begin supported by the SunJCE
Provider. However, if i explicitly try to instantiate it by
public static void main(String[] args)
throws NoSuchAlgorithmException, NoSuchPaddingException {
Provider jce = Security.getProvider("SunJCE");
Cipher aes = Cipher.getInstance("AES", jce);
System.out.println(aes);
}
I get
Exception in thread "main" java.lang.SecurityException: JCE cannot
authenticate the provider SunJCE
at javax.crypto.Cipher.getInstance(DashoA12275) at
CypherTest.main(CypherTest.java:13)
Caused by: java.util.jar.JarException: Class is on the bootclasspath
at javax.crypto.SunJCE_d.a(DashoA12275) at
javax.crypto.SunJCE_b.b(DashoA12275) at
javax.crypto.SunJCE_b.a(DashoA12275) ... 2 more
Can someone shed some light on this?

Signature
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper
Stefan Schulz - 09 Feb 2005 11:31 GMT
> Can someone shed some light on this?
Things get stranger and stranger... when i try to do the same outside of
Eclipse, it works like a charm!
Now if only i could make sense of this behaviour...

Signature
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper
Roland - 09 Feb 2005 12:53 GMT
>>Can someone shed some light on this?
>
> Things get stranger and stranger... when i try to do the same outside of
> Eclipse, it works like a charm!
>
> Now if only i could make sense of this behaviour...
Interesting. I see the same behavior.
Did some further experimenting (Eclipse 3.0.1).
It seems to be affected by the setting of 'Use system libraries' in
Window -> Preferences -> Java -> Installed JREs -> (select JRE) -> Edit
If 'Use system libraries' is unchecked (off), Eclipse adds the
'-Xbootclasspath' parameter (with all the libs in the list) to the java
executable. [I used sysinternals.com's Process Explorer to reveal the
commandline of the java executable started by Eclipse.]
If it's checked, Eclipse doesn't add -Xbootclasspath, so it allows the
java executable to discover its on boot classpath.
Running the program from commandline causes java also to discover it's
own boot classpath. I didn't try specifying -Xbootclasspath on the
commandline.
Next question then would be, why java cannot find the algorithm when the
bootclasspath has been specified with all libs from the JRE.

Signature
Regards,
Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \