JAR entry not found when JAR is updated inline and cached by URLConnection

[eicki]

We've been using maven-assembly-plugin 2.5.5 which depends on plexus-io 2.6.
Additionally our assembly unpacks jar dependencies.
From time to time this failed stating that "JAR entry ... not found" in our jar that we want to unpack, this didn't occur that often so we didn't care. But for some unknown reason after we upgraded our Jenkins to a recent version (especially we now use Java 7 instead of Java 6) the assembly step in our build started to fail in 50% of all cases.
While the root cause is unclear we found a remedy for it, namely to change PlexusIoUrlResource in the following way:

Replace
return url.openStream();
by
URLConnection uc = url.openConnection(); uc.setUseCaches(false); return uc.getInputStream();

[michael-o]

Obviously the cache is broken, did you search for other possible issues related to the URL connection with cache?

[eicki]

Don't think java guys will consider this a bug because http://bugs.java.com/view_bug.do?bug_id=6207022 states they won't fix this (I know this is quite old and I've no clue why this started to get worse with Java 7).
What I additionally found out is that the assembly plugin always retrieves fresh new SNAPSHOTs from our nexus for our dependencies we want to unpack and I think this may be part of the problem that the jar the build depends on is multiple times retrieved and written to the local repo.

[michael-o]

The bug in the JDK is quite obvious. So you think that disabling caching will solve the problem and won't cause any other issues? What about performance penalities?

[eicki]

We have adjusted plexus-io 2.6 for us in the above way a few days ago and the problem has disappeared. I also did a quick look into the JarURLConnection class from the JDK, deactivating the caching should just behave as if there is a cache miss, so I don't expect other issues.
Concerning performance penalties, we don't see any in our build (i.e. it is probably there but not measurable).
I think url connection caching in the JDK has been introduced having some remote retrieval via slow networks in mind (I checked it, it is there ever since the beginning, i.e. JDK 1.0). But this is not the case here, the jar is already present in the local maven repo, so reading the file twice shouldn't harm.

[michael-o]

Found two spots. Do you want to create the PR and get credit or do you want me to go fix it directly?

[eicki]

You may fix it. By the way I really appreciate your quick response to this issue.

[michael-o]

Fixed, please test.

[rbjorklin]

This change has a very noticeable performance impact when building a jar-with-dependencies and at least one of the dependencies is pretty big such as eclipse-collections. We have single module builds that go from ~20 seconds to over 2 minutes and multi-module builds that go from ~3:30 minutes to over 8 minutes. We're building with JDK10 and have not yet experienced any issues when the cache is active. Is there any chance that cache use could be made configurable?

[michael-o]

@rbjorklin Willing to re-evaluate if you provide some reasonable PR.