Platform, compiler, provider & JRE requirements
We're constantly adding new platforms to the mix but most of our platform ports were initiated by customer demand. For some combinations, we might ask you to generate a dynamic link library yourself using our JunC++ion tool. It comes with a preconfigured project for JMS Courier. Contact us if you need JMS Courier on a yet unsupported platform and we can discuss what's involved in doing a port for you.
|Windows 98 and later on IA32 and AMD64.||Supported on all flavors of Windows.|
|Linux on IA32 and AMD64||We're building on RHEL 5. We don't make any warranties for other distros but there's no reason it shouldn't work. As far as we can tell, our build creates a dependency on GLIBC_2_3 but that could probably be "fixed" if someone needed it on a distro that does not have GLIBC_2_3.|
|Solaris on Sparc and Intel|
|MacOS-X 10.4 and later|
We always strive to support at least the "platform native" compiler. While there has been occasional demand for other compilers, it never amounted to much. Just as with platform ports, we're always willing to entertain compiler ports if you're seriously interested and willing to commit yourself.
|Microsoft Visual C++ 6
Microsoft Visual C++ .NET
Microsoft Visual C++ 2002
Microsoft Visual C++ 2003
Microsoft Visual C++ 2005
|We imply the Windows platform here.|
|g++ 3.2, (3.3), 3.4, 4.0.1+||On Linux we support all relatively modern versions of the GNU C++ compiler with the exception of 3.3 and 4.0.0. Applications compiled with g++ 3.3 could have some runtime issues and g++ 4.0.0 simply does not work whereas 4.0.1 works fine.|
|VisualAge C++ 6||On AIX.|
|Sun Workshop 6u1 or higher||On Solaris Sparc.|
In theory, JMS Courier should work with just about any Java Runtime Environment. In practice, we require a fairly complete and correct implementation of the Java Native Interface (JNI). Such implementations have become fairly commonplace since Sun JRE 1.2.1 and you can probably use any fairly modern Java2 or later JVM in in-process mode.
Sometimes a later version (particularly a point zero version) might introduce some regressions that could impact an integration solution like JunC++ion. In all likelihood, this is not going to be an issue, but to be certain, we only qualify JunC++ion with JREs we have tested with in the past.
A JRE is only required at runtime and only if you're using the recommended in-process mode. The C++ proxy classes that make up the JMS Courier API have been generated against a JRE 1.4.2. This means that some support types (for example java::lang::String) contain proxy functions that can only be used when running with a 1.4 or higher JVM. Just to stress this point: you can safely use the JMS Courier classes if you're planning to run with a JRE 1.3 as long as you stay away from proxy methods that correspond with JRE 1.4 features. The entire JMS API for example is perfectly safe to use.
f you're deploying in out-of-process mode, you need the JRE only on the machine that hosts the Shared JVM server.
|Sun JRE 1.2.2 - 1.5.x||There are no known limitations for any Sun JREs.|
|IBM JRE 1.4||There are no known limitations for the IBM JRE but we have only tested with the 1.4 version.|
|BEA (JRockit) 1.5||There are no known limitations for the BEA JRE but we have only tested with the 1.5 version.|
Shared JVM mode
In out-of-process (Shared JVM) mode, the JunC++ion shared JVM server requires at least a JRE 1.4, otherwise the in-process constraints apply.
JMS Courier theoretically works with any JMS provider that is JMS specification 1.0.2 or 1.1 compliant and that can be discovered via JNDI. We have tested with a number of different providers and our customers are using JMS Courier with several more. The following table contains a list of providers we know JMS Courier to work with. We have yet to encounter a provider JMS Courier does not work with.
nirvana is a high-performance, commercial messaging system with a very good JMS interface. It is popular in the financial industry and Codemesh enjoys a very good relationship with my-channels.
Due to this relationship, we can resell nirvana as a fully supported backend for JMS Courier.
Check out the runtime configuration for nirvana here.
Popular open source application server with embedded JMS.
Check out the runtime configuration for JBossMQ here.
|IBM WebSphere MQ||
IBM's industrial strength messaging solution.
OpenJMS is an open source JMS implementation that is popular as a stand-alone messaging solution.
Check out the runtime configuration for OpenJMS here.
BEA's enterprise messaging system, bundled with WebLogic application server.
Check out the runtime configuration for WebLogic JMS here.