Skip to content

Conversation

@smarter
Copy link
Member

@smarter smarter commented Jan 7, 2020

No description provided.

Somehow, if we don't close the classloader used to read .tasty files
from jars, a subsequent compilation run might end up reading a stale
version of the .tasty file which does not exist on disk anymore. I don't
understand why this happens since we don't reuse the classloader itself,
but that's life sometimes ¯\_(ツ)_/¯
Copy link
Contributor

@nicolasstucki nicolasstucki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise LGTM

The previous commit tried to fix some weird caching behaviors by closing
the classloader used to read a .tasty file, but it turns out the JVM is
dumb and that breaks any other in-use classloader that uses the same
jar. Give up on the whole thing and work directly with the underlying
ZipArchive to find the .tasty file (this just required adding a "parent"
field to ZipArchive#Entry).
@smarter
Copy link
Member Author

smarter commented Jan 7, 2020

I had to use a different approach, see latest commit

@smarter smarter assigned nicolasstucki and unassigned smarter Jan 7, 2020
@nicolasstucki nicolasstucki merged commit 8305bd0 into scala:master Jan 8, 2020
@nicolasstucki nicolasstucki deleted the fix-stale-tasty branch January 8, 2020 08:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants