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
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Java EE has this "mysterious shroud" around it for younger Java developers - one that I've been trying to lift myself for quite a while with little success.
Confusion arises from:
Java EE seems to be both a library and a platform - there are multiple ways to "get" the Java EE library, typically from something like Oracle's Java EE SDK download. However, the Java EE library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc). Why? Can't the libraries function outside of the application server environment? Why do I need something massive as JBoss just to compile simple code to send an email?
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
What can one do with Java EE that they cannot do with standard Java?
What can one do with standard Java that they cannot do with Java EE?
When does a developer decide they "need" Java EE?
When does a developer decide they do not need Java EE?
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)?
Thanks for helping me clear the flog!
Why can't the libraries function outside of the application server environment?
Actually they can. Most of the libraries can be directly used standalone (in Java SE) or included in a .war (practically that's nearly always Tomcat). Some parts of Java EE, like JPA, have explicit sections in their respective specifications that tells how they should work and be used in Java SE.
If anything, it's not so much an application server environment per se that's at stake here, but the presence of all other libraries and the integration code that unites them.
Because of that, annotations will be scanned only once for all your classes instead of every library (EJB, JPA, etc) doing this scanning over and over itself. Also because of that, CDI annotations can be applied to EJB beans and JPA entity managers can be injected into them.
Why do I need something massive as JBoss just to compile simple code to send an email?
There are a few things wrong with this question:
For compiling you only need the API jar, which is below 1MB for the Web Profile, and a little over 1MB for the full profile.
For running you obviously need an implementation, but "massive" is overstating things. The OpenJDK for example is around 75MB and TomEE (a Web Profile implementation containing mail support) is only 25MB. Even GlassFish (a Full Profile implementation) is only 53MB.
Mail works perfectly fine from Java SE (and thus Tomcat) as well using the standalone mail.jar and activation.jar.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Java EE in a way was one of the first attempts to split up the already massive JDK into chunks that are easier to manage and download. People are already complaining that the graphical classes (AWT, Swing) and Applets are inside the JRE when all they do is run some commands on a headless server. And then you also want to include all the Java EE libraries in the standard JDK?
With the eventual release of modularity support we'll just have a small base JRE with many things separately installable as packages. Perhaps one day many or even all classes that now make up Java EE will be such package as well. Time will tell.
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
There are more than just two flavors of Java SE. There is at least the IBM JDK, the previous BEA one (JRocket, which is being merged into the Oracle/Sun one because of the acquisition), various other open source implementations and a slew of implementations for embedded use.
The reason behind Java SE and EE being a specification is that many vendors and organizations can implement it and thus it encourages competition and mitigates the risk of vendor lock-in.
It's really no different with C and C++ compilers, where you have many competing offerings as well all adhering to the C++ standard.
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)
Java EE builds on Java SE, so it trails behind. The versions do correspond though. Java EE 5 requires Java SE 5. Java EE 6 requires Java SE 6 and so on. It's just that mostly when Java SE X is current, Java EE X-1 is current.
Here are a few quickly composed answers to your questions...
Why can't JavaEE libraries function without an application server?
The services provided by JavaEE (container managed transactions, container managed dependency injection, timer service, etc..) inherently involve JavaEE compliant Application Servers (for example: GlassFish, JBoss, WebSphere, etc...). Therefore the JavaEE libraries serve no purpose without such a container. "Why do I need something as massive as JBoss just to compile simple code to send an email?" You don't. There are ways to send an email without JavaEE... But if you want to do it the JavaEE way, you need a JavaEE container.
Why are JavaEE libraries not included with JavaSE download?
The same reason that many libraries aren't included: it would be overkill. Since you can't even use the JavaEE libraries without an application server, why bother to include them? JavaEE should be downloaded if and when a developer installs an application server and decides to use JavaEE.
Why are there so many JavaEE offerings?
Are there really "so many" JavaEE offerings? If so, please list some of them. More accurately I believe there are multiple implementations of the same APIs.
What can one do with JavaEE that they can't do without standard Java?
Lots. You can't rely on an application server to manage transactions or persistence contexts without JavaEE. You can't allow an application server to manage EJB dependency injection without JavaEE. You can't use an application managed timer service without JavaEE. The answer to this question should make the answer to the first question quite clear... Most of the services provided by JavaEE require a JavaEE container.
What can you do with JavaSE that you can't do with JavaEE?
Um... I don't know.
When does a developer decide they need JavaEE?
This question is completely subjective... But if you need any of the services provided by JavaEE, you start to think about it. If you don't know what JavaEE is... you probably don't need it.
When does a developer decide they do not need JavaEE?
See previous answer.
Why is JavaEE library version not in sync with JavaSE version?
Good question. I won't pretend to know how to answer it... But I would guess the answer is: "because they're not in sync".
At bird's eye view, Java EE is a platform, i.e. something that we can build on.
Taking a more technical perspective, the Java Enterprise Edition standard defines a set of APIs commonly used for building enterprise applications. These APIs are implemented by application servers - and yes, different application servers are at liberty to use different implementations of the Java EE APIs.
However, the java ee library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc).
You compile against the Java EE APIs, so you only need those APIs at compile time. At runtime, you'll also need an implementation of these APIs, i.e. an application server.
Why do I need something massive as JBoss just to compile simple code to send an email?
You don't. However, if you wish to use the Java EE API for sending mail, you will need an implementation of that API at runtime. This can be provided by an application server, or by provided by a stand alone library you add to your classpath.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Because only the APIs are standardized, not the implementations.
Why are there so many Java EE offerings
Because people disagree on the right way to implement certain features. Because different vendors compete for market share.
What can one do with Java EE that they cannot do with standard Java?
Since Java EE implementations are built with "standard Java": Nothing. However, leveraging the existing libraries can save a great deal of effort if you are solving typical enterprise problems, and using a standardized API can prevent vendor lock-in.
What can one do with standard Java that they cannot do with Java EE?
Nothing, since Java EE includes Java SE.
When does a developer decide they "need" Java EE? When does a developer decide they do not need Java EE?
Generally speaking, the Java EE APIs solve typical, recurring problems in enterprise computing. If you have such problems, it usually makes sense to use the standard solutions - but if you have different problems, different solutions may be called for. For instance, if you need to talk to a relational database, you should consider using JPA. But if you don't need a relational database, JPA won't help you.
What is Java EE?
Let's start from canonicity definition at wiki:
Java Platform, Enterprise Edition or Java EE is Oracle's enterprise
Java computing platform. The platform provides an API and runtime
environment for developing and running enterprise software, including
network and web services, and other large-scale, multi-tiered,
scalable, reliable, and secure network applications.
The main point here is that Java EE is a platform provides an API, not some concrete library.
What for Java EE needed?
The main scope of Java EE is the network based applications, unlike Java SE oriented to the desktop applications development with simple network support. This is the main diference between them.
Scalability, messaging, transactioning, DB support for every application... the need in all of this has increased with the evolution of the network.
Of course a lot of ready solutions which Java SE provides are useful for network development, so Java EE extends Java SE.
Why do we need application servers to run our code?
Why do we need operation systems? Because there are a lot of painful work with hardware we need to do to make even simpliest application. And without OS you need to do it again and again. Oversimplified OS is just a programmatic container, which provides us a global context to run our applications.
And this is what the application servers are. They are allows us to run our applications in their context and provides us a lot of highlevel functionality which is needed for enterprise highloaded network applications. And we are don't want to write our own bicycles to solve this problems, we are want to write code which will satisfy our business needs.
Another example here could be JVM for Java.
Why Java EE doesn't contains onboard app server?
Hard to say for me. I think, it was done for more flexibility. Java EE says what they should do, they decide how to do it.
Why JVM doesn't include Java EE?
Because they directed to different market sectors. Java EE has a bunch of functionality which is doesn't need for usual desktops.
Why are there so many Java EE offerings?
Because Java EE only describes the behaviour. Everybody can implement it.
What can one do with Java EE that they cannot do with Java SE?
To conquer the internet. It's really hard to do with Java SE applets and sockets :)
What can one do with Java SE that they cannot do with Java EE?
As mentioned above Java EE extends Java SE, so with Java EE you should be able to do everything what is available for Java SE.
When does a developer decide they "need" Java EE?
When they need the power of Java EE. All what is mentioned above.
When does a developer decide they do not need Java EE?
When they write a usual console or desktop application.
Why versions of Java SE and Java EE are unsynced?
Java always had troubles with it's technologies naming and versioning. So this situation is not an exception.
Java EE is all about container concept. Container is an execution context within which will run your application and which provide this last a set of services. Each kind of service is defined by a specification named JSR. For example JSR 907, JTA (java transaction Api) which provide a standard way to manage distributed transaction against different resources. There are generally many different implementations for a given JSR, the implementation you will use depends on the container provider, but you don't really mind about that as you are sure the behavior respect the predefined contract : the JSR API. So to take advantage of Java EE, you need to run your application inside a container. The two main ones are EJB and servlet container which are both present on any Java EE certified application server.
The aim of all of this is to defined a standard execution environment to allow to package your application with only the essentials, id.est. your business. It avoids to depend on a unknown and various set of third-party libraries that you would have to package and provide with your app otherwise, and which may be sources of conflict with other apps on the server. In Java EE you know that all standard non functional requirements like security, transaction, scalability, remote invocation, and many more will be provided by the container (factorized for all apps running inside it) and you just have to base your work on its.
I've taken over maintenance of an old web application, which uses multiple applets embedded in the same web page. This used to work fine, but since the Next Generation Java plugin was introduced (~1.6.0_10) the individual applets are not guaranteed to load in the same JVM instance. If they load in different JVMs, they cannot communicate through AppletContext.getApplets() or through static variables.
Is there any way we can force the applets to load in the same JVM instance? I saw a workaround mentioned where specifying identical 'java_arguments' parameter may encourage the Java plugin to run applets in the same JVM instance, but this does not work for our application (and in any case is not officially supported by Oracle and hence may disappear any time in any case).
We've also tried replacing direct applet-to-applet communication with indirect applet-to-JavaScript-to-applet communication, but we can't use this approach as our clients use old web browser versions which prevent this from working. I'd be keen to avoid routing all local applet-to-applet communication through a non-local server if at all possible.
We had a similar problem and worked around it by disabling the "next-generation" Java plugin in Java control panel.
Are the available Java-COM bridges like j-Integra, com4j and Jacob and others suitable to be used in a J2EE container? Which one is the most appropriate for that use? I need to evaluate the risk of JVM crashes, native memory leak and unmanaged thread creation (since it's not recommended in a J2EE container that uses thread pools) for the available Java-COM bridges available today.
I've used those bridges you mentioned. I would chose a very different approach, because of the things you said: crashes, mem leaks, and a lot of other stuff.
I would have a little Windows Server, using COM components since it is its native environment. In that little Windows Server you can expose some HTTP interfaces (WEB requests) you can use in your Java EE server to access COM components through Windows Server. That Windows Server can be an IIS with ASP.NET server, or a custom made program with a proprietary protocol you can write in C#, C++, C, VB.NET.
It's in my opinion, your safest choice. It will save you a lot of headaches when you go to production mode.
One of the reason you need to use JAVA-COM bridge is you need some Windows based functionality which is not available in Unix based system. Few years back it was no MS WORD, EXCEL JAVA APIs were available on Unix. So if possible try to use native JAVA APIs to achieve Windows based functionality. Like using APACHE POI. Setting J-Integra on machine with high security settings is tricky and needs special considerations.
What is the best (easiest, most seamless) way to build a Java app while relying as little as possible on the actual application-server used in deployment?
For example, say I want to deploy on Apache Geronimo, and later want to use GlassFish, how difficult would the transition be? What is the best way to abstract the use of each app server?
Excuse my ignorance, I'm relatively new to Java development. I want to start a new project, but am unsure on whether to use separate APIs for the functionality I need or develop on top of a chosen app-server from the start.
Thanks for your help,
Ivan
Without getting into too much details, even though you can write bare-bones Java EE code, the configuration around it is not very simple. Each application server has its own set of configuration files and naming conventions (for example, the format for specifying the location of the AS is different in IBM WAS and in JBOSS). Though these are not very important for application development, once you get to the deployment phase, these will become important.
As far as the libraries and your code is concerned as long as you stick to EJB standards you will be able to run your application on majority of the application servers (I know of WAS and JBoss - the code that I wrote didn't have to change for these servers; the configuration though, well that was a different beast !).
Follow Java EE specification as much as possible, while follow server specification least as possible.
If we try to find out what are in common among there Java EE application servers(JBoss, WAS...), answer is Java EE specification which server vendors must follow. If you have 2 solutions on a Java EE problem, you could check which solution comply with Java EE specification better rather than server specification.
From my experience with Jboss and Sun AS, you should just forget about AS-independency.
In sql, for example, you can do quite a lot without employing vendor-specific features. Well, it's not like that in Java EE. For Jboss and SAS even 'hello world' applications will require different configuration. And more application grows, more vendor-specific features you have to use.
In particular, if you look at official Sun Java EE tutorial, you'll find that it employs SAS-specific configuration files (sun-web.xml, sun-ejb-jar.xml, etc) from the very beginning.
But all above applies only if you use full range of Java EE features (like EJB, JMS, mbeans). I've found that if you just have servlets/jsps packaged in one war-archive, such application can still be very portable.
If you have the resources then consider developing and testing for several application servers instead of just your initial target one. This will allow you to - from the start - pinpoint things that need to be configurable and code accordingly.
Personally I would consider Glassfish 3.0.1 in such a situation as it is the reference implementation, so things should at least work there without any special efforts.