The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

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?

asked 01 Jun '12, 18:46

Derli%20Marcochi's gravatar image

Derli Marcochi
1.6k323877
accept rate: 33%

edited 01 Jun '12, 19:30


AFAIK, there are (at least) four JREs that can be used by SQL Anywhere:

  • The administration tools (particularly DBSIQL and Sybase Central) make use of the JRE6 included in the \Sun\jre160_XYZ subfolder. As to the docs:

The administration tools require JRE 1.6.0. You should not substitute a later patch version of the JRE unless you have a specific need to do so.

  • The database server can make use of any JRE it is configured with, cf. the ALTER EXTERNAL ENVIRONMENT JAVA LOCATION statement. To quote:

If you want to use JAVA in the database, but do not have a Java Runtime Environment (JRE) installed, you can install and use any Java JRE that you want to. Once installed, it is best to set the JAVA_HOME or JAVAHOME environment variable to point to the root of the installed JRE.

  • The MobiLink server has a different setting for Java scripts, cf. the -sl java option.

  • And obviously, any JDBC client will use its own JRE - where JDBC 4 drivers require a JRE 1.6 or later whereas JDBC 3 drivers have lower requirements.

So the question is: To what kind of JRE usage do you refer?

permanent link

answered 04 Jun '12, 06:40

Volker%20Barth's gravatar image

Volker Barth
29.3k287438645
accept rate: 32%

edited 05 Jun '12, 10:50

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.

permanent link

answered 04 Jun '12, 10:56

Phil%20Mitchell's gravatar image

Phil Mitchell
1.9k1831
accept rate: 27%

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.

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".

The java that is picked up by the command-line is defined by the first binary that appears in your environment's $PATH variable. (To see which one is currently being used, type 'which java'). When you execute sa_config.sh, we place our JRE 1.6.0 binary path ahead of others:

/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.)

permanent link

answered 04 Jun '12, 16:51

Jeff%20Albion's gravatar image

Jeff Albion
10.7k171174
accept rate: 24%

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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×404
×86
×62
×51
×14

question asked: 01 Jun '12, 18:46

question was seen: 1,283 times

last updated: 05 Jun '12, 12:15