Well this is my problem: I have packages structured like that : pack1 + pack2 + pack3 + file1.java file2.java File2 has a reference in file1. I'm compiling with "ant". My problem is that class1 can't find class2. This is all I tryed: - import class2 in class1 - put class2.class in a jar and add the jar to the classpath - add the root path to the classpath - try with another simple class to test if the problem comes from my class2 but it doesn't work either
The only thing that work is to put the file2.java in a package like this: pack1 + pack2 + pack3 +... packtmp + file2.java This work but my problem is that I CAN'T MODIFY the .java file (security problem) I try with javac, jidea,... nothing work So I'm hopeless, can someone help me plz... thx
Devil's Killer, Please change your name to be compliant with JavaRanch's naming policy. It should not be obviously fictitious. Your displayed name should be 2 separate names with more than 1 letter each. We really would prefer that you use your REAL name. You can change your name: here. Thanks, Cindy
"JavaRanch, where the deer and the Certified play" - David O'Meara
This is a problem introduced in the 1.4.0 version of Java SDK. You can't import classes from the default package if you are in a sub-package. The best bet for fixing this is: If you REALLY can't change the .java file and put it in a package, go back to the 1.3.x SDK and it should work OR you could try moving class1.java into the default package as well, so that you won't have to import the class2 file. Of course this is a problem if you are making a more complicated heirarchy... Steve
Originally posted by Devil's Killer: I CAN'T MODIFY the .java file (security problem)
p.s. Why can't you modify the .java file? What kind of security problem? Is it write protected? If so there are ways to make it un-protected (OS dependent).
Joined: Feb 12, 2003
Thanks a lot Steve for the information, it works with the java 1.3....
The security problem is that the project is for another company. The class2 contains passwords that our company CAN'T know so we give them this file, they compile it and they put it in a library that we will use when the project is over. Have a nice day.... P.S.: sorry for my last nickname, Cindy I hope this one is good ;-) [ February 13, 2003: Message edited by: Javier Calvo ]
So just to satisfy the need for security through obscurity -- which is generally seen to be worse than having no security at all -- you are lumbered with a broken class? They give you a library with a Java class that ultimately knows about the passwords, so if you want you can find out what the passwords are. If they trust you not to do that, then why not trust you with a properties file with the passwords (perhaps XORed with some shared "secret key" so you can't read them by accident). If on the other hand they don't trust you, they are fooling themselves with security through obscurity and making your life miserable in the process. They would have to look into a completely different type of security infrastructure, probably using public-key cryptography. If that class implements a specific interface, or if you're willing to use reflection, it might be worth checking if Class.forName() and friends will work. I'm not at all sure though. The real problem is the arbitrary, unreasonable and ill-informed constraints you're being placed under. - Peter