https://github.com/openjsse/openjsse
"The OpenJSSE project was created to add support for TLS 1.3 to existing Java 8 applications without requiring code changes"
How to use this project exactly?
I'm currently using the AdoptOpenJDK build for Java 8.
As mentioned in the issue log for openjdk (Link):
OpenJSSE for OpenJDK can be installed in two possible ways:
add OpenJSSE provider in the list of security providers of java.security file
registered at runtime with Security.insertProviderAt method
However you'll better use Azul JDK8 builds as soon as it has preintegrated and fully tested support for OpenJSSE provider with -XX:+UseOpenJSSE
Related
I currently have an environment where I am trying to get a Liberty Profile v8.5.5.9(using Java 7) to utilize a WebSphere MQ v9.0.3(using Java 8). These two are on the same box, the server.xml is configured correctly, but I'm getting a namespace error when I'm trying to do a direct client connection.
I'm just trying to rule out if there's a problem using these two versions together that would cause a JNDI problem.
There apparently is a conflict between the two environments. Once I removed 9.0.3 and installed 7.5(MQ) it now works.
Can a Java 6 application work on Webpshere 8.5 if the nodes are built using Java 7? I have an EAR which was developed using Java6 and deployed on Websphere 8.5 using EA but the Webservice always gives 404.
Thanks.
It appears that that no support is provided for Java SE 6 in that version of WebSphere.
From the online documentation for WebSphere 8.5.5 (not sure if this is the version you are using tho')
Notice: Java SE 6 is being removed from service. Java SE 8 is the
recommended Java SDK because it provides the latest features and
security updates. You can continue to use Java SE 6, but no service
can be provided after the end of the support date, which might expose
your environment to security risks.
In fact, it appears that not even Java SE 7 is supported in this version of WebSphere either
There is a confusion here about the meaning of "version" and how it applies to JavaEE applications:
There is the version of the JVM which is selected to run the server.
There is the JavaEE specification level used to encode XML documents (web.xml, application.xml, ejb-jar.xml, etc) which are within an application.
There is the JavaEE specification level which is supported by the server.
There is the java compiler level which is set for classes packaged within an application.
There is, technically speaking, no specific version associated with an application. That an application is at Java 7 can mean "the classes of the application were compiled to java7", or, "the XML descriptors are set to the versions available to JavaEE7", or, "the function of the application requires a container which supports JavaEE7".
A key detail is that when running with WebSphere, its the server which decides to which JavaEE specification the application is run, not any feature of the application.
I'm guessing that in the original question, "Java 6 application" means the application was compiled to java6 and that the application features are limited to those available in java6. That should work on all of WebSphere v7.0, v8.0, v8.5, and v9.0 (at all service levels).
There are some complications to consider when using a distributed topology (having a DMGr node and more than one application server nodes). A frequent complication is that one or more of the application server nodes is at a lower version than the DMgr node. This is a supported scenario (with some limits on how big of a version difference is supported). The scenario is typical when a topology (a collection of federated nodes) is being migrated gradually from a particular WebSphere version to a higher version, and during the migration a mixture of node versions is available. When this is the case, the DMgr tracks the version of the application server nodes and constrains processing of the application to ensure the deployment is valid to all of the application server nodes to which the application is deployed.
Since the JavaEE level is set by the application server version, and since, generally, higher versions of the application server implement higher JavaEE levels, applications can function differently when migrated between application server versions. Whether this is the case for this question cannot be known without looking in more detail at the exact failure which is occurring.
I found that Hotswapagent works different way in SE and EE application. In SE application I can add a new property to the class (e.g. private Long x;) without any problem, Hotswap can update the code. But I'm not able to do this in my EE application in a JSF ManagedBean, I got "The virtual machine does not support this operation: schema changes not implemented".
My EE application is a Maven Enterprise Application (ejb,web,ear projects) in Netbeans 8.2 with Wildfly 10. I use DCEVM (jdk1.8.0_112) and Hotswapagent 1.1.0.
Simple code changes (e.g. edit method body) are works both in SE and EE applications, but it can't handle new property creation neither in ejb nor in web project. I'd like to know if I made some mistake in settings or this is because the differences between SE and EE environments. Thanks for any ideas.
There's no problem with it. Only when I start application in debug mode.
I would expect the addition of a field to be considered a schema change (in such a case, you would get the exception in both Java SE and Java EE). But Java EE is specific by modification of classes (bytecode) at runtime. I guess that when you inserted a field, it wasn’t just that field what was added, but also some synthetic getter and/or setter was introduced, which was a schema change for sure.
HotswapAgent works on JVM level, there should be no difference between Java SE and Java EE. Most probably your Wildfly server does not use DCEVM, please check your setup.
here there is all you need to know to config any EE app server
Payara + DCEVM config
In trying to connect from an MQSeries 7.5 client to a 7.5 local server I'm getting a CSIException: JMSCS0002 which when I look up the error in the IBM codes says:
JMSCS0002
The call could not be completed because CommonServices has not been initialized.
CommonServices is an internal component and needs to be initialized at startup but has failed.
Check that the installation and classpath setup is correct.
But both my compile and run classpaths include com.ibm.mq.commonservices.jar, com.ibm.msg.client.commonservices.jar, and com.ibm.msg.client.commonservices.j2se.jar
I'm was using Oracle JDK 1.6. I tried using the WS MQ java but it made no difference.
Any help appreciated. Thanks.
Caused by: com.ibm.msg.client.commonservices.CSIException: JMSCS0002
at com.ibm.msg.client.commonservices.workqueue.PIWorkQueueManager.enqueueItem(PIWorkQueueManager.java:67)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.enqueue(WorkQueueManager.java:225)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.enqueue(WorkQueueManager.java:194)
at com.ibm.msg.client.wmq.common.internal.WMQThreadPool.enqueue(WMQThreadPool.java:91)
I had been using jar files from an uninstalled MQSeries 7.5 Client because I wanted to make sure that the functionality I was using would work just with the jars provided by the free client license. According to IBM documentation taking uninstalled jars is problematic.
When I switched to the jars from the installed server trial then things works ok.
I'm trying to build a Java 5 system using Java 6. I have configured and with 1.5, but I also need to set to point at a Java 5 rt.jar to ensure there are no faulty linkages like using Java 6 APIs. Has anyone ever configured maven to somehow pull rt.jar from a repository and reference it this way?
You can verify your usage of external libraries - and implicitly of the Java core APIs - by using the Animal Sniffer Maven Plugin
The Animal Sniffer Plugin is used to build signatures of APIs and to check your classes against previously generated signatures.
The plugin website shows how to generate signatures for the Java runtime and how to check against generated signatures.
You can send the source and target options down to javac by configuring the default maven java compiler plugin. Take a look at this page for an example.