Excellent - that's good to hear :)
glenn opdycke-hansen wrote:
It may be working now. I have to check with a co-worker. The
target="1.4" may have been effective. Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additi
It may be working now. I have to check with a co-worker. The
target="1.4" may have been effective. Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
So I take it, it deleted the dirs containing class files? If so, is it
still not working?
glenn opdycke-hansen wrote:
Good idea. I am from the "scorched earth" build school and the build
script has the following before the compile:
init:
Setting project property: DSTAMP -> 20061211
Setting p
Good idea. I am from the "scorched earth" build school and the build
script has the following before the compile:
init:
Setting project property: DSTAMP -> 20061211
Setting project property: TSTAMP -> 1438
Setting project property: TODAY -> December 11 2006
[delete] Deleting directory
K:\bxnar
I'd try removing all my class files and recompiling first. Just because
you removed the JDK 1.5 - does that mean you rebuilt everything
afterward? Otherwise you will still have 1.5 compiled versions of your
class files.
glenn opdycke-hansen wrote:
ok, how could we be getting jdk 1.5 java co
ok, how could we be getting jdk 1.5 java compile?
We removed (via control panel) the 1.5 jdk. could some file be lurking
in c:\winxp or other folder?
Below are parts of the log from the build:
PATH=D:\Software\Java\j2sdk1.4.2_13\bin;D:\Software\Perl\bin\;C:\CYGWIN\bin;D:\CVSNT;D:\Perl\bin;D:\apa
You can certainly specify which JDK to use in the task.
However, that may not fix your runtime issue...if an older version of
the JDK is used to run against it...
Yes, specifying may help...
Again, you need to ensure the VM being used when running against the
compiled class is the correct
Right, I know that jdk 1.4.2 works.
I suspect that some other jdk version is creeping into the class/jar file.
I specified JAVA_HOME for the 1.4.2 jdk. I also suggested to the
developer to change the path. (I heard that that did not work)
java -version also states that 1.4.2 will be used.
Is the
Well there is your problem...the JVM you are trying to use to run (not
compile) does not support the version that was compiled.
Meaning...let's say you compiled using the JDK 1.5 but attempted to run
using the JDK 1.2.2 - you'd get the error listed.
Somehow you are compiling with a newer JDK
Replies below.
On 12/11/06, Scot P. Floess <[EMAIL PROTECTED]> wrote:
What type of exceptions are you getting?
java.lang.Exception: Error in
[ProcessDefinitions/Shared/Logging/MaskLogData.process/MaskPayload]
BW-JAVA-100030 Unable to obtain information for method
[maskElementsInPayload] from t
What type of exceptions are you getting?
If you use the class file outside the jar file...does that work?
Is your harddrive full?
glenn opdycke-hansen wrote:
We are seeing that the javac can produce an unusable .class file.
One PC will build the java source OK, but the other PC does not. The
We are seeing that the javac can produce an unusable .class file.
One PC will build the java source OK, but the other PC does not. The
resulting JAR file has a different size and there are exceptions when
the other jar is used.
We set JAVA_HOME to the jdk (1.4.2_13) on both PCs.
Has anyone seen
12 matches
Mail list logo
