Re: scalac compilation requires transitive dependencies on classpath at compile-time whereas javac does not
Jason Zaugg <[email protected]> Wed, 24 Feb 2016 12:39:18 +0000
| Newsgroups | gmane.comp.lang.scala |
|---|---|
| Message-ID | <CAG3_yeUUmmBSSJLskRMQZpv2qh4E3VBBq+FUB-1p7OoEjX-GYA@mail.gmail.com> |
Are you compiling with -optimize at the time? I notice that under this mode, our ClassFileParser (that we use to read the signatures of Java originated classes) reads the signatures of private fields which would include private static Logger LOG = .... Looks like the same problem (right down to Hadoop) was reported <https://issues.scala-lang.org/browse/SI-7751?focusedCommentId=67907&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-67907> in the comments of a kindred bug. We should definitely demote that warning if it is just on a a private field. Please raise a ticket and I’ll improve this. Here's the test case: https://gist.github.com/64fe18c74eac9d49092e In the meantime, you can safely ignore the warning. It will turn into an error if it really prevents the compiler from making a decision later on. We don't currently have a means to disable the warning, sort of customizing the reporter in the compiler, which is a bit of a pain. -jason On Wed, Feb 24, 2016 at 5:19 PM P. Oscar Boykin <[email protected]> wrote: > I am using 2.11.7 > > It's a bit hard to boil down since I am seeing it when depending on Hadoop > code which has a very deep dependency graph. > > I'm instantiating GenericOptionsParser: > > https://hadoop.apache.org/docs/r1.0.4/api/org/apache/hadoop/util/GenericOptionsParser.html > and Configuration: > > https://hadoop.apache.org/docs/r2.6.4/api/org/apache/hadoop/conf/Configuration.html > > and it is complaining about: > > *07:09:29* warning: Class org.apache.commons.logging.Log not found - continuing with a stub.*07:09:29* one warning found > > > > which will be added to the runtime classpath, but is indeed not on the > compile time classpath. > > Is that enough to clarify the question some? > > So, I think we are dealing with cases where the classes in question never > appear explicitly in the code, or even in a superclass of any new classes, > but are used by some of the classes instantiated by the code. > > This code is not OSS, and hadoop deps are pretty deep, so it is a bit of a > pain to replicate it (which I'm hoping to avoid if the answer is that there > is little that can be done). > > > On Tuesday, February 23, 2016 at 2:19:15 PM UTC-10, Jason Zaugg wrote: >> >> What Scala version(s) are you testing with? Robustness to missing >> dependencies fluctuated somewhat through 2.10 and 2.11 releases. >> >> Could you boil this down to a test case like this one? I’ll then be >> better able to answer your questions. >> >> % cat sandbox/test.scala >> class A >> >> class B { >> def foo(a: A) = a >> def bar = 42 >> } >> >> % (export V=2.11.7; ~/scala/$V/bin/scalac sandbox/test.scala; rm A.class; ~/scala/$V/bin/scala -nc -e 'new B().bar') >> >> % (export V=2.11.7; ~/scala/$V/bin/scalac sandbox/test.scala; rm A.class; ~/scala/$V/bin/scala -nc -e 'new B().foo(null)') >> error: missing or invalid dependency detected while loading class file 'B.class'. >> Could not access type A in package <empty>, >> because it (or its dependencies) are missing. Check your build definition for >> missing or conflicting dependencies. (Re-run with `-Ylog-classpath` to see the problematic classpath.) >> A full rebuild may help if 'B.class' was compiled against an incompatible version of <empty>. >> /code/scala on topic/nuke-impl-classes-2* >> >> As you can see from my test, the intention is to create a stub symbol for >> the type of the parameter a when we read the B.class, and defer any >> error until typechecking can’t proceed without knowing more about that type. >> >> Regards, >> >> -jason >> >> > -- > You received this message because you are subscribed to the Google Groups > "scala-language" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "scala-language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.