-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to Gradle 7.6 and JDK-19 #4973
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -45,12 +45,15 @@ | |
import org.gradle.internal.jvm.Jvm; | ||
import org.gradle.internal.jvm.inspection.JvmInstallationMetadata; | ||
import org.gradle.internal.jvm.inspection.JvmMetadataDetector; | ||
import org.gradle.jvm.toolchain.internal.InstallationLocation; | ||
import org.gradle.util.GradleVersion; | ||
|
||
import javax.inject.Inject; | ||
import java.io.File; | ||
import java.io.FileInputStream; | ||
import java.io.IOException; | ||
import java.lang.invoke.MethodHandles; | ||
import java.lang.invoke.MethodType; | ||
import java.nio.charset.StandardCharsets; | ||
import java.nio.file.Files; | ||
import java.nio.file.Path; | ||
|
@@ -195,7 +198,29 @@ private JavaVersion determineJavaVersion(String description, File javaHome, Java | |
} | ||
|
||
private JvmInstallationMetadata getJavaInstallation(File javaHome) { | ||
return jvmMetadataDetector.getMetadata(javaHome); | ||
final InstallationLocation location = new InstallationLocation(javaHome, "Java home"); | ||
|
||
try { | ||
try { | ||
// The getMetadata(File) is used by Gradle pre-7.6 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it simpler to get the version of gradle and remove all these try/catches? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, but how Gradle version helps? We still need to call the method :-) Unless we set the minimum to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's really NBD. I mean is there an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm ... the old refection mechanism could be used in such a way (get methods, try to find the one you need) but |
||
return (JvmInstallationMetadata) MethodHandles.publicLookup() | ||
.findVirtual(JvmMetadataDetector.class, "getMetadata", MethodType.methodType(JvmInstallationMetadata.class, File.class)) | ||
.bindTo(jvmMetadataDetector) | ||
.invokeExact(location.getLocation()); | ||
} catch (NoSuchMethodException | IllegalAccessException ex) { | ||
// The getMetadata(InstallationLocation) is used by Gradle post-7.6 | ||
return (JvmInstallationMetadata) MethodHandles.publicLookup() | ||
.findVirtual( | ||
JvmMetadataDetector.class, | ||
"getMetadata", | ||
MethodType.methodType(JvmInstallationMetadata.class, InstallationLocation.class) | ||
) | ||
.bindTo(jvmMetadataDetector) | ||
.invokeExact(location); | ||
} | ||
} catch (Throwable ex) { | ||
throw new IllegalStateException("Unable to find suitable JvmMetadataDetector::getMetadata", ex); | ||
} | ||
} | ||
|
||
private List<JavaHome> getAvailableJavaVersions(JavaVersion minimumCompilerVersion) { | ||
|
@@ -205,7 +230,7 @@ private List<JavaHome> getAvailableJavaVersions(JavaVersion minimumCompilerVersi | |
String javaHomeEnvVarName = getJavaHomeEnvVarName(Integer.toString(version)); | ||
if (System.getenv(javaHomeEnvVarName) != null) { | ||
File javaHomeDirectory = new File(findJavaHome(Integer.toString(version))); | ||
JvmInstallationMetadata javaInstallation = jvmMetadataDetector.getMetadata(javaHomeDirectory); | ||
JvmInstallationMetadata javaInstallation = getJavaInstallation(javaHomeDirectory); | ||
JavaHome javaHome = JavaHome.of(version, providers.provider(() -> { | ||
int actualVersion = Integer.parseInt(javaInstallation.getLanguageVersion().getMajorVersion()); | ||
if (actualVersion != version) { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -44,25 +44,30 @@ | |
public class MockSinglePrioritizingExecutor extends PrioritizedOpenSearchThreadPoolExecutor { | ||
|
||
public MockSinglePrioritizingExecutor(String name, DeterministicTaskQueue deterministicTaskQueue, ThreadPool threadPool) { | ||
super(name, 0, 1, 0L, TimeUnit.MILLISECONDS, r -> new Thread() { | ||
@Override | ||
public void start() { | ||
deterministicTaskQueue.scheduleNow(new Runnable() { | ||
@Override | ||
public void run() { | ||
try { | ||
r.run(); | ||
} catch (KillWorkerError kwe) { | ||
// hacks everywhere | ||
} | ||
super(name, 0, 1, 0L, TimeUnit.MILLISECONDS, r -> { | ||
// This executor used to override Thread::start method so the actual runnable is | ||
// being scheduled in the scope of current thread of execution. In JDK-19, the Thread::start | ||
// is not called anymore (https://bugs.openjdk.org/browse/JDK-8292027) and there is no | ||
// suitable option to alter the executor's behavior in the similar way. The closest we | ||
// could get to is to schedule the runnable once the ThreadFactory is being asked to | ||
// allocate the new thread. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This feels like a problem. How did you come up with a workaround and what do folks in https://bugs.openjdk.org/browse/JDK-8292027 think about it? Maybe add a comment there? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dblock it does, and the fact the issue is still open and no alternative mechanism provided, it will be the probelm for quite some time. I tried several approaches, the most straightforward one is to not override The idea behind this change: we know that the new thread is going to be allocated once thread pool decides that new worker is needed. We cannot override or alter the This implementation is laser targeted to the way There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the detailed explanation. |
||
deterministicTaskQueue.scheduleNow(new Runnable() { | ||
@Override | ||
public void run() { | ||
try { | ||
r.run(); | ||
} catch (KillWorkerError kwe) { | ||
// hacks everywhere | ||
} | ||
} | ||
|
||
@Override | ||
public String toString() { | ||
return r.toString(); | ||
} | ||
}); | ||
} | ||
@Override | ||
public String toString() { | ||
return r.toString(); | ||
} | ||
}); | ||
|
||
return new Thread(() -> {}); | ||
}, threadPool.getThreadContext(), threadPool.scheduler()); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:-(