New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ToolBox doesn't respect relative imports #6393
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6393?orig=1 |
@xeno-by said: The problem is that Scala reflection and reflective compiler (which is underlying toolboxes) use a different model of classfile loading than vanilla scalac does. Vanilla compiler has its classpath as a list of directories/jars on the filesystem, so it can exhaustively enumerate the packages on the classpath. Reflective compiler works with arbitrary classloaders, and classloaders don't have a concept of enumerating packages. As a result, when a reflective compiler sees "math" having "import scala.; import java.lang." imports in the lexical context, it doesn't know whether that "math" stands for root.math, scala.math or java.lang.math. So it has to speculate and provisionally creates a package for root.math, which ends up being a wrong choice. We could probably support a notion of "overloaded" packages, so that the compiler doesn't have to speculate and can store all the possible options, but that'd require redesign of reflection and probably of the typer as well. |
@gkossakowski said: |
@xeno-by said: |
@paulp said: This is important for other reasons, independent of reflection. #6039. I have gone to a lot of trouble to work around it only a small ways, because I am plagued by compilation errors whenever I try to recompile a subset of compiler sources. scala/scala@55b609458f But that was only the beginning, and deterioration began immediately. Yet another reason it is important is because scanning the entire classpath up front is a very expensive piece of startup time. |
@paulp said: |
@xeno-by said: |
@gkossakowski said: |
@retronym said: Rather than deal with the lowest common denominator (the ClassLoader API), we could try to do a better job for the more powerful, and very common, URLClassLoader, which would let use get at the underlying folders and JAR files to enumerate the classpath, as is done in the compiler proper. This might be an opt-in feature, or even a feature implemented in an external library, that takes advantage of extra hooks we expose. |
@xeno-by said (edited on Jan 15, 2013 6:49:53 PM UTC): As to the comment itself, a possible solution would be to distinguish URLClassLoaders, which can exhaustively enumerate their contents, and treat them specially in the reflective compiler. That would bring conceptual feature parity to toolboxes w.r.t the regular compiler in 99% of the use cases. |
@gkossakowski said: Let's start with sbt and IDE. I don't know how sbt is handling classloaders so I added Mark to watchers and let him comment on that. Same for Iulian. |
@retronym said: But it is likely that some environments (maybe OSGi) will be fundamentally incompatible with classpath enumeration, and will not support ToolBox compilation. We might have to live with that (or provide hooks for someone else to build a bridge). But we shouldn't punish the mainstream. I believe that Paul's branch a few comments above has a little code for URLClassLoader enumeration. |
@gkossakowski said: If we are designing API we should think about all future clients not only current ones. I agree that we should provide connivence for common case but we need to ensure that we have a way to support more exotic environments. In order to assure that, could we start with designing an API that allows one to pass classpath enumerator to Reflection API, try that with {{URLClassLoader}}-based enumerator and only then make it a default choice? |
@retronym said: |
I am having trouble fully understanding the impact of this issue, but I've posted about it at this Stack Overflow question. If this issue is related, then it is a blocker for me, and I'd like to know the current status of possible solutions (if any). Thanks in advance! |
any solutions? |
You can check out the SO post for what solved my problem. I haven't looked at Scala in a while, so I'm not sure if it's the same problem, but I hope it helps! |
The text was updated successfully, but these errors were encountered: