One more alternative which could be considered (though it requires a
language change) is to allow the inference of Iterable type for
enhanced for when iteration value is a function expression and
iteration parameter type is explicitly specified as T. In this case
for(T t : stream::iterator) {}
Hello!
The proposal looks good to me. In particular it's very nice to have
this properly (ability to iterate only once) to be encoded in the type
system. This could be helpful for static analysis tools to warn when
IterableOnce is reused.
Scanner case looks funny. In general such pattern could
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Remove JPackageCreateImageOverwriteTest and
JPackageCreateImageStripNativeCommandsTest.
- Remove usage of --overwrite.
[1]
Hi all,
Please review and comment on this proposal to allow Stream instances to be used
in enhanced-for ("for-each") loops.
Abstract
Occasionally it's useful to iterate a Stream using a conventional loop. However,
the Stream interface doesn't implement Iterable, and therefore streams cannot
On 02/28/2019 01:06 PM, Alan Bateman wrote:
On 28/02/2019 20:58, Jonathan Gibbons wrote:
Looking at the revised JAR specification, approved in [1], it is
disappointing that the spec contains text which is specific to
a JAR file being used in a classloader:
|The resulting URLs are inserted
looks fine Naoto
> On Feb 28, 2019, at 4:15 PM, Naoto Sato wrote:
>
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8219890
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8219890/webrev.00/
>
> After
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8219890
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8219890/webrev.00/
After the fix for 8217609, some locales return empty string for the
display name for the new era.
On 28/02/2019 20:58, Jonathan Gibbons wrote:
Looking at the revised JAR specification, approved in [1], it is
disappointing that the spec contains text which is specific to
a JAR file being used in a classloader:
|The resulting URLs are inserted into the search path of the class
loader opening
Looking at the revised JAR specification, approved in [1], it is
disappointing that the spec contains text which is specific to
a JAR file being used in a classloader:
|The resulting URLs are inserted into the search path of the class loader
opening the context JAR immediately following the
Hi Philipp,
Thank you for looking into this issue and proposing a fix. I ran the JCK and
encountered 9 failures similar to the JavaClassPathTest failure. The JCK tests
that I looked at did not validate all of the attributes which is one of the
reasons this was not caught earlier
Given the
a
Hi All,
This is my first contribution to openjdk, so hope to learn a lot!
I first posted this to compiler-dev, but they explained that I better
can discuss this first on this list.
I created a fix + tests for
https://bugs.openjdk.java.net/browse/JDK-8218268 (I will rewrite the
test to java
I added the 'jdk8u-fix-request' tag to these issues.
Paul
On 2/28/19, 3:13 AM, "core-libs-dev on behalf of Deepak Kejriwal"
wrote:
Hi All,
Please approve the backport of following bugs to 8u-dev.
JDK-8202088 : Japanese new era implementation
Hi All,
Please approve the backport of following bugs to 8u-dev.
JDK-8202088 : Japanese new era implementation
JDK-8207152 : Placeholder for Japanese new era should be two characters
JDK-8211398 : Square character support for the Japanese new era
JDK-8180469 : Wrong short form text for
Hello,
I can confirm the same ugly error stack with 12-b33 EA, this time with debug:
$ jdk-12/bin/java -cp . -Dsun.java2d.debugfonts=true FontTest
Are we headless? true
g = sun.java2d.HeadlessGraphicsEnvironment headless: true
Feb 28, 2019 9:50:32 AM sun.awt.X11FontManager registerFontDir
INFO:
14 matches
Mail list logo
