|
We have openjdk 7 installed in a Ubuntu 12.04 box which is being used as a development and test box. After jdk7 was installed I confirmed that both javac and java were returning a 7 version: 1.7.0_03 I can't say for sure but it seems that when the SQL Anywhere 12.0.1 was installed it also installed a JRE 1.6.0_16 version as reported now in the "java -version". Since the java projects inside the IDE need a JRE platform to be clearly identified, I am not sure if this could become an issue since the projects are assigning a JRE7 platform but the SA 12 libraries may expect to be process in a JRE6 setup? Also, we have other .war files running as servlets under Tomcat Apache with JRE7 to where this project is being developed. Will we need to downgrade the JRE on the Tomcat server to run under a JRE6 platform? |
|
AFAIK, there are (at least) four JREs that can be used by SQL Anywhere:
So the question is: To what kind of JRE usage do you refer? Since the IDE and Tomcat are set up to compile/run in JRE7 I will experiment with the ALTER EXTERNAL to also set it as 7 as you listed. What caught my attention is that when I run java -version it is now listing 1.6.0_16 even though I had 1.7.0_03 installed.
(04 Jun '12, 13:08)
Derli Marcochi
@Volker, We have JRE7 as the designed platform in Netbeans so this is the reason we would prefer having the jdbc calls using the same.
(05 Jun '12, 11:44)
Derli Marcochi
|
|
The JRE installed with SQL Anywhere is primarily used by the administration tools. They are not tested with any Java version other than the one that we provide. As Volker mentioned, SA and MobiLink may use that JRE, but they can be configured to use others. Your client applications should also be able to use a newer JRE, provided that Oracle hasn't broken runtime compatibility with any JARs you might be pulling in from SQL Anywhere. Given that you are using Apache Tomcat, I'm guessing you are trying to make a JDBC connection to SQL Anywhere. In that case, I believe you should be okay to use JRE 7. If you run into trouble during testing that you think might be related to the JRE version, it wouldn't hurt to try it with the JRE installed with SQL Anywhere, just to be sure. 1
Yes, we are working with JDBC and Tomcat and would prefer to keep all modules under the same JRE environment. As my previous comment to @Volker, I will check if ALTER EXTERNAL will help. Not that I would do that right now, but do you think we could uninstall the JRE6 installed with the latest EBF and just run JDBC with the openjdk7 I installed?
(04 Jun '12, 13:15)
Derli Marcochi
Replies hidden
1
The ALTER EXTERNAL ENVIRONMENT configuration is only for java-in-the-database. If you are installing a JAR into the database to be run by the database server, then that's the place to configure the JRE. If you are only running a separate client application that simply connects to the server (as with a JDBC connection from Tomcat), you don't need to worry about that. Don't uninstall JRE 6 if you intend to use the administration tools. It is installed in a location within the SQL Anywhere installation directory, and we don't do anything to set it as the default JRE for the system, so I'm not sure why it would affect other applications.
(04 Jun '12, 15:06)
Phil Mitchell
|
|
See http://www.sybase.com/detail?id=1058536 for details on our Java Runtime Environment (JRE) support and options for replacing it, if you think the JRE version we include is an issue for your deployment.
The /bin64/sa_config.sh PATH="$SQLANY12/bin64:$SQLANY12/bin32:${PATH:-}" export PATH PATH="$SQLANY12/sun/jre160_x64/bin:${PATH:-}" << This line here ... To allow other Java executables to be picked up first, you would need to switch the order of the paths: /bin64/sa_config.sh PATH="$SQLANY12/bin64:$SQLANY12/bin32:${PATH:-}" export PATH PATH="${PATH:-}:$SQLANY12/sun/jre160_x64/bin" ... ... but note that this configuration may cause issues with the administration tools, depending upon the version of the JRE that is being picked up instead. See: http://www.sybase.com/detail?id=1058174. Basically, any way that you can resolve the path issue is a configuration that will work (e.g. launch the administration tools with a separate environment script with a separate PATH, only source "sa_config.sh" before you start SQL Anywhere tools, etc.) Making changes to the sa_config.sh could become an option for us in the long run. However, are there any plans on publishing EBFs for JRE7 environments as well?
(05 Jun '12, 12:07)
Derli Marcochi
Replies hidden
No, we will not update the JRE in an EBF unless there's a very good reason to do so. If an update happens, it will be done in a major release.
(05 Jun '12, 12:15)
Phil Mitchell
|
