Community
Participate
Working Groups
we have packages like de.innuendo.util de.innuendo.auth but not "de.innuendo" (there is no class in it; the directory exists). when writing in eclipse import de.innuendo.* everythin compiles. but the jdk1.4 compiler from sun complains Test.java:6: package de.innuendo does not exist import de.innuendo.*; ^ 1 error this problem happens if you delete classes out of a package until the package is empty. all of our development is done with eclipse but the daily build uses the JDK 1.4 compiler of sun. so it is a little annoying that eclipse don't notices it as a bug.
Kent - please double check other vendors behavior.
Take the following example with 2 files a\b\A.java & x\X.java: A.java package a.b; import a.*; public class A {} X.java package x; import a.*; public class X {} a\b\A.java never complains. x\X.java only complains if it is compiled by itself. How are you compiling your files with javac? All together or one at a time?
its an ant script. try the following: A.java package a.b; import a.*; public class A {} ==== X.java package a.c; public class X {} ==== so X.java is ok, but A.java contains the buggy import. suppose you have both package trees in different projects -client +--a +--b +--A.java -server +--a +--c +--X.java now i check out both projects to directory "c:/temp". change to directory "c:/temp" and enter set classpath= javac client/a/b/*.java server/a/c/*.java please unset the classpath so that the compiler cannot check any imports against the filesystem. now you get an error from the jdk1.4 compiler. i'm not sure that this is a bug in eclipse; it is only a difference to sun's compiler. i don't know which is the correct. to be honest: i would prefer the javac from jdk1.4 to work like eclipse :^) if you set the classpath to set classpath=c:/temp/client;c:/temp/server everything compiles. so i think the sun compiler is also not consistent. but in my script i unset the classpath to be sure not to load old classes.
The Eclipse compiler is always consistent (the example results I gave previously were with javac)... only javac reports errors sometimes depending on what it can find with: javac client/a/b/*.java server/a/c/*.java We believe the package 'a' exists because we're compiling a type defined in package a.b or a.c. Javac only seems to think it exists when it can find it on its classpath. Try this from inside the client directory: javac a/b/*.java ../server/a/c/*.java javac did not complain. To ensure you don't pick up other classes, why not tell javac to put the class files somewhere else using the -d option? Then you could set a normal class path. Or use the batch version of the Eclipse compiler instead of javac all together. ;)
nice idea to use the eclipse compiler. but our sources are part of a product which is bundled as sourcecode. the customer can and will compile it. so it should compile with jdk1.4. the easiest workaround is to remove the buggy import statement. it would be nice to get a notify from the eclipse compiler. but we realize this behaviour with our daily build which is made with jdk1.4. btw: i use the "-d" option of javac in our ant script.
Yes the easiest workaround is to remove the import but I'm missing why you cannot set the classpath in your ant script.
- i set the CP only to libraries which i need for my product but not to my own classes (compile time). this does not make sense at compile time. - i cannot optimize the build process for our company if our customers have another process which uses jdk1.4 and they have problems. - our customers use different IDE's for java development and our sources have to compile in every IDE especially when this ide uses the standard javac. but for me its ok now: now i know that i have to do a daily build with the jdk1.4 to minimize such compatibility problems.
We're not going to change our behaviour to match javac for this case. Until they clarify the spec or add a JCK test that covers this case, we going to leave our behaviour as is.
