Meaningless Drivel is fun!*
The moose likes Tomcat and the fly likes String class can't find split method: wrong java version? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "String class can Watch "String class can New topic
Author

String class can't find split method: wrong java version?

Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Dear all,
I try to upgrade my code from 1.4.2_05 to 1.6.0_21 (different computers). The second PC is quite new and java was never installed on it before.


Old one:
C:\Documents and Settings\Administrator>java -version
java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)


New one:
C:\Users\Administrator>java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)


The following code:

String photoPathlist = "a,b,c";
String delimiter = ",";
String photoPathArr[] = photoPathlist.split(delimiter);


works absolutely fine of old (1.4.2_05) and gives error on new (1.6.0_21):

An error occurred at line: 114 in the jsp file: /PCMS/ErrorLogs.jsp
The method isEmpty() is undefined for the type String
111: }
112: else
113: {
114: boolean tmp = photoPathlist.isEmpty();
115: String delimiter = ",";
116: String photoPathArr[] = photoPathlist.split(delimiter);
117: String sourceNameArr[] = sourceNamelist.split(delimiter);

An error occurred at line: 116 in the jsp file: /PCMS/ErrorLogs.jsp
The method split(String) is undefined for the type String
113: {
114: boolean tmp = photoPathlist.isEmpty();
115: String delimiter = ",";
116: String photoPathArr[] = photoPathlist.split(delimiter);
117: String sourceNameArr[] = sourceNamelist.split(delimiter);
118: String photoFileNameArr[] = photoFileNamelist.split(delimiter);
119: String regFileName="";



line with isEmpty is added only for test: the both methods isEmpty and split are presented in 1.6 and absent in 1.3.
All methods from 1.3 work fine for String class.

I reinstalled JDK 1.6 - it doesn't help.

Does somebody have an idea - why version of string class comes from 1.3 version instead of installed 1.6?

Or it is something else? But what?

Thanks in advance for help!!!

Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60817
    
  65

Please take the time to choose an appropriate forum for your posts. This forum is for questions on JSP. For more information, please click this link ⇒ CarefullyChooseOneForum.

This post has been moved to a more appropriate forum.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38100
    
  22
If you look in the API documentation for String#split(java.lang.String), look at the last but one entry, where it says "Since: 1.4". That demonstrates the method was not available in Java 1.3. You can do the same for isEmpty.

I don't know why you appear to be using a 1.3 version of String. Sorry. Please search your PC for copies of rt.jar and similar standard Java installation files. There might be an old one that has crept in somewhere. Also check your PATH that you haven't let an old version slip in. Also try javac -version on your newer PC.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Bear Bibeault wrote:Please take the time to choose an appropriate forum for your posts. This forum is for questions on JSP. For more information, please click this link ⇒ CarefullyChooseOneForum.

This post has been moved to a more appropriate forum.


Thanks, I'm new here, sorry for mistake
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4168
    
  21

SO it looks like you are running JSPs, which run in a ServletEngine of some sort. The ServletEngine is probably providing its own JRE (actually, probably part of a JDK since it needs to compile the JSPs), and not using the default system version of Java.

What you need to do is look through your server's documents and confirm:
1) What version of Java it is compatible with
2) If the JDK it uses to execute/compile in can be changed


Steve
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Campbell Ritchie wrote:If you look in the API documentation for String#split(java.lang.String), look at the last but one entry, where it says "Since: 1.4". That demonstrates the method was not available in Java 1.3. You can do the same for isEmpty.

I don't know why you appear to be using a 1.3 version of String. Sorry. Please search your PC for copies of rt.jar and similar standard Java installation files. There might be an old one that has crept in somewhere. Also check your PATH that you haven't let an old version slip in. Also try javac -version on your newer PC.


I do not use Java 1.3. I use Java 1.6. I'm sorry, if it was not clear. I never used 1.3 - my oldest version is 1.4; my current version is 1.6; the method split doesn't work on 1.6.

Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4168
    
  21

The server you are using is not using Java 6. The split() method DOES work in Java 6. Please double check the version of java that your server is using.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Steve Luke wrote:SO it looks like you are running JSPs, which run in a ServletEngine of some sort. The ServletEngine is probably providing its own JRE (actually, probably part of a JDK since it needs to compile the JSPs), and not using the default system version of Java.

What you need to do is look through your server's documents and confirm:
1) What version of Java it is compatible with
2) If the JDK it uses to execute/compile in can be changed



Thanks! exactly, this is JSP with servlet code. But I don't understand where it could take old JRE since this is absolutely new computer with Java 1.6 installed; older versions were never installed there.

1) my server is Tomcat 6, it is compatible with Java 1.6
2) there is no uses to jdk; since I use this code in jsp I define uses as < %@ page import="java.io.*" % > without version indication.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Steve Luke wrote:The server you are using is not using Java 6. The split() method DOES work in Java 6. Please double check the version of java that your server is using.


Steve, I understand that something is wrong with the version :) but don't understand - what...

My server works on with the following Java version:

C:\Documents and Settings\julia>java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)

Version 1.3 (the last version without split method) was never installed on my environment...
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4168
    
  21

Julia Shreiber wrote:
Steve Luke wrote:The server you are using is not using Java 6. The split() method DOES work in Java 6. Please double check the version of java that your server is using.


Steve, I understand that something is wrong with the version :) but don't understand - what...

My server works on with the following Java version:

C:\Documents and Settings\julia>java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)
.


That is the version of java installed on the computer. You have a Server which you are running your JSP from. That Server may have a DIFFERENT version of Java embedded in it. It probably has NOTHING to do with the version of Java you installed on the computer, and has EVERYTHING to do with the version of the JSP server you are running.

What Servlet Enginge (JSP Server) are you running?
What version of that Servlet Engine?
What version of Java does that Servlet Engine support?
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4168
    
  21

First, Sorry I missed your previous email where you stated the server and version...

Julia Shreiber wrote:1) my server is Tomcat 6, it is compatible with Java 1.6
2) there is no uses to jdk; since I use this code in jsp I define uses as < %@ page import="java.io.*" % > without version indication.


1) What version of Java does Tomcat 6 ship with? It does ship with a version... you will have to research it.
2) Incorrect. There is a JDK. JSPs get first translated into normal java code, then compiled into Java byte code. There is a JDK involved or there could be no compiling. I know you don't compile the code - the server does. The JDK was likely shipped with Tomcat 6, look up docs to find out how to tell what version (been a while, but I think it comes with a version of the Eclipse JDK... and there is a way to configure it...).

<edit>
And you can also check the startup parameters for the Server. There are a few different config files to check as well. Take a look at them and see if any of them provide a target version for compiling code to. It could be Tomcat 6 comes with Java 5/6 support but is targeting Java 1.3 for some reason.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Steve, thank you for your time! I'm sorry for such stupid question and stupid answers for your questions - I'm not java programmer at all



Steve Luke wrote:1) What version of Java does Tomcat 6 ship with? It does ship with a version... you will have to research it.


Is this the answer? (this is Tomcat workspace)


Steve Luke wrote:
Julia Shreiber wrote:
2) there is no uses to jdk; since I use this code in jsp I define uses as < %@ page import="java.io.*" % > without version indication.

2) Incorrect. There is a JDK. JSPs get first translated into normal java code, then compiled into Java byte code. There is a JDK involved or there could be no compiling. I know you don't compile the code - the server does. The JDK was likely shipped with Tomcat 6, look up docs to find out how to tell what version (been a while, but I think it comes with a version of the Eclipse JDK... and there is a way to configure it...).

I don't know where it takes libs exactly (I guess here: C:\Program Files\Java\jdk1.6.0_21\jre\lib) but there is now way to take 1.3 version somewhere: I never installed it. This code works well some years with 1.4, so even if it has wrong JDK it should be 1.4.

Steve Luke wrote:
And you can also check the startup parameters for the Server. There are a few different config files to check as well. Take a look at them and see if any of them provide a target version for compiling code to. It could be Tomcat 6 comes with Java 5/6 support but is targeting Java 1.3 for some reason.


I checked server.xml and web.xml - there is no indication of Java version.

Maybe just this one?
< Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

but I changed it to
< Connector className="org.apache.catalina.connector.http10.HttpConnector"
port="8084" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="10" debug="0" />


- it doesn't help.

Sorry again, I'm with it from yesterday, very strange issue...

Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4168
    
  21

Julia Shreiber wrote:
Steve Luke wrote:1) What version of Java does Tomcat 6 ship with? It does ship with a version... you will have to research it.


Is this the answer? (this is Tomcat workspace)



Nope, that would be the Java version Eclipse uses. Tomcat may have its own settings. If you are only launching Tomcat via an Eclipse plugin then there is probably some configuration inside the Eclipse IDE for setting java versions and the like. You will have to dig around some more...

Julia Shreiber wrote:
I don't know where it takes libs exactly (I guess here: C:\Program Files\Java\jdk1.6.0_21\jre\lib)


I would look inside the directories where Tomcat is installed. But more importantly you should look through the configuration files. If you don't see anything specific, look online for the Tomcat configuration docs to see what options are available, where they are located, and what the defaults are.
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

may be here




[Thumbnail for eclipse_server.JPG]

Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Steve, thank you!

The only indication for version 1.3 I found in Tomcat/common directory (ant.jar, tools.jar, servlet.jar etc) - this collection is really old. But it works well on Java 1.4.

All other attempts (search in xml-s etc) return nothing. No version indication, no jdk, nothing.

that would be the Java version Eclipse uses


Tomcat is compiled with jre6 and is running on PC with jre6 - does it mean that it still could use another version?

I'm keep trying, I see direction now. Thank you!
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Seetharaman,

Is it eclipse environment? My Tomcat runs as Windows service, I don't see where I can jre version there...
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Have you installed anything from Oracle? What's your path?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38100
    
  22
I think this thread is now too difficult for "beginning" and I ought to move it.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
David Newton wrote:Have you installed anything from Oracle? What's your path?


I don't use Oracle software, there is no Oracle in my PATH value...
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

I mean the path used by Tomcat. There's obviously an installation of a 1.3 JRE *somewhere*.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
David Newton wrote:I mean the path used by Tomcat. There's obviously an installation of a 1.3 JRE *somewhere*.


This is absolutely new clear PC, I installed Java 1.6 on it, then compiled my old (previously compiled on 1.4 and never on 1.3) Tomcat code with JRE6. There is no 1.3 and never was - this code is very old "Legacy" but the first version was created on 1.4.

I understand that is is unbelievable...
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

It's not just unbelievable; it's not really possible.

But I'm also suspicious of the claim that String.isEmpty worked pre-1.6, since that method was introduced in Java 1.6:

http://download.oracle.com/javase/1.4.2/docs/api/java/lang/String.html
http://download-llnw.oracle.com/javase/6/docs/api/java/lang/String.html#isEmpty()

Maybe explain that claim first.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
David Newton wrote:It's not just unbelievable; it's not really possible.


I know...

David Newton wrote:But I'm also suspicious of the claim that String.isEmpty worked pre-1.6, since that method was introduced in Java 1.6:


No, it was not worked in 1.4 - this code I added in 1.6. I've not checked it in 1.4.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

If you're running Tomcat under the IDE, I'll move this thread to IDEs.

The bottom line is that whatever is compiling the JSPs simply isn't using 1.6, no matter what you *think* it's using. If it's an Eclipse issue, it's better handled in the IDE forum.

Have you tried deploying the war to Tomcat and running Tomcat manually? (After clearing out any work directories?)
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 9962
    
163

Under <TOMCAT HOME>/conf folder, you will find a (global) web.xml file which controls the target version of the class compiled out of JSP:



Read the comments on "compilerTargetVM". Have you made any changes in that file?


[My Blog] [JavaRanch Journal]
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Jaikiran Pai wrote:Read the comments on "compilerTargetVM". Have you made any changes in that file?


I've not changed web.xml, only server.xml.

Comment about compilerSourceVM says: Compiler Source VM. [1.5]
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
David Newton wrote:
Have you tried deploying the war to Tomcat and running Tomcat manually? (After clearing out any work directories?)


What is the "war"? (sorry...) I'm running it as service.

Thank you for finding right place for my thread.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

The war file is the web application packaged as a war file.

I'm asking you to deploy to Tomcat *not* as a service and run it from the command line.

If you're running Tomcat as a service you need to check to see where it's getting its JRE from, because it's not using 1.6.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
I tried to run it from command line, there were some warning including one saying:

INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Tomcat\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Java\jre6\lib

I guess it means Tomcat looks for libs here: C:\Program Files\Java\jre6\lib - Java 6.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

When younrun it from the command line, sure. I was asking if there were any app errors.i
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19656
    
  18

I'm moving this thread to our Tomcat forum.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

OK, been a whole lot of sound and fury here, lots of people running off in all sorts of directions. Time for me to come in and straighten it all out.

If you run Tomcat from the command line, you have to supply it with a JDK. Specifically a JDK and not a JRE, because the java compiler is used by the jasper subsystem to compile JSPs into executable classes. That's in the process of changing, but I don't think that it has taken effect as of the latest Tomcat6 release.

Regardless, Tomcat is a Java Application, so it has to run under some sort of JVM.

Tomcat doesn't care how many JDK's and JRE's you have installed on your computer. The one that it runs under is the one you select by setting the JAVA_HOME environment variable. Actually, there's also a JRE_HOME, but usually they'll end up set to the same thing. Main difference has to do with debugging, which (jasper improvements or not) requires a JDK, not a JRE.

JAVA_HOME can be defined in a setenv script or from the command line. If neither is done, the current OS PATH will be used to locate an executable JAVA. There's all sorts of rules and options, and for details, I recommend you RTFM and/or the TOMCAT_HOME/bin scripts, because I can't remember them all myself. Usually having a defined JAVA_HOME is all I care about.

Once the version of Java has been sorted out, everything else flows from there. The DLLs/so's, the location of the juli logging files, encryption config, even GUI fonts, all that stuff descends from the "JAVA_HOME" according to the same rules as any other Java Application. I think there may be an option to use an alternate JVM for compiling JSPs, but I wouldn't normally use it, since the resulting classes might not be version-compatible with the JVM that actually runs them ($JAVA_HOME/bin/java).

OK. The point of all that is simply to have said that there's no Black Art to determining which version of Java Tomcat's running under and where it finds resources. It's all predictable and controllable according to well-defined rules.

Now for the actual problem.

The String split() method has been around a while and no recent vintage of Tomcat can run under a JDK (much less JRE) that's older than the split method. Therefore, I pose this simple question:

Is that really the java.lang.String class?

The error message isn't including a fully-qualified classname. Or if it is, it's definitely not referring to java.lang.String, but instead to a class named "String" in the default package.

Something worth verifying. You can go totally crazy trying to figure out why the standard class method isn't honored, but if you're actually not using that class, it won't help!


Customer surveys are for companies who didn't pay proper attention to begin with.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Tim, thank you for such deep investigation!


Tim Holloway wrote:
Tomcat doesn't care how many JDK's and JRE's you have installed on your computer. The one that it runs under is the one you select by setting the JAVA_HOME environment variable. Actually, there's also a JRE_HOME, but usually they'll end up set to the same thing. Main difference has to do with debugging, which (jasper improvements or not) requires a JDK, not a JRE.

JAVA_HOME can be defined in a setenv script or from the command line. If neither is done, the current OS PATH will be used to locate an executable JAVA. There's all sorts of rules and options, and for details, I recommend you RTFM and/or the TOMCAT_HOME/bin scripts, because I can't remember them all myself. Usually having a defined JAVA_HOME is all I care about.

Once the version of Java has been sorted out, everything else flows from there. The DLLs/so's, the location of the juli logging files, encryption config, even GUI fonts, all that stuff descends from the "JAVA_HOME" according to the same rules as any other Java Application. I think there may be an option to use an alternate JVM for compiling JSPs, but I wouldn't normally use it, since the resulting classes might not be version-compatible with the JVM that actually runs them ($JAVA_HOME/bin/java).

OK. The point of all that is simply to have said that there's no Black Art to determining which version of Java Tomcat's running under and where it finds resources. It's all predictable and controllable according to well-defined rules.

Now for the actual problem.

The String split() method has been around a while and no recent vintage of Tomcat can run under a JDK (much less JRE) that's older than the split method. Therefore, I pose this simple question:

Is that really the java.lang.String class?

The error message isn't including a fully-qualified classname. Or if it is, it's definitely not referring to java.lang.String, but instead to a class named "String" in the default package.

Something worth verifying. You can go totally crazy trying to figure out why the standard class method isn't honored, but if you're actually not using that class, it won't help!


First, I defined my String variable as java.lang.String - in order to be sure that class is really java.lang.String. There is no change, the same error message is shown.

Second... I found java.exe in C:/Windows/System32 folder, is it right place? According to date, this file is here from java 1.6 installation; also I found there only deploy.Java1.dll, javaw.exe and javaws.exe. I defined environment variables: JAVA_HOME as C:/Windows/System32 and JRE_HOME as C:/Program Files/Java/jre6/bin (are they right? sorry for stupid questions, I'm really working with Tomcat second time in my life, first time was very small issue some years ago.) There is no change detected, Tomcat commonly still running well, error message still appears on each page when string.split() is used.

Also, I've checked again and again - there are no JRE's on my computer, only one jre6.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

Something sounds funny here.

A proper installation would have something like "C:\Program Files\Java\jdk1.6_18" and the java.exe would be in its bin subdirectory.

JAVA_HOME points to the installation. So typically, you'd do something like this:


I use the raw tomcat script, but that's just habit.

If you actually do have java.exe directly under Program Files, that's rather odd. Best I can figure out is that it might be a web browser's java. If you DON'T have something like what I illustrated above, go directly to java.sun.com or whatever Oracle mangled it to and download and install an actual official "Sun" jdk.

And it it gives you a choice, don't install it under "Program Files" or any other directory that has blank spaces in its name. That's trouble enough in any case!
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

I think the normal installer drops a JRE executable into the Windows directory.

There *IS* a non-1.6 executable: that is the *only* way you can see the errors you're seeing.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
David,
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

David Newton wrote:I think the normal installer drops a JRE executable into the Windows directory.

There *IS* a non-1.6 executable: that is the *only* way you can see the errors you're seeing.


"Normal" is a bit of a stretch when it comes to Tomcat installers for Windows. There seem to be about 3 of them, each with their own private set of woes. The actual Tomcat distribution itself doesn't come with a JDK or JRE, so those of us in penguin-land are free to get into trouble all by ourselves.

You can get serious class problems without running the wrong JRE as long as your JVM libraries are sufficiently scrambled. Although usually it starts objecting to java.lang.Object and works its way out from there.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Tim Holloway wrote:"Normal" is a bit of a stretch when it comes to Tomcat installers for Windows.

Normal *Java* installer, not Tomcat.
Julia Shreiber
Greenhorn

Joined: Sep 12, 2010
Posts: 28
Tim Holloway wrote:Something sounds funny here.

A proper installation would have something like "C:\Program Files\Java\jdk1.6_18" and the java.exe would be in its bin subdirectory.

JAVA_HOME points to the installation. So typically, you'd do something like this:


I use the raw tomcat script, but that's just habit.

If you actually do have java.exe directly under Program Files, that's rather odd. Best I can figure out is that it might be a web browser's java. If you DON'T have something like what I illustrated above, go directly to java.sun.com or whatever Oracle mangled it to and download and install an actual official "Sun" jdk.

And it it gives you a choice, don't install it under "Program Files" or any other directory that has blank spaces in its name. That's trouble enough in any case!


I set JAVA_HOME as C:\Program Files\Java\jdk1.6_21 now - no changes, error still appears; my JDK is downloaded from java.sun.com some days ago... Previously I worked with JRE but when the problem was found installed also JDK.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

David Newton wrote:
Tim Holloway wrote:"Normal" is a bit of a stretch when it comes to Tomcat installers for Windows.

Normal *Java* installer, not Tomcat.


Apparently not. I just checked my XP box. It has 2 JDKs and 2 JREs in PROGRAM FILES\Java, but no ".EXE" files from anyone in Program Files itself.

But I stick by my earlier advice. Better to explicitly download and install a known good JDK than to try and make sense of what's apparently a broken system. Then set JAVA_HOME and run the catlalina.bat file so that the runtime environment is a known good setup. From there it should be possible to work towards the fancier stuff.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: String class can't find split method: wrong java version?
 
Similar Threads
How to find the jdk version
B&S I Built My Project In 1.5, But It Bombs In1.4.2. Is This OK?
List of Online Practice Tests - For IBM 484 & 486
ArrayList:
UnsupportedClassVersionError