Problem compiling with IVParameterSpec

I'm trying to build a password file that will be created by one program and read by a different one using CipherInput/OutputStreams. I believe that I need a repeatable key so that as I write the file, I can also read it.
I'm trying to use cipher.init (Cipher.ENCRYPT_MODE, key, ivSpec) with ivSpec set to the same array of bytes in both my read and write routines. When I try to compile the write class, I get an error at my import statement for the IVParameterSpec.
Line 78: import javax.crypto.spec.IVParameterSpec;Error:
[javac] C:\rat\jtim\src\com\baesystems\jtim\RemotePassword.java:78: cannot resolve symbol
[javac] symbol : class IVParameterSpec
[javac] location: package spec
[javac] import javax.crypto.spec.IVParameterSpec;
Do I need to load something else into the JDK to get IVParameterSpec? What could I be doing wrong?

just a spelling mistake.
javax.crypto.spec.IvParameterSpecThe "v" in Iv is the small V, not the capital V.
Thanks. You'd think after 15 years of Unix, I'd be able to catch a case error.

Similar Messages

Problems compiling with packages

Hi,
I wonder if anyone could help me.
I have had problems compiling using a package. I have altered the classpath in autoexec.bat with:
SET CLASSPATH=%classpath%;C:\jdk1.3.1_02\classes;.
the package class files are stored in C:\jdk1.3.1_02\classes\helliker\id3
and I have imported the class with:
import helliker.id3.*;
I am getting the following error:
C:\My Documents\Uni work\mp3 project\test\Driver.java:1: package helliker.id3 does not exist
import helliker.id3.*;
^
Can anybody help?
Thanks,
Dave

Perhaps the version of Windows you are using does not use autoexec.bat. For example, in NT and XP, you set Classpath using ControlPanel/System/Advanced/Environment Variables.
Perhaps there is a typo in your Classpath, for example an extra space.
On a command line, try this:
javac -classpath C:\jdk1.3.1_02\classes C:\My Documents\Uni work\mp3 project\test\Driver.java
If that works, then definitely Classpath is not set as you think it is.

Problem compiling with Swing

I am new to java.
I have recently installed jdk-1.3.1_01 and am able to compile and run basic java programs. However, when trying to compile HelloWorldSwing.java, I get the following error:
HelloWorldSwing.java:6: error:Cannot find class "JFrame" [JLS 8]
Is this a classpath problem? Please help!

yes, I'm sure the code is right. What is strange is that when I first installed jdk, I was able to compile and run the swing program. Once I closed the terminal, though, and opened a new one, I was unable to compile. I'm using Linux Mandrake 8.1. Any ideas?

Problem compiling with a final static statement

I'm trying to compile a code that i obtained from jad. The error is:
MethodInvoke.java:269: illegal start of type
^
At the final of the code i got:
static final
{ //here appear the problem
try
pool = new ObjectPool(com.test.wsp.main.MethodInvoke.class);
catch(Exception exception)
throw new ExceptionInInitializerError("could not initialize the worker pool, exception=" + com.tess.hometop.gateways
.utils.Utils.parse(exception));
Could anyone explain me which is the problem?
Thanks

I'm trying to compile a code that i obtained from jad. The error is:
MethodInvoke.java:269: illegal start of type
^
At the final of the code i got:
static final
{ //here appear the problem
try
pool = new ObjectPool(com.test.wsp.main.MethodInvoke.class);
catch(Exception exception)
throw new ExceptionInInitializerError("could not initialize the worker pool, exception=" + com.tess.hometop.gateways
.utils.Utils.parse(exception));
Could anyone explain me which is the problem?
Thanks

SUNWspro iostream error while compiling with SunStudio 10

We are getting the following error when we try to compile the C++ code using SunStudio 10 on Sun Solaris Sparc server.
We made couple of changes in the source code 1) whereever we have stream.h we replaced it with iostream.h and 2) include fstream.h whereever required.
Can anyone tell us where did it go wrong.
+ /opt/SUNWspro/bin/CC -g -O -DHAWK -mt -lclntsh -lsocket -lnsl -I/export/home/StandardComponents/SC/include -I../../mylib -I../../include -I/opt/SUNWspro/prod/include/CC/Cstd -I. -I- -D_TRACE_ -c collectDborMtoInfo.c
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: Use ";" to terminate declarations.
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: A declaration was expected instead of "'\n'".
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: Use ";" to terminate declarations.
"/opt/SUNWspro/prod/include/CC/Cstd/iostream.h", line 20: Error: A declaration was expected instead of "'\n'".
4 Error(s) detected.

Remove the -I directive that points into the compiler installation. You should not have have -I or -L options that point into the compiler installation area, into /usr/include, or into /usr/lib. The CC compiler driver knows where to find system headers and libraries, and in what order to search the directories. If you force a different search order, you can break something.
If removing -I/opt/SUNWspro/prod/include/CC/Cstd does not fix the problem, compiling with -P or -E will show you the preprocessor output, and looking at the lines with the errors will usually show the source of the problem quickly.
BTW, you should be aware that the ".h" form of the C++ headers, like <iostream.h> and <fstream.h>, is not standard. Using them is not portable, because not all C++ implementations provide them, and those that do often have different content.

Problem in compiling with -g option

I am using forte5.1 compiler. While compiling my whole source code with -g option, for some of the files, the compilation is successfully but for some files I am getting en error as ">> Assertion (../link/dbg_stcomm.cc, line 271) while processing srsCallbacks.C at line 0. Error code 1. make:Fatal error". If I try to compile the whole source code without -g option my whole compilation is successfull. I have downloaded all the required patches for this. Previously I was using compiler 5.0 and I was not getting any error with -g option. Can u just tell me why am I facing this problem specifically with forte5.1 and not with 5.0. How can I resolve this problem so as to compile the whole source code with -g option?

Hi,
I think you will need patch:
Patch-ID# 109490-01
Synopsis: C++ 5.1: Patch for Forte Development 6 C++ compiler
As it appears that you are hitting bug id # 4312608
"Assertion: (../links/dbg_stcomm.cc, line 271)"
Can you confirm whether you are having this patch by doing:
"CC -V" or "showrev -p"
Thanks,
Gopinath.
Sun - DTS.

Having problems compiling *.java with import javax.servlet.jsp......

I've been trying to do the tutorials in a book titled Apache Jakarta-Tomcat as part of my introduction to JSP. I'm new to Java but do know the basics. I have on my machine Java 1.3, Java 1.4, Java FrameWorks 2.1 and Jython 2.1 on Win2000 Pro. So enough about my configuration. I have never worked with packages also.
I downloaded the files from the books site due to the fact I make a lot of typos when hand coding Java (I've become a pretty good debugger of my own code). But everytime I go to compile the *.java I get error messages. So below you will find HelloTag.java and beneath that the error messages that are thrown when I try and compile it. I tested other bits of *.java and have had no problem compiling them. Is there a JSP module I'm missing?
Am I doing something wrong or am I missing something from my configuration.
Marijan Madunic
package chapter2;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspTagException;
import javax.servlet.jsp.tagext.TagSupport;
public class HelloTag extends TagSupport
public void HelloTag() {
// Method called when the closing hello tag is encountered
public int doEndTag() throws JspException {
try {
// We use the pageContext to get a Writer
// We then print the text string Hello
pageContext.getOut().print("Hello");
catch (Exception e) {
throw new JspTagException(e.getMessage());
// We want to return SKIP_BODY because this Tag does not support
// a Tag Body
return SKIP_BODY;
public void release() {
// Call the parent's release to release any resources
// used by the parent tag.
// This is just good practice for when you start creating
// hierarchies of tags.
super.release();
D:\Java\JDK 1.3\bin>javac HelloTag.java
HelloTag.java:3: cannot resolve symbol
symbol : class JspException
location: package jsp
import javax.servlet.jsp.JspException;
^
HelloTag.java:4: cannot resolve symbol
symbol : class JspTagException
location: package jsp
import javax.servlet.jsp.JspTagException;
^
HelloTag.java:5: cannot resolve symbol
symbol : class TagSupport
location: package tagext
import javax.servlet.jsp.tagext.TagSupport;
^
HelloTag.java:7: cannot resolve symbol
symbol : class TagSupport
location: class chapter2.HelloTag
public class HelloTag extends TagSupport
^
HelloTag.java:14: cannot resolve symbol
symbol : class JspException
location: class chapter2.HelloTag
public int doEndTag() throws JspException {
^
HelloTag.java:20: cannot resolve symbol
symbol : variable pageContext
location: class chapter2.HelloTag
pageContext.getOut().print("Hello");
^
HelloTag.java:24: cannot resolve symbol
symbol : class JspTagException
location: class chapter2.HelloTag
throw new JspTagException(e.getMessage());
^
HelloTag.java:28: cannot resolve symbol
symbol : variable SKIP_BODY
location: class chapter2.HelloTag
return SKIP_BODY;
^
HelloTag.java:37: cannot resolve symbol
symbol : variable super
location: class chapter2.HelloTag
super.release();
^
9 errors

Well, it looks like you've not got the servlet development kit JAR on your classpath. I think it'll probably be called servlet.jar on your system. Add that to the classpath if it's not already there.
Incidentally, you've bumped into one of the areas Java's slightly lenient - declaring a method that looks like a constructor:
public HelloTag() { }
public void HelloTag() { }The first is a constructor, the second is a normal method. I'm assuming you intended to have the former instead of the latter.
Anyway, hope this helps.

Problem in compile with JDeveloper

Compile with JDeveloper failded if the class didn't implement the abstract method of it's super abstract class. But it is ok wiht other IDE(VisualCafe, Eclipse, JBuilder...).
It seems that JDeveloper is more strict than other IDEs.
Anyone can tell me how to avoid this error? TIA.

I've found out the reason.
JDeveloper will try to compile all the source files the project used even they're not added into the project.
I have ClassA extend abstract ClassB, and ClassB extend abstract ClassC and implement the abstract methods of ClassC, they can all be compiled. And then I got a wrong source file of classB which didn't has the methods. Maybe I've kept this wrong source file for a long time but didn't get any trouble until I began to use JDeveloper and got the error.
Since I didn't add ClassB into the project and classB.class didn't changed. So I didn't noticed that a wrong source file caused the problem.
Thank you! :-)

Codepage problem when compiling with fastjavac

Hi,
I'm getting the following warnings when compiling with fastjavac:
fastjavac: warning: Can't find codepage for "Cp1250" encoding.
fastjavac: warning: Use default ANSI codepage.
2 warnings
How could I suppress these warnings?
Thanks in advance

I think you are posting it on the wrong Forum. This is for Forte 4GL not Forte for Java.

Bug report: ube_ipa: internal error when compiling with -xO5

When compiling imlib2-1.1.2, one source file causes compilation to fail with the following error message:
ube_ipa: internal error
cc: ube_ipa failed for loader_tiff.c
The command which fails is (probably wrapped):
cc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -I../src -I../loaders -I../libltdl -I/usr/X11R6/include -I/usr/openwin/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -g -fast -xarch=386 -xstrconst -v -xildoff -xO5 -c loader_tiff.c -KPIC -DPIC -o .libs/loader_tiff.o
Changing -xO5 to -xO4 works around the problem. The source file in question is imlib2-1.1.2/loaders/loader_tiff.c
Patch 112756-10 has been applied, and doesn't correct the problem. GCC doesn't have any problem compiling the file.
A quick note to any Sun employees reading this: it took me 45 minutes to find somewhere to submit this bug report. Searching sun.com for "submit bug report" turned up many forum postings where people asked "Where do I submit bug reports?", a bug report form for Sun One Java Studio, and not much else. It might be in your interest to make submitting bugs easier.

Internal errors, such as the one you encountered, are generally considered compiler bugs. They indicate that the compiler reached an unexpected state and therefore bailed out. I opened bug 20703141: internal error: pic_relocs(): hh reltype? to investigate. I see the same error message emitted by the current Studio development release; I will update this thread if I find a work-around.
Thanks,
Mark

Problem compiling source file in package

Hi, I have 5 source files which I have just packaged together and put in the same sub-directory, the problem is that when I try to compile the file with the main method I get the error message:"cannot read" then the name of the source file. I am compiling from the command line and setting the classpath as I compile with the statement:
c:\j2sdk1.4.1\bin>javac -classpath c:\directory\package directory source file.java
I'm not sure what I am doing wrong and the source files all compiled fine before I added the package statement to the files. Please any help would really be appreciated.

It sounds like the java file your are trying to compile is not in the directory you are compiling from.
Is this basically what you are doing?:
Say the package name is mypackage.
Assume we are O.K. with keeping source and class files together.
Create a directory named 'mypackage' somewhere...C:\mypackage\.
Put all the .java files in it (these .java files indicate that they are a member of the 'mypackage' package).
At a command prompt, cd to the directory containing the 'mypackage' directory...'cd C:\'
Compile the source files: C:\j2sdk1.4.1\bin\javac mypackage\*.java
run the main class: C:\j2sdk1.4.1\bin\java mypackage.TheMainClass
Basically, this says keep the files where you want them and point to javac, instead of moving everything under java/bin. btw it will save a lot of typing if you add java/bin to your PATH.
Hope this helps.

Java 6u24 won't launch signed JNLP app with classes compiled with JDK 1.4.2

Anyone else having a problem launching a JNLP app compiled with Java 1.4 using Java 6u24 on the client? Anyone have a Java 1.4-compiled app that does launch with Java 6u24?
I am, and I have isolated the problem to some change in 6u24's java web start launching logic. The splash screen appears and then javaws just quits with no error. Trace shows it is not getting past checking of the first .jar. My JNLP app, fully signed with CA-issued certificate, when compiled with Java 1.4.2 will not launch on JRE 6u24 (or 6u25-b03). The same exact app launches perfectly fine when it is compiled with JDK 1.5 or 1.6. It is not a signing problem, though it is related to certificate checking logic or a concurrency flaw in javaws' AppPolicy and TrustDecider classes. It is not a host server or network problem as those have been varied with same results. It is not a specific .jar problem as I have varied what is the first .jar with same results. I have eliminated all other variables to find the only difference is what Java version the app is compiled with. Well, all but one other variable - I have not tried with apps other than mine.
My app is compiled with JDK 1.4.2 so I can still support older platforms. That requirement is going away soon but this is still a regression from 6u23 that is causing a big problem for at least this developer.

You can try to use the version of the jarsigner JDK 1.5 or later.
Has changed the management of files in META-INF.
So compile with 1.4 but sign with 1.5 or later

Help!Apache compiling with gcc in Solaris 10

Greetings
I am having problems with Apache 1.3.
When I am running the script ./src/Configure my output is:
#./Configure
Using config file: Configuration
Creating Makefile
+ configured for Solaris 2100 platform
+ setting C pre-processor to gcc -E
+ using "tr [a-z] [A-Z]" to uppercase
+ checking for system header files
+ adding selected modules
./helpers/TestCompile: make: not found
+ using builtin Expat
./Configure: make: not found
+ checking sizeof various data types
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
./helpers/TestCompile: make: not found
+ doing sanity check on compiler and options
./helpers/TestCompile: make: not found
** A test compilation with your Makefile configuration
** failed. The below error output from the compilation
** test will give you an idea what is failing. Note that
** Apache requires an ANSI C Compiler, such as gcc.
======== Error Output for sanity check ========
./helpers/TestCompile: make: not found
============= End of Error Report =============
Aborting!
I am root, my PATH is
/usr/bin:/usr/ucb:/etc:/usr/local/bin:/opt/netscape:/usr/css/bin/:/bin:/usr/openwin/bin:/usr/sbin:/
I am missing something stupid, I know but I can't find it!!!!Help please I am a newbie.
I am curious. Has anyone been able to compile succesfully apache server with gcc in Solaris 10?
Thanks,

Thanks,
It was only that.!!!
But now I have the following problem, I can't create executables when I type make. The output is:
when I am in the src/folder
#make
===> regex
<=== regex
===> os/unix
gcc -c -I../../os/unix -I../../include -DSOLARIS2=2100 -DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED os.c
In file included from /usr/include/sys/wait.h:24,
from ../../include/ap_config.h:1079,
from os.c:21:
/usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:292: error: parse error before '}' token
/usr/include/sys/siginfo.h:294: error: parse error before '}' token
/usr/include/sys/siginfo.h:390: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:392: error: conflicting types for `__proc'
/usr/include/sys/siginfo.h:261: error: previous declaration of `__proc'
/usr/include/sys/siginfo.h:398: error: conflicting types for `__fault'
/usr/include/sys/siginfo.h:267: error: previous declaration of `__fault'
/usr/include/sys/siginfo.h:404: error: conflicting types for `__file'
/usr/include/sys/siginfo.h:273: error: previous declaration of `__file'
/usr/include/sys/siginfo.h:420: error: conflicting types for `__prof'
/usr/include/sys/siginfo.h:287: error: previous declaration of `__prof'
/usr/include/sys/siginfo.h:424: error: conflicting types for `__rctl'
/usr/include/sys/siginfo.h:291: error: previous declaration of `__rctl'
/usr/include/sys/siginfo.h:426: error: parse error before '}' token
/usr/include/sys/siginfo.h:428: error: parse error before '}' token
/usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t"
/usr/include/sys/siginfo.h:437: error: parse error before '}' token
In file included from /usr/include/sys/procset.h:24,
from /usr/include/sys/wait.h:25,
from ../../include/ap_config.h:1079,
from os.c:21:
/usr/include/sys/signal.h:85: error: parse error before "siginfo_t"
In file included from ../../include/ap_config.h:1079,
from os.c:21:
/usr/include/sys/wait.h:86: error: parse error before "siginfo_t"
In file included from ../../include/ap_config.h:1096,
from os.c:21:
/usr/include/signal.h:111: error: parse error before "siginfo_t"
/usr/include/signal.h:113: error: parse error before "siginfo_t"
*** Error code 1
make: Fatal error: Command failed for target `os.o'
Current working directory /web-download/apache_1.3.33/src/os/unix
*** Error code 1
The following command caused the error:
for i in regex os/unix ap main lib modules; do \
echo "===> $i"; \
case ".Solaris 2100" in \
.OS390 | .TPF) ( cd $i && make SDP='' OPTIM='') || exit 1;; \
*) ( cd $i && make SDP='' CC='gcc' AUX_CFLAGS=' -DSOLARIS2=2100 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED ' RANLIB='ranlib' OPTIM='') || exit 1;; \
esac; \
echo "<=== $i"; \
done
make: Fatal error: Command failed for target `subdirs'
but when I am typing one step up is.
===> src
===> src/regex
<=== src/regex
===> src/os/unix
gcc -c -I../../os/unix -I../../include -DSOLARIS2=2100 -DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED os.c
In file included from /usr/include/sys/wait.h:24,
from ../../include/ap_config.h:1079,
from os.c:21:
/usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:292: error: parse error before '}' token
/usr/include/sys/siginfo.h:294: error: parse error before '}' token
/usr/include/sys/siginfo.h:390: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:392: error: conflicting types for `__proc'
/usr/include/sys/siginfo.h:261: error: previous declaration of `__proc'
/usr/include/sys/siginfo.h:398: error: conflicting types for `__fault'
/usr/include/sys/siginfo.h:267: error: previous declaration of `__fault'
/usr/include/sys/siginfo.h:404: error: conflicting types for `__file'
/usr/include/sys/siginfo.h:273: error: previous declaration of `__file'
/usr/include/sys/siginfo.h:420: error: conflicting types for `__prof'
/usr/include/sys/siginfo.h:287: error: previous declaration of `__prof'
/usr/include/sys/siginfo.h:424: error: conflicting types for `__rctl'
/usr/include/sys/siginfo.h:291: error: previous declaration of `__rctl'
/usr/include/sys/siginfo.h:426: error: parse error before '}' token
/usr/include/sys/siginfo.h:428: error: parse error before '}' token
/usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t"
/usr/include/sys/siginfo.h:437: error: parse error before '}' token
In file included from /usr/include/sys/procset.h:24,
from /usr/include/sys/wait.h:25,
from ../../include/ap_config.h:1079,
from os.c:21:
/usr/include/sys/signal.h:85: error: parse error before "siginfo_t"
In file included from ../../include/ap_config.h:1079,
from os.c:21:
/usr/include/sys/wait.h:86: error: parse error before "siginfo_t"
In file included from ../../include/ap_config.h:1096,
from os.c:21:
/usr/include/signal.h:111: error: parse error before "siginfo_t"
/usr/include/signal.h:113: error: parse error before "siginfo_t"
*** Error code 1
make: Fatal error: Command failed for target `os.o'
Current working directory /web-download/apache_1.3.33/src/os/unix
*** Error code 1
The following command caused the error:
for i in regex os/unix ap main lib modules; do \
echo "===> src/$i"; \
case ".Solaris 2100" in \
.OS390 | .TPF) ( cd $i && make SDP='src/' OPTIM='') || exit 1;; \
*) ( cd $i && make SDP='src/' CC='gcc' AUX_CFLAGS=' -DSOLARIS2=2100 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED ' RANLIB='ranlib' OPTIM='') || exit 1;; \
esac; \
echo "<=== src/$i"; \
done
make: Fatal error: Command failed for target `subdirs'
Current working directory /web-download/apache_1.3.33/src
*** Error code 1
The following command caused the error:
case "xi86pc-sun-solaris2.2100" in \
x*390*) C89STEPS="0xffffffff"; export C89STEPS;; \
esac; \
cd ./src; make SDP=src/ all
make: Fatal error: Command failed for target `build-std'
Current working directory /web-download/apache_1.3.33
*** Error code 1
The following command caused the error:
make -f ./Makefile root= build-std
make: Fatal error: Command failed for target `build'
I am newbie with Solaris and gcc so I have no so much idea what is missing there.
Thanks,
Juan

Compiling with Windows XP

I've just installed J2SE 1.4.0 and am having problems with the classpath. I've tried setting it as explained in the Help section on the java.sun site, however I still get the error message:
'javac' is not recognised as an internal or external command, operational program or batch file
How exactly should I go about setting the classpath and what is the format that it should take?

I have a same proplem when compiling with Windows XP.
I set
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32
Wbem;C:\j2sdk1.4.0_01\bin.Could you please tell me
more about this problem. Thanks a alot!Open a console window.
Type the following command
set
Verify that the PATH looks like what you think it does. If it doesn't fix it.
Then do this
cd C:\j2sdk1.4.0_01\bin
set PATH=.
javac -?
If you still get the same error then something is wrong with the install. Examine the bin directory. There should be a number of exe files in it including javac.

NoSuchMethodError compiling with 1.4 and running on 1.3

Hi community,
I have a little problem with code like the following when mixing both JDK versions:
StringBuffer sb1 = new StringBuffer();
sb1.append(new StringBuffer());In 1.3 this is linked to append(Object) and in 1.4 to the newly added append(StringBuffer) which does not exist in 1.3. The code compiles fine with both versions, but if compiled under 1.4 and run in 1.3 this throws NoSuchMethodError(as it should, of course).
I understand why it is so, the question is if there is an easy way to overcome this problem. I played with the target option of javac without success(javap shows it is always linked as stated), also I read a bit in the JLS to make sure I am right why the exception is thrown.
I see the following choices:
1. Compile with 1.3. Not a good idea because all other our products are developed and run in 1.4;
2. Ask the customers to upgrade to 1.4. There is some their reason for which they still stick to 1.3 and don't want to upgrade, we can't force them do it;
3. Find such places in code and explicitly cast. But who will know what other cases like the above exist in the code. I can find where append(StringBuffer) is used in the code, but what about other methods of other JDK classes? And it is a bad idea because somewhere in time it will anyway run with 1.4.
My question is if there is another easier option that I am missing at the moment.
Thanks for you time and cooperation
Mike

Why is option 1 bad? You will be able to run it in 1.4 even if you compiled it using 1.3, so I don't see the problem? It will never run in 1.3 if you can't compile it in 1.3.Because it will always be a source of errors. Always there will be someone that will not set up their project to use 1.3 for compile or will deconfigure it while working with the other projects. Besides that as I stated source compiles fine in both versions, I don't have a compiletime problem, but a runtime one.
I know this is the most reasonable option, I know what I would choose among the three listed above, I needed some confirmation if I have missed an option.
and you are correct about the target flagI only mentioned the target tag just as one of the directions of my search, we always whine for others not putting effort in their problems ;)
Thanks for opinions
Mike

Problem compiling with IVParameterSpec

Similar Messages

Maybe you are looking for