New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 885273 link

Starred by 2 users

Issue metadata

Status: Verified
Owner: ----
Closed: Nov 21
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Build should validate classpath of targets is correct

Project Member Reported by agrieve@chromium.org, Sep 18

Issue description

We used to pass only the direct classpath to javac when compiling. Now that we use errorprone, we've switched to passing the full classpath (required by errorprone - bug 804331).

Besides having targets no longer always specifying correct deps, this actually leads to confusing errors, such as desugar failing (it still uses direct classpath):
 * E.g.: https://chromium-review.googlesource.com/c/chromium/src/+/1230059/1)

There is also nothing in our build that validates the deps of prebuilt jars, which can lead to proguard / r8 failing (or more often, working by accident due to an unrelated dependency adding the missing one). 
 * E.g. https://bugs.chromium.org/p/chromium/issues/detail?id=872904#c17

We should add to our build system some validation that direct deps are correct. Ideally, it should work for both java_library and java_prebuilt.

One idea is to put it in bytecode_processor.py, except that it uses the full classpath... Perhaps we could pass it both the direct and full classpath so that it can ensure all directly references are in the direct classpath:
https://stackoverflow.com/questions/1983839/determine-which-jar-file-a-class-is-from

 
We could use the bytecode rewriter to do this. Another option would be to use python:

#1 - use javap to dump all referenced classes.
#2 - use zipfile to find .class files for referenced classes.

Not sure if this would be faster / slower than putting it in bytecode rewriter.
Status: Verified (was: Available)
This has been done in org.chromium.bytecode.ClassPathValidator.

Sign in to add a comment