Imported From: https://issues.scala-lang.org/browse/SI-2089?orig=1
Reporter: @paulp

@odersky said:
Can you explain under what circumstances this arises. It seems your application is looking for some class or package in com/yourkit, but since it's obfuscated, why do that?

@paulp said:
Replying to [comment:3 odersky]:

Can you explain under what circumstances this arises. It seems your application is looking for some class or package in com/yourkit, but since it's obfuscated, why do that?

That is a very good question. Apparently it's because there is an obfuscated jar yjp.jar and an unobfuscated jar yjp-controller-api-redist.jar, and somewhere in the course of upgrading yourkit my symlink ended up pointing at the wrong one. So I'm not 100% sure yet, but I think I'm back on the rails. Thanks, sorry for the misdirection.

Dominik Maehl (dominikm) said:
Hi everyone, I'm quite a newbie regarding scala but I've encountered the same problem with an obfuscated jar.

I use a library from an external company which is obfuscated (Qoppa JPDFProcess) and even if I don't directly access any of the obfuscated classes scalac still complains about a package and an object with the same name.

(fragment of pdf_preflight.scala):1: error: package pdfViewer contains object and package with same name: a
one of them needs to be removed from classpath
val p = new com.qoppa.pdfProcess.PDFDocument.PDFDocument()

So is there anything I can do? The jar works perfectly with javac. If I can help in any way I would like to, but I have no experience in compilers and such things.

And I hope its ok to hijack this bug.

@odersky said:
I don't see a way to fix this. Anybody else?

Dominik Maehl (dominikm) said:
I've tried deleting the conflicting packages/objects from the jar file while compiling. The application then runs perfectly with the full jar.

Maybe there could be a way to not parse every class file on compile? The runtime apparently is not affected by this problem.

Pavol Vaskovic (pali-at-pali.sk) said:
I have the same problem with scala 2.8.0.Beta1 and obfuscated library:

... error: package trree contains object and package with same name: b
 one of them needs to be removed from classpath
       val sail = new com.ontotext.trree.OwlimSchemaRepository()
                                   ^

I am not importing the conflicting class nor package. This error breaks java interoperability. This worked with scala 2.7.7.

Why are the scala package naming/importing rules enforced on valid binary java imports, instead of being scoped only on compiled scala sources?

Andrey (andrey) said:
If the solution would require dramatic changes in the Scala compiler which are
difficult to maintain then my vote is to keep the Scala compiler clean.
In this case the obfuscator will find a solution for Scala. We do not need to
change every java obfuscator in the world, we just need to use the one which is
able to work with Scala.

Pavol Vaskovic (pali-at-pali.sk) said:
I've tested,as suggested on [scala-user], that for direct references, it is possible to work around this issue with custom wrapper written in java. I'm not sure if this could be applied to original problem reported by extempore.

Once my scala files do not contain a package/class naming conflict on the "package path" (i.e. in the fully qualified name) there is no problem. Note this is unrelated to using import statements, as the problem is triggered by mere fully qualified reference.

I'm using class: com.ontotext.trree.OwlimSchemaRepository
The com.ontotext.trree package contains several class/package naming conflicts (a, b, c, d), the compiler chose to report 'b'.

This seems to be an issue with the way compiler looks up imports. I believe it should emit the reported error only in case if I'm trying to import the object/package that has naming conflict and not when some of it's siblings are in conflict.

Miles Egan (cageface) said:
I think this is tripping up a project I'm working on that uses a third party proprietary jar library too.

Kohsuke Kawaguchi (kohsuke) said (edited on Jun 7, 2011 10:49:13 PM UTC):
Jenkins also adopts this convention where class names and package names collide (except the colliding packages do not have any class files --- they only have resource files.) So I'd like to point out that this isn't just about obfuscators.

In my situation, the fix would be easier. We just want scala compiler to only consider real packages that contain some classes.

Commit Message Bot (anonymous) said:
(extempore in r25145) Added a -Y option to resolve namespace collisions between package and
object. It's a blunt instrument: if people have lots of these conflicts
they need to resolve in individually nuanced fashion, they'll probably
remain out of luck. But now people can use YourKit probes without a
custom hacked compiler. Let's say this closes #2089. Review by odersky.