Re: scalac compilation requires transitive dependencies on classpath at compile-time whereas javac does not

Thanks so much, Jason.

Added issue:
https://issues.scala-lang.org/browse/SI-9673

I am not using -optimize, or indeed any flag to compile.  You can see the 
invocation here:

https://github.com/bazelbuild/rules_scala/blob/master/scala/scala.bzl#L78

I am using that with no `scala_opts` set.

On Wednesday, February 24, 2016 at 2:39:31 AM UTC-10, Jason Zaugg wrote:
>
> ​
>
> 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://www.google.com/url?q=https%3A%2F%2Fissues.scala-lang.org%2Fbrowse%2FSI-7751%3FfocusedCommentId%3D67907%26page%3Dcom.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel%23comment-67907&sa=D&sntz=1&usg=AFQjCNHcle_ecbgC33RB_F462Oskf4c1fg> 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] 
> <javascript:>> 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] <javascript:>.
>> 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.