I know Oracle JRE has Java Smart API implementation. However, if I try to use IBM JRE, it doesn't even ship with javax.smartcardio package.
Who know whether IBM JRE provide javax.smartcardio package and implementation or not? If so, where to get it?
Who know whether IBM JRE provide javax.smartcardio package and implementation or not? If so, where to get it?
IBM knows if they provide that particular package. If they provide it, they will know where you can get it. I presume IBM. IBM used to ship with their own (badly designed, but working) smart card library however.
Note that JSR 268 specifies a package in the javax namespace. This means that implementation of the JSR is optional. You may be able to download and use a reference implementation from Oracle from their page. It states that the "RI" is available for free (although the testing kit costs about 50K$).
Related
I have problems with the following method:
sun.security.x509.AuthorityKeyIdentifierExtension.getEncodedKeyIdentifier()
It exists in openJDK but it does not exist in oracleJDK. I always thought that except for some special cases regarding licensing those JDKs should be the same ...
While I can work around that issue, I fear there are other incompatibilities I might not be aware of.
Classes that are not part of the standard packages and classes that are deprecated can be not part of a jdk.
In your case you can try to solve the problem using the classes of the package javax.security.cert. Searching for it on google you can find some tutorials like this one.
Just to complete the answer is true that "generally" both compiled code comes from the same source code in the open jdk and in the oracle jdk. But oracle jdk and open jdk have different licences so there are also few little differences. Generally the differences are not related to the source of common classes, but to the presence or absence of classes or entire packages. As an example see the font library.
This is not the only difference. As you noted in your code also the security packages are different, because the open jdk added also the old sun version of x509 certificate classes and the oracle jdk not. There is no guarantee on what classes are included or not if they are not part of the standard packages. So if you have problems running your code on different jdk environments use only standard packages or explicitly import libraries as you need.
That class is not part of the public Java API and is therefore not guaranteed (or even likely) to exist in every JRE implementation, nor every release of the same provider's implementation.
If it's not part of the standard APIs, then you can't count on it.
Java Standard Edition 8 - all JDKs should provide these
Java Enterprise Edition 7 - some environments and libraries will provide these
While the OpenJDK and OracleJDK implementations happen to be very similar as they share a common history, they could diverge (or converge) in any private APIs or implementation details at any time, simply because they are separately-run projects.
Instead you should be using the appropriate implementation-agnostic APIs in java.security and javax.security for dealing with certificates.
Oracle JDK was previously called SUN JDK and that was before the takeover by Oracle. Earlier, it was the official proprietary implementation of the Java language. After the takeover it was named as Oracle JDK and Oracle’s team maintains the JDK.
OpenJDK is an open source implementation of the Java Standard Edition platform with contribution from Oracle and open Java community.
Actually, Oracle JDK’s build process builds from OpenJDK source code. So there is no major technical difference between Oracle JDK and OpenJDK.
Apart from the base code, Oracle JDK includes, Oracle’s implementation of Java Plugin and Java WebStart. Also includes third party closed source and open source components like graphics rasterizer and Rhino respectively.
How Oracle JDK and OpenJDK is kept in Sync:
All of the development and bug fixes happens in OpenJDK and then they are propagated to the Oracle JDK. Security fixes happens in private forest without public code reviews unlike general fixes, then they are pushed to Oracle JDK and then to OpenJDK.
more on http://javapapers.com/java/oracle-jdk-vs-openjdk-and-java-jdk-development-process/
The compiler display warnings if you use Sun's proprietary Java classes. I'm of the opinion that it's generally a bad idea to use these classes. I read this somewhere. However, aside from the warnings are there any fundamental reasons why you should not use them?
Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs.
Try to avoid uses of such APIs, always prefer a public documented and specified class.
The JDK 6 Documentation includes a link titled Note About sun.* Packages. This is a document from the Java 1.2 docs, so references to sun.* should be treated as if they said com.sun.*
The most important points from it are:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java.*, javax.*,
org.* and sun.*. All but the sun.*
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun.*, that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.*
packages are not 100% Pure Java.
and
Each company that implements the Java
platform will do so in their own
private way. The classes in sun.* are
present in the SDK to support the Sun
implementation of the Java platform:
the sun.* classes are what make the
Java platform classes work "under the
covers" for the Sun Java 2 SDK. These
classes will not in general be present
on another vendor's Java platform. If
your Java program asks for a class
"sun.package.Foo" by name, it may fail
with ClassNotFoundError, and you will
have lost a major advantage of
developing in Java.
Try running your code with a non-Sun JVM and see what happens...
(Your code will fail with a ClassNotFound exception)
Yes, because nobody guarantees that these classes or API will be the same with the next Java release and I bet it's not guaranteed that those classes are available in Java versions from other vendors.
So you couple your code to special Java version and loose at least portability.
Sun's proprietary Java classes are part of their Java implementation not part of the Java API their use is undocumented and unsupported. Since they are internal they can be changed at any time for any reason that the team working the Sun JVM decides.
Also Sun's Java implementation is not the only one out there! Your code would not be able portable to JVMs from other vendors like Oracle/BEA and IBM.
Here is Oracle's answer: Why Developers Should Not Write Programs That Call 'sun' Packages
I recently had a case that showed a real-world problem you can hit when you use these classes: we had code that would not compile because a method it was using on a sun.* class simply did not exist in OpenJDK on Ubuntu. So I guess when using these classes you can no longer say things like 'this works with Java 5', because it will only work on a certain Java implementation.
I don't find any references in JDK 7 documentation regarding sun.* packages.
Is it deprecated. But then what are the substitutes?
For eg: sun.reflect.*; is deprecated, so what are the options now?
It would be great if someone could post the deprecated packages and the new options available.
Note: I succeded in using them by setting access rules to all available.
What does this mean?
You have to use the java.lang.reflect package for reflection purposes.
See: http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/package-summary.html
The sun.reflect packages are not deprecated. They are for internal use by the JDK only. Oracle (formerly Sun) does not document the internal packages and does not guarantee that they will exist on all Java platform implementations (any vendor can make a Java platform implementation) nor that they will be the same in all versions of the standard Oracle Java platform implementation.
Oracle explains this on their website:
The sun.* packages are not part of the supported, public interface.
A Java program that directly calls into sun.* packages is not
guaranteed to work on all Java-compatible platforms. In fact, such a
program is not guaranteed to work even in future versions on the same
platform.
It seems to me that the Java Compiler API allows to compile at runtime a class, writing its output (the .class file) to the file system. However, in-memory compilation is not supported. Is this correct ? or is possible to use this API to compile a class in memory (from a String) and instantiating such class afterwards ?
(I know I can compile the class to the file system and load it afterwards with a custom class loader, but I am wondering if I can compile it in memory, without passing by the file system).
Is there another alternative mechanism to do such in memory compilation using the J2SE only?
BeanShell (I library that can do what I want) mentions in its web page that it may be included in the J2SE at "some point in the future", however, the status of its JSR is "Dormant" (whatever does it mean).
Update:
Ideally, I would like to know if this can be done with the J2SE only (or if there are any expected enhancements to J2SE that will allow me to do this in, for example, Java 8). However, tips about how to do that requirying the JDK to be installed are also appreciated (thanks Evgeniy).
It is possible if you have JDK, java complier is in tools.jar which comes with JDK only. See http://docs.oracle.com/javase/7/docs/api/javax/tools/package-summary.html
Java Compiler API .. in-memory compilation is not supported. Is this correct?
No. The STBC uses the JavaCompiler to do exactly that.
..and instantiating such class afterwards?
The STBC does not go as far as trying to load/run the class, but I believe it should be possible. I imagine it might require a custom 'in memory' class loader though.
..the JavaCompiler API can do that independently if the JDK is installed or not?
From the page..
System Requirements
STBC will run on any computer with a version 1.6+ Java Plug-In* JDK (AKA SDK).
* The API that STBC uses is merely a public interface to the compiler in the tools.jar that is distributed only with JDKs (though the 'public JRE' of the JDK also seems to acquire a tools.jar). ..
I am porting a webapplication written in jdk1.4 to 1.6. While compiling I am getting warnings related to sun.security package deprecation. Though I can compile with warnings, I prefer to do a compile without warnings.Also this could become errors in future when using jdk 1.7 version.
Warnings are like
warning: sun.security.util.DerEncoder is Sun proprietary API and may be removed in a future release
I am ready to change the source code by removing the sun packages and use some third party free package. For fixing some other issues I have rewritten other parts of code(which uses classes like sun.misc.BASE64Decoder) using org.apache.commons.codec .But I couldn't find any replacements for sun.security.util.
My server is apache tomcat, so using other server libraries like *ibm* won't be feasible.
Edit
I am using classes including(not limited to) sun.security.util.DerEncoder, sun.security.util.DerInputStream ,sun.security.util.DerValue,sun.security.util.ObjectIdentifier ,sun.security.x509.X500Name etc
In fact, sun.security.util.DerEncoder is an interface and you could trivially create your own version. The difficult task would be locating and dealing with the classes that implement this interface.
For what it is worth, the DerEncoder interface defines a single method:
public void derEncode(OutputStream out)
throws IOException;
The method is supposed to output the DER encoding for this to the supplied stream.
DER is an encoding scheme for ANS.1 data. AFAIK, this interface is internal to the Sun implementation of X.509 certificates and so on. I suspect that fixing this is not simply a matter of finding a replacement class. Rather, I think you need to understand the reason why your code is (apparently) using this interface, and then figure out the "correct" way to do what it needs to do. ("Correct" ... as in using public APIs.)
UPDATE
Based on the other classes you are using, I think you need an X500 for Java implementation:
One possibility is the "Oracle Security Developer Tools Security Engine" (aka "Oracle Fusion Middleware Security Engine"). This appears to be part of the Oracle 10g and 11g product suite, but it may also be available separately. Link: http://docs.oracle.com/cd/E23549_01/apirefs.1111/e10674/toc.htm
As far as I can tell, you can't get this stuff for free. You can only get it embedded in various paid-for Oracle products.
Another possibility is the BouncyCastle X509 implementation.
Note that Java 6 is EOL'ed, so you should really be porting to Java 7.
If you really need to get rid of these classes (they're still there in 1.7 AFAICT), you'll probably have to rewrite the entire code with equivalent code from a cryptography library. Try this one:
http://www.bouncycastle.org/java.html