[jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException
8254350: CompletableFuture.get may swallow InterruptedException - Commit messages: - JDK-8254350 Changes: https://git.openjdk.java.net/jdk16/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=17=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254350 Stats: 178 lines in 3 files changed: 170 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/17/head:pull/17 PR: https://git.openjdk.java.net/jdk16/pull/17
[jdk16] RFR: JDK-8247994: Localize javadoc search
This is for JDK16, as a precursor to fixing JDK-8258002. While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself. The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image. - Commit messages: - JDK-8247994: Localize javadoc search Changes: https://git.openjdk.java.net/jdk16/pull/16/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=16=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247994 Stats: 122 lines in 9 files changed: 88 ins; 6 del; 28 mod Patch: https://git.openjdk.java.net/jdk16/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16 PR: https://git.openjdk.java.net/jdk16/pull/16
Re: [jdk16] RFR: JDK-8247994: Localize javadoc search
On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote: > This is for JDK16, as a precursor to fixing JDK-8258002. > > While it is good to be using localized strings in the generated output, the > significance for JDK-8258002 is that the strings are now obtained from a > resource file, and not hardcoded in JavaScript file itself. > > The source file `search.js` is renamed to `search.js.template`, and (unlike > other template files) is copied as-is into the generated image. The values in > the template are resolved when javadoc is executed, depending on the locale > in use at the time. Because of the change in the file's extension, two > makefiles are updated to accommodate the new extension: one is for the > "interim" javadoc used to generate the API docs; the other is for the primary > javadoc in the main JDK image. make/CompileInterimLangtools.gmk line 77: > 75: Standard.java, \ > 76: EXTRA_FILES := > $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java, \ > 77: COPY := .gif .png .xml .css .js .js.template .txt > javax.tools.JavaCompilerTool, \ Build-folk: it would be nice if this macro could use `$(jdk.javadoc_COPY)` instead of having to duplicate entries. (Future RFE?) - PR: https://git.openjdk.java.net/jdk16/pull/16
[jdk16] RFR: 8258140: Update @jls tags in java.base for renamed/renumbered sections
Given upcoming changes in the JLS terminology around the term "type", various sections were renamed: https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html The @jls tags in the java.base module which refer to the renamed sections should be updated. Analogous changes in the java.compiler module made under JDK-8258060. - Commit messages: - 8258140 Changes: https://git.openjdk.java.net/jdk16/pull/15/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=15=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258140 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk16/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/15/head:pull/15 PR: https://git.openjdk.java.net/jdk16/pull/15
It's not a bug but it's not user friendly
A student of mine send me a code that can be reduced to this code
---
import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;
public class ThereIsABugButWhere {
private static final VarHandle TEXT;
static {
try {
TEXT = MethodHandles.lookup().findVarHandle(ThereIsABugButWhere.class,
"text", String.class);
} catch (NoSuchFieldException | IllegalAccessException e) {
throw new AssertionError(e);
}
}
private final String text;
ThereIsABugButWhere() {
text = "FOO";
}
public void update(String s) {
TEXT.compareAndSet(this, "FOO", s);
}
public static void main(String[] args) {
new ThereIsABugButWhere().update("BAR");
}
}
---
If you execute it, you get
Exception in thread "main" java.lang.UnsupportedOperationException
at java.base/java.lang.invoke.VarForm.getMemberName(VarForm.java:99)
at
java.base/java.lang.invoke.VarHandleGuards.guard_LLL_Z(VarHandleGuards.java:77)
at ThereIsABugButWhere.update(ThereIsABugButWhere.java:22)
at ThereIsABugButWhere.main(ThereIsABugButWhere.java:26)
It takes me 20 mins to find the issue ...
I think we can improve the error message or even better report the issue at the
right location :)
regards,
Rémi
