On 12/05/2016 07:13, Alan Bateman wrote:
>
>
> On 11/05/2016 12:18, Mark Thomas wrote:
>> :
>> Sure. Done.
>> Review ID: 9087338
>>
> I found it, and moved it to the JDK project in JIRA:
>
> https://bugs.openjdk.java.net/browse/JDK-8156824
Thanks.
Mark
Hi Remi,
> > while working and trying the new JDK9 MethodHandles features like
> > MethodHandles#countedLoop, I recognized a API inconsistency problem
> with it.
> >
> > We also found this while implementing the "Painless" scripting language for
> > Elasticsearch (see https://goo.gl/DbOzjC)! Painl
Hi Ralph,
On 11/05/16 21:00, Ralph Goers wrote:
I am not at all familiar with how the stack is actually managed. I was hoping
it was just an array and that the index into it was being kept track of. Since
we know that we will only be adding more stack elements I would think that
deferring use
Hello,
Should this also care about overwriting threadlocals, threadgroup,
securitycontext and default exception handler (i.e. using the new constructor
for managed threads and some).
Gruss
Bernd
--
http://bernd.eckenfels.net
-Original Message-
From: Mark Thomas
To: Alan Bateman , c
Hi Shilpi,
thanks for the clarification. OK by me then - please note this is a lower-case
review.
Best,
Michael
> Am 11.05.2016 um 15:55 schrieb shilpi.rast...@oracle.com:
>
> Thank You Michael for comments!
>
> It was fixed for VarargsArrayTest.java but not fixed for
> java/lang/invoke/Cu
... yes.
Best,
Michael
> Am 12.05.2016 um 06:44 schrieb Sundararajan Athijegannathan
> :
>
> +1
>
> -Sundar
>
>
> On 5/11/2016 10:01 PM, shilpi.rast...@oracle.com wrote:
>> Hi All,
>>
>> Please review the updated webrev-
>> http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/
>>
>> Cha
Hi Uwe,
If you’re targetting JDK 9 only, you could also consider basing your language’s
dynamic operations on Dynalink; it’s integrated into JDK 9 and is specifically
meant as a way to ease implementation of languages that have dynamic types. It
happens to have a predefined GET_LENGTH[1] operat
Hi Uwe,
> Am 11.05.2016 um 21:35 schrieb Uwe Schindler :
> With Java 9 this gets a bit worse: There is no "easy way" with the
> MethodHanldes class to generate a MethodHandles.countedLoop() on all elements
> of an array:
>
> public static MethodHandle countedLoop(MethodHandle iterations, Method
Hi Attila,
thanks for the info. We are currently targeting Java 8.
The proposal made here was more about making the API in the MethodHandles class
“feature complete”, because you have the array element getters/setters there,
but not the length. This is pure inconsistent, because for count
> On 11 May 2016, at 18:31, shilpi.rast...@oracle.com wrote:
>
> Hi All,
>
> Please review the updated webrev-
> http://cr.openjdk.java.net/~srastogi/8149574/webrev.07/
>
1219 FieldVisitor fv;
1220 MethodVisitor mv;
1221 AnnotationVisitor av0;
Field “fv i
Hello,
In jshell, there's a special history mode that is intended to aid with
editing/re-entering multi-line snippets (EditingHistory). It works like
this: when the user goes back through the history to the first line of a
multi-line snippet, and enters/confirms that line, the history view is
On 12/05/2016 10:33, e...@zusammenkunft.net wrote:
> Hello,
>
> Should this also care about overwriting threadlocals, threadgroup,
> securitycontext and default exception handler (i.e. using the new
> constructor for managed threads and some).
>
> Gruss
> Bernd
>
I have only observed memory
Hello.
The following set of two patches aims to fix the errors that currently
occur during compilation of OpenJDK8U with gcc6 (version 6.1.0).
Other three patches needed to build OpenJDK8U have been posted to the
hotspot-dev with a similar message subject (for a total of five
patches).
I suppose
The following (RFC) patch aims to fix a build error when using gcc6:
/home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:
In function ‘_jobject*
Java_com_sun_java_util_jar_pack_NativeUnpack_getUnusedInput(JNIEnv*, jobject)’:
/home/guido/new/jdk
Disable the -Werror compiler flag while compiling JDK SCTP.
Signed-off-by: Guido Trentalancia
---
jdk/make/lib/NioLibraries.gmk |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- jdk8u-build2/jdk/make/lib/NioLibraries.gmk 2016-05-11 00:03:25.591433084
+0200
+++ jdk8u-build1/jdk/make
The nashorn and jdk repo changes look good to me.
Thanks,
-Sundar
On 5/12/2016 3:55 PM, Jan Lahoda wrote:
> Hello,
>
> In jshell, there's a special history mode that is intended to aid with
> editing/re-entering multi-line snippets (EditingHistory). It works
> like this: when the user goes back
Hi Hiroshi,
This is a good example of what seems like a small feature and yet there are
some unexpected complexities :-)
We will need to refine the implementation specification of List.spliterator,
which currently states:
* @implSpec
* The default implementation creates a
* late-binding split
Thank You Paul for comments.
Please review updated webrev
http://cr.openjdk.java.net/~srastogi/8149574/webrev.08/
Regards,
Shilpi
On 5/12/2016 3:41 PM, Paul Sandoz wrote:
On 11 May 2016, at 18:31, shilpi.rast...@oracle.com wrote:
Hi All,
Please review the updated webrev-
http://cr.openjdk.
Hello.
A year ago I asked about problems with the handling of files with
diacritics in their name, as per this thread:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017183.html
For almost the whole past year I suspended the investigation and moved to
other things t
Hi Paul:
On default package: with the new rule a VM anonymous class has to be
either [1] in the same package as that of the host class or [2] in the
unnamed package. MethodHandleImpl's T class was earlier in
java.lang.invoke package. So we can either fix it [1] to match the
package of the host cla
Hi Michael,
> > Am 11.05.2016 um 21:35 schrieb Uwe Schindler :
> > With Java 9 this gets a bit worse: There is no "easy way" with the
> MethodHanldes class to generate a MethodHandles.countedLoop() on all
> elements of an array:
> >
> > public static MethodHandle countedLoop(MethodHandle iteratio
On 12/05/2016 13:11, Fabrizio Giudici wrote:
:
The Paths submitted to the test are discovered by Files.walk().
What I'm seeing is that all the troubled files show now no access
problems with NIO, while IO fails (e.g. toFile().exists() returns
false while Files.exists(path) returns true).
:
Overall, looks really good! I like how it shapes out.
A couple of nitpicks:
(1) Please, use more meaningful names: INJECTED_INVOKER_TEMPLATE vs
T_BYTES, invokerTemplateGenerator vs tBytesGenerator, InjectedInvoker vs T.
(2) There's no need in a constructor. The invoker is never instantiat
> On 12 May 2016, at 14:24, Sundararajan Athijegannathan
> wrote:
>
> Hi Paul:
>
> On default package: with the new rule a VM anonymous class has to be
> either [1] in the same package as that of the host class or [2] in the
> unnamed package.
Yes.
> MethodHandleImpl's T class was earlier i
Looks fine.
Thanks for the updates, Roger
On 5/11/2016 4:30 AM, Stephen Colebourne wrote:
This seems fine by me.
Stephen
On 10 May 2016 at 19:25, nadeesh tv wrote:
Hi,
Stephen, Roger Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8155823/webrev.04/
On Thu, 12 May 2016 14:41:04 +0200, Alan Bateman
wrote:
I assume is a decoding and encoding round trip issue, meaning bytes ->
String -> bytes. When you use the new file system API then you are using
a Path which will use the underlying representation to access the file.
Once you call t
This patch applies on the top of the jdeps refresh patch [1]..
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.01/
The -addmods option is the same as what the runtime supports so that we can run
jdeps in the same command-line options as runtime. -system is to specify
On 5/12/16 8:54 AM, Fabrizio Giudici wrote:
On Thu, 12 May 2016 14:41:04 +0200, Alan Bateman
wrote:
I assume is a decoding and encoding round trip issue, meaning bytes
-> String -> bytes. When you use the new file system API then you are
using a Path which will use the underlying representa
Hi Joe,
Thanks for your comments and suggestions. New webrev can be found at
this location:
http://cr.openjdk.java.net/~aefimov/8145974/9/01
Answers are inlined.
Best Regards,
Aleksej
On 12/05/16 07:51, huizhe wang wrote:
Hi Aleksej,
The change looks good overall. It may be better to repl
Hi Mandy,
I am a bit surprised that the verbose option doesn't seem
to have any effect on the output of jdeps -I
I have built 4 jars:
unsafe.jar has some class that depend directly on
sun.misc.Unsafe, and some that don't.
indirect.jar has some classes that depends indirectly
I think I know where the issue is. Can you send me your test and I can modify
and include it in this patch?
Mandy
> On May 12, 2016, at 10:31 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> I am a bit surprised that the verbose option doesn't seem
> to have any effect on the output of jdeps -I
>
Thanks Aleksej. The change looks good.
Best,
Joe
On 5/12/2016 10:00 AM, Aleks Efimov wrote:
Hi Joe,
Thanks for your comments and suggestions. New webrev can be found at
this location:
http://cr.openjdk.java.net/~aefimov/8145974/9/01
Answers are inlined.
Best Regards,
Aleksej
On 12/05/16 0
On Thu, 12 May 2016 18:52:37 +0200, Xueming Shen
wrote:
It sounds more like a hfs+/nfd file path issue (file name on nfs+ is in
unicode nfd form). Myabe the
nfd-ed file name gets messed up while doing the utf8-xxx-utf8
conversion. Does that --iconv have
any specific encoding name specifie
Hi Brent,
>
> A new webrev is here:
> http://cr.openjdk.java.net/~bchristi/8029891/webrev.4/
This patch looks good.
To help future readers to understand this, it may be better to move:
1152 private transient ConcurrentHashMap map =
1153 new ConcurrentHashMap<>(8);
to the beginn
Hi,
Please help review the proposed change for #8147588
issue: https://bugs.openjdk.java.net/browse/JDK-8147588
webrev: http://cr.openjdk.java.net/~sherman/8147588/webrev
This is a regression on Windows platform triggered by the change for
https://bugs.openjdk.java.net/browse/JDK-8145260, in wh
> On May 11, 2016, at 8:39 PM, David Holmes wrote:
>
>> While good progress was made during the original code review, all of the
>> overridden methods in Properties caused an explosion of unnecessary
>> JavaDoc (see specdiff at [2]). With the recent fix of 8073100 (new
>> "@hidden" JavaDoc tag)
Hi, David
On 5/11/16 8:39 PM, David Holmes wrote:
On 11/05/2016 7:56 AM, Brent Christian wrote:
While good progress was made during the original code review, all of the
overridden methods in Properties caused an explosion of unnecessary
JavaDoc (see specdiff at [2]). With the recent fix of 807
On 5/12/16 11:44 AM, Mandy Chung wrote:
This patch looks good.
To help future readers to understand this, it may be better to move:
1152 private transient ConcurrentHashMap map =
1153 new ConcurrentHashMap<>(8);
to the beginning and add a comment describing what are lock-free a
> On May 12, 2016, at 2:44 PM, Brent Christian
> wrote:
>
> On 5/12/16 11:44 AM, Mandy Chung wrote:
>>
>> This patch looks good.
>>
>> To help future readers to understand this, it may be better to move:
>> 1152 private transient ConcurrentHashMap map =
>> 1153 new ConcurrentH
Update to the test, and additional comments:
http://cr.openjdk.java.net/~bchristi/8029891/webrev.5/webrev/
Thanks,
-Brent
On 5/12/16 4:15 PM, Mandy Chung wrote:
On May 12, 2016, at 2:44 PM, Brent Christian wrote:
On 5/12/16 11:44 AM, Mandy Chung wrote:
This patch looks good.
To help fut
Hi Brent,
On 13/05/2016 7:02 AM, Brent Christian wrote:
Hi, David
On 5/11/16 8:39 PM, David Holmes wrote:
On 11/05/2016 7:56 AM, Brent Christian wrote:
While good progress was made during the original code review, all of the
overridden methods in Properties caused an explosion of unnecessary
On 5/11/16 2:37 PM, Martin Buchholz wrote:
The problem is again that the library maintainer is not the same as
the compiler invoker.
A conscientious library maintainer does not stop at ensuring that
their own builds are warning free; they want to ensure as much as they
can that their users can al
42 matches
Mail list logo
