Skip to content

I20211024-1800

I20211024-1800: Bug 573363: Fix classloader isolation for VerifyTests
@kriegaex kriegaex tagged this 22 Oct 10:59 
Before this fix, VerifyTests used a dedicated classloader subclass
VerifyTests.VerifyClassLoader in order to try and achieve class loader
isolation for separate tests running in the same cached JVM instance.
However, the isolation only worked for file system folders, not for JAR
files as e.g. used in DeprecatedTest.test008a. Because the JVM
normally does not close JAR files, replacing such a file would have
no effect on the loaded classes on UNIX-oid platforms and the additional
bad effect of locked file errors when trying to delete such JARs on
Windows.

The solution is,
  - to use a URLClassLoader, because it can be closed when no longer
    used and then releases its resources,
  - to make sure the classpath for test-specific directories and JARs is
    not set as a classpath parameter for the test JVM, but communicated
    per test via the existing socket connection between main and forked
    JVM.

In order to achieve this, some changes had to be done on both sides, in
classes TestVerifier (main JVM) and VerifyTests (forked test JVM).

Because it was inconvenient to test the interplay of both classes due to
the fact that not the original VerifyTests class was copied into the
forked JVM, but a hard-coded copy stored as a string inside
TestVerifier, I also added an option to switch into a mode actually
copying the original file. This mode could be the future default (it
falls back to the hard-coded value if the file cannot be read anyway),
but for backward compatibility the flag READ_VERIFY_TEST_FROM_FILE is
false by default.

Another goodie I added is a primitive filter for the source code,
capable of stripping out some annotations and 'assert', which are
incompatible with Java 1.5. So they do not need to be stripped out of
the VerifyTests source anymore, only the rest of the class needs  to be
compatible with 1.5, i.e. you should avoid things like diamonds,
multi-catch, catch-with-resources and other more recent Java features.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Bug 573363: TestVerifier.launchAndRun does not need minimal classpath

I guess I replaced one call too many and reverted from
  launcher.setClassPath(getMinimalClassPath(classpaths));
back to
  launcher.setClassPath(classpaths);

It actually only makes sense to minimise the classpath, if later the
missing paths can be communicated to the test VM via socket
communication (DataOutputStream). But that is only the case when
TestVerifier.loadAndRun is called, which again only happens in the case
that a JVM is reused.

If in the future we detect cases in which class loader isolation is
needed for TestVerifier.launchAndRun too, because e.g. later the same
JVM is to be re-used with the same class directory or JAR file names, we
need to invent a new way of communicating the additional paths (e.g. via
a temporary file) or always open a dedicated communication socket to the
target VM.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Bug 573363: Fix 2 tests checking cast error messages

1) MethodVerifyTest.testBug536978_comment5
2) LambdaExpressionsTest.test039

Make assertions more robust by producing predictable output:
  - Omit stack trace for test robustness.
  - Cut off class loader name (e.g. 'java.net.URLClassLoader @f3f9f4b')
    for easier matching.

Change-Id: I745b216a16bdb8d465a788b390c4b4b80e89bf82
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Reviewed-on: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/186176
Reviewed-by: Sravan Kumar Lakkimsetti <sravankumarl@in.ibm.com>
Reviewed-by: Manoj Palat <manpalat@in.ibm.com>
Tested-by: JDT Bot <jdt-bot@eclipse.org>
Assets 2
Loading