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)
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)
String photoPathlist = "a,b,c";
String delimiter = ",";
String photoPathArr[] = photoPathlist.split(delimiter);
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="";
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.
Steve
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.
Steve
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
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.
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)
.
Steve
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.
Steve
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.
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...).
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.
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)
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)
Steve
that would be the Java version Eclipse uses
David Newton wrote:Have you installed anything from Oracle? What's your path?
David Newton wrote:I mean the path used by Tomcat. There's obviously an installation of a 1.3 JRE *somewhere*.
David Newton wrote:It's not just unbelievable; it's not really possible.
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:
Jaikiran Pai wrote:Read the comments on "compilerTargetVM". Have you made any changes in that file?
David Newton wrote:
Have you tried deploying the war to Tomcat and running Tomcat manually? (After clearing out any work directories?)
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
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!
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
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.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:"Normal" is a bit of a stretch when it comes to Tomcat installers for Windows.
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!
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.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Consider Paul's rocket mass heater. |