Problem: FQTNs are easily detectable by regexp, but are ambiguous with long dereference chains, e.g.

public void beep(ToolSetup com) {
  System.out.println(com.toolchain.you.Get.the.picture);
}

You can figure out if

com.toolchain.you.Get

is a real type if you know the real list of classes that are available on the classpath, but Pants’ approach is to not specify the entire dependency list, especially if we’re going to make Fat JARs. Proposed Solution: When resolving the lockfile for a project, we walk the

zip

index of each dependency JAR we pull down. At this point, we can note the packages that are included with each locked JAR, and save that to a metadata file. At dependency scan time, we can search for strings of the form

x.y…z

and look for prefixes that match a known package name, and include the JARs that provide that package on the classpath. This will produce an overspecified classpath (if there are package prefixes that are ambiguous with variable names, we may specify more dependency classes than are actually there), but AIUI, overspecifying a classpath is not a correctness issue, but a file size issue. Any thoughts before I commit this to a GH issue? @witty-crayon-22786 @bored-art-40741

as mentioned there: i think that “relative imports” / FQTs are a lower priority than code that actually imports things, and would be totally fine not catching inline imports in a first version if we agree that it encourages good code hygiene to prefer imports

oh, got it. referring to your comment

when in doubt we should bias toward under specified: although we do have syntax for excluding dependencies that have been inferred, i think that it is much better to get an error from a compiler that something isn’t present, then no warning at all that you are pulling in something that you don’t actually depend on

i think that it’s really important to minimize magic, and avoiding approaches that have false positives is an important part of that

Explicit dependencies provide an easy to understand escape hatch for fixing a dep that dep inference missed. There is no such escape hatch for fixing a dep that inference incorrectly inferred, and it's really difficult to even detect such a situation

In that scenario too, even the

!

escape hatch is infeasible

There are many more dependencies in the world that you might need to explicitly cut than there are dependencies that you might need to explicitly add

I'm also leaning strongly toward ignoring inline type references that aren't explicitly imported, and potentially heuristically ignoring imports that appear to be "implicit" (e.g.

import Foo.blah

where it looks like it's probably importing from a type already in scope based on the name)

There's a bunch of incremental work we could do with phased parse rounds where we add in known immediate dependencies and sources from the same package to get a really strong handle on implicit imports, but I think it's worth seeing how much demand there really is for that (weighed against the difficulty of just adding some explicit deps)

this isn’t a new failure mode: folks who use build systems know this one.

…which i guess is the whole reasoning behind preferring false negatives: the consequences are relatively low.

That's much more likely now that I have full type export working in the existing code

I think it's doable, just harder, and probably should be introduced as an experimental option with lots of instrumentation

I'm actually more worried right now about the sort of opposite scenario that I expect to be more common and more difficult to detect: unqualified references to types in the same package

The best I have now is: you should still import those for hygiene reasons, and because we need that import for fine grained dep analysis

Or perhaps we should have a flag that automatically hairballs all package sources together for people who really want implicit access to types in the same package

"current level"?

What I have now is type-level inference

So it'll depend on fine-grained sources within a package

Although it also has the analysis available to do package-level dependencies if we want

And we're still going to need to special case tests somehow there

and you have `A.java`:

package org.pantsbuild.example;

import org.pantsbuild.example.C;

public class A {
	public static void main(String[] args) throws Exception {
		C c = new C();
	}
}

These both compile. Note that A is referring to a package private type in B.java

And in fact you don't even need to import C there

I think this mostly solves the test issue organically, if you're willing to import types from the same package in your test

My first pass at this treated Java packages as hierarchical, and while I got a pretty clean implementation, I realized the false positive failure modes were too bad

e.g. if I saw an import for

foo.bar.Baz

but nothing had the package

foo.bar

, I'd end up depending on everything that provided a package with a prefix of

foo. ...

Which when applied to

com

or

org

is disasterous

The new approach is better, and it allows for the sort of "monolithic package" approach you're suggesting if we want to go that route. In fact, it allows for that approach as a user-configurable option, but I haven't implemented that