On the other side, if the above affirmation is correct, I would be reluctant to use merely < pure > Java features, because this could reduce the performance of the application. What would be your advice?
"Pure Java" does not necessarily mean "no J2EE". Typically, "pure Java" refers to the absence of native methods, i.e., going outside of the scope of the JVM and standard Java extensions in order to do work.
In the past, building a J2EE application that would be executed within a given vendor's application server exposed the application to the risk of not transparently porting to another vendor's application server. The majority of the porting problems were caused by differences in EJB and servlet deployment mechanisms. However, most of these differences have been resolved as the result of standardization of the suspect deployment technologies.
To avoid porting problems, be sure to use the standard tools and guidelines when building and deploying EJBs, servlets and other J2EE components.
Dig Deeper on Application portability and interoperability
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.