Undo parent for MultipleParentsClassLoader

[charlesmunger]

66998ea inadvertently undid a change from 9bc9be6, which breaks behavior under some classloaders that special-case mockito classes. Use of an explicit parent with MultipleParentsClassLoader appears to be discouraged in the documentation also.

Followup for #2303

[codecov-commenter]

Codecov Report

Merging #2312 (62bd555) into main (d475354) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main    #2312      +/-   ##
============================================
+ Coverage     84.61%   84.65%   +0.04%     
- Complexity     2766     2768       +2     
============================================
  Files           328      328              
  Lines          8428     8428              
  Branches       1011     1011              
============================================
+ Hits           7131     7135       +4     
  Misses         1015     1015              
+ Partials        282      278       -4     

Impacted Files	Coverage Δ
.../creation/bytebuddy/SubclassBytecodeGenerator.java	80.71% <100.00%> (+1.42%)	⬆️
...to/internal/util/concurrent/WeakConcurrentMap.java	39.39% <0.00%> (+2.02%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d475354...62bd555. Read the comment docs.

[TimvdLippe]

Thanks for the quick fix! Can we please add a regression test for this scenario? Preferably without introducing any new dependencies. E.g. let's not add GWTMockito as dependency to our test suite, but instead construct a ClassLoader ourselves that would behave as if it was the ClassLoader in GWTMockito.

[charlesmunger]

I spent some time thinking about it and reduced the test case to something understandable.

[TimvdLippe]

I slightly refactored the test code to make it clear which exact classes will be loaded by the child ClassLoader and which are not. I have verified that reverting the change in SubclassBytecodeGenerator makes the test fail again.

Thanks Charles for fixing this!