Hi Masayoshi,
Thank you for review. This test was contributed by me for bug HYPERLINK
"https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982.
Running this only in English should be Ok as per me, since this was added just
to test one of the parsing scenario when Zone information is ava
Looks OK to me. But I'd like some java.time people to review this change
to see if the intention of this test is to run only in English.
Thanks,
Masayoshi
On 1/27/2016 1:51 PM, Ramanand Patil wrote:
Hi all,
Please help me in reviewing this test fix.
Regards,
Ramanand.
From: Raman
Hi all,
Please help me in reviewing this test fix.
Regards,
Ramanand.
From: Ramanand Patil
Sent: Monday, January 25, 2016 1:05 PM
To: i18n-...@openjdk.java.net
Cc: core-libs-dev@openjdk.java.net
Subject: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of
java/time/tck/java/time/form
> On Jan 25, 2016, at 8:54 AM, Alan Bateman wrote:
Somehow I missed this, sorry for the delayed response.
>>
>> Changed to BASE, i.e. Release.BASE
>>
> This looks better. Release.BASE is probably okay although it still feels like
> Release.UNVERSIONED, esp. when it is defined as "Represents
VM anonymous classes are an implementation detail that is
opaque to system components except for the lowest layers of
the JDK runtime and the JVM itself. Transformers and other
instrumentation should not look inside them expecting to interpose
on their behavior. Ideally we should not make them vi
> On Jan 26, 2016, at 8:27 AM, Chris Hegarty wrote:
>
> Latest webrev updated in-place:
> http://cr.openjdk.java.net/~chegar/8148117/
>
> * to execute the run method requires an appropriate permission
> * reverted any copyright changes ( leave to a bulk update )
> * updated the test to remove
Hi Martin,
how about seeing j.l.i as a framework for lightweight reflection on the one
hand, and for method handle-based meta-programming on the other? That's clearly
usable beyond the domain of dynamic language implementation. Granted, the
latter remains an important application area, but ther
I think that expectation is just out of date (if not outright
mistaken.) Yes, j.l.i was originally called "java.dyn", but prior to
shipping *7* we renamed it to j.l.i precisely because it had turned into
a general customizable linkage mechanism that was usable far beyond
dynamic languages. (To
On 1/26/16 4:28 AM, Remi Forax wrote:
please don't be seduced by the dark side,
Clearly, he feels the call from light. :-)
On 1/26/16 10:25 AM, Martin Buchholz wrote:
webrev refreshed -
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Vector-grow/
Hi Martin,
Thanks for the updates. L
There's a big "expectations" effect here. j.l.invoke is "supposed to
be" for making dynamic languages less slow, not for making low-level,
ultra-non-dynamic operations faster. Asking the Unsafe users of the
world to switch to dynamic VarHandle is like asking C programmers to
rewrite their code in
Hi Vladimir,
I have previously explored what you suggest (instrumenting the lambda
exception's method bodies) but decided against it, mainly for three
reasons:
1. Instrumentation has to be done more eagerly: To avoid redefinition
(and the constraints involved), the instrumentation has to be appli
On Jan 26, 2016, at 11:08 AM, Andrew Haley wrote:
>
> On 01/26/2016 07:04 PM, John Rose wrote:
>> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic.
>> IMO that's a better starting point than memcpy. Perhaps it can be
>> given an additional parameter (or overloading) to specify a swa
On 01/26/2016 07:04 PM, John Rose wrote:
> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic.
> IMO that's a better starting point than memcpy. Perhaps it can be
> given an additional parameter (or overloading) to specify a swap size.
OK, but conjoint_memory_atomic doesn't guarantee t
On Jan 26, 2016, at 10:48 AM, Andrew Haley wrote:
>
> On 01/26/2016 06:32 PM, John Rose wrote:
>> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote:
>>>
>>> I agree that memcpy is the right thing to use. It's portable and is
>>> inlined well on production-quality C compilers.
>>
>> But it is no
On 01/26/2016 06:32 PM, John Rose wrote:
> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote:
>>
>> I agree that memcpy is the right thing to use. It's portable and is
>> inlined well on production-quality C compilers.
>
> But it is not strong enough to uphold the Java memory model,
> because it i
On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote:
>
> I agree that memcpy is the right thing to use. It's portable and is
> inlined well on production-quality C compilers.
But it is not strong enough to uphold the Java memory model,
because it is allows to copy byte-wise, which can tear shorts,
webrev refreshed -
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Vector-grow/
On Tue, Jan 26, 2016 at 4:28 AM, Remi Forax wrote:
> Hi Martin,
> sorry for jumping on this conversation lately,
> please don't be seduced by the dark side,
Too late! I've already committed such changes to Arra
On Tue, Jan 26, 2016 at 5:44 AM, Jason Mehrens
wrote:
> Hi Martin,
>
> Are you sure about the change where addElement is now calling the public
> (non-final) version of add? I would think that we would want to avoid any
> type of compatibility changes with regard to Vector.
Jason, you are righ
On 26/01/2016 16:27, Chris Hegarty wrote:
Latest webrev updated in-place:
http://cr.openjdk.java.net/~chegar/8148117/
* to execute the run method requires an appropriate permission
* reverted any copyright changes ( leave to a bulk update )
* updated the test to remove the script
-Ch
> On 26 Jan 2016, at 16:57, Tagir F. Valeev wrote:
>
> Hello!
>
> Thanks for review! Updated webrev:
> http://cr.openjdk.java.net/~tvaleev/webrev/8147505/r2/
> Removed redundant test and added a comment.
>
Thanks, it’s in my queue,
Paul.
> On 26 Jan 2016, at 16:51, Tagir F. Valeev wrote:
>
> Hello!
>
> Thank you for review! Here's the issue:
> https://bugs.openjdk.java.net/browse/JDK-8148250
> Will post complete webrev later.
>
> PS> Note that it is still the case that in almost all scenarios this
> PS> is likely to be a bad f
Hi,
API changes l and security check look good to me. I don't have time to compile
and test a JDK, but I trust you that it works :-)
Uwe
-
Uwe Schindler
uschind...@apache.org
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -Original Message-
>
Latest webrev updated in-place:
http://cr.openjdk.java.net/~chegar/8148117/
* to execute the run method requires an appropriate permission
* reverted any copyright changes ( leave to a bulk update )
* updated the test to remove the script
-Chris.
On 26 Jan 2016, at 15:23, Alan Bateman wro
On 26 Jan 2016, at 16:36, Roger Riggs wrote:
> Hi Chris,
>
> Looks good, thanks for updating the test.
>
> One typo:
> "Unexpected exist
> code”
D’oh. Fixed in-place.
-Chris
> Roger
>
>
>
> On 1/26/2016 11:27 AM, Chris Hegarty wrote:
>> Latest webrev updated in-place:
>>
>> http://
Hi Chris,
Looks good, thanks for updating the test.
One typo:
"Unexpected *exist *code" Roger
On 1/26/2016 11:27 AM, Chris Hegarty wrote:
Latest webrev updated in-place:
http://cr.openjdk.java.net/~chegar/8148117/
* to execute the run method requires an appropriate permission
* rever
On 1/26/16 4:28 AM, Alan Bateman wrote:
On 26/01/2016 04:57, Mikael Vidstedt wrote:
I've finally found some time to return to this and have a new version
of the patch which looks more promising:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/
This uses memcpy to read/
Hello!
Thanks for review! Updated webrev:
http://cr.openjdk.java.net/~tvaleev/webrev/8147505/r2/
Removed redundant test and added a comment.
With best regards,
Tagir Valeev.
PS> Hi Tagir,
PS> StreamCloseTest.java
PS> —
PS> 181 try(Stream s = countTo(100).stream()) {
PS> 182
Hello!
Thank you for review! Here's the issue:
https://bugs.openjdk.java.net/browse/JDK-8148250
Will post complete webrev later.
PS> Note that it is still the case that in almost all scenarios this
PS> is likely to be a bad form of parallel stream.
Well not always it's possible to estimate in ad
Hi
Many thanks for the feedback so far.
Some high-level responses:
1) I don’t think there is much we can do right now to reduce the verbosity of
reflective lookup. We have discussed this at least once before in the past. We
need field literals, as mentioned in the JEP, to really knock this on
On 26/01/2016 13:55, Chris Hegarty wrote:
It is wonderful to see the various ideas on this thread about the longer
term solution to the prompt releasing of direct buffer native memory. I
do not want to obstruct that ( it is very informative ), but I’d like to warp up
the review on the actual movi
Hi Chris,
Looks fine.
Perhaps update the copyrights.
Upgrading the shell based test to java based would be good sometime too.
Also, there is a more recent version of webrev [1] that provides
convenient next and previous links.
Thanks, Roger
[1] http://hg.openjdk.java.net/code-tools/webrev/
Hi,
> On 26/01/2016 14:05, Uwe Schindler wrote:
> > Hi,
> >
> > looks good to me. Once we have EA builds with that I will adapt the
> ByteBufferIndexInput code in Lucene.
> >
> > One thing about the Runable: This should work perfectly fine, because we
> only need to make call the getCleaner() meth
On 26/01/2016 14:05, Uwe Schindler wrote:
Hi,
looks good to me. Once we have EA builds with that I will adapt the
ByteBufferIndexInput code in Lucene.
One thing about the Runable: This should work perfectly fine, because we only
need to make call the getCleaner() method accessible, call it
Hi,
looks good to me. Once we have EA builds with that I will adapt the
ByteBufferIndexInput code in Lucene.
One thing about the Runable: This should work perfectly fine, because we only
need to make call the getCleaner() method accessible, call it and finally check
if return type implements R
> On 23 Jan 2016, at 21:31, Andrew Haley wrote:
>
> BTW, does anyone here know why we don't have humongous ByteBuffers
> with a long index?
>
Probably in part because of Java arrays. IMO we need Arrays 2.0 (+ panama i
suspect).
Here’s some "shoot from the hip" thinking…
In principle a direc
It is wonderful to see the various ideas on this thread about the longer
term solution to the prompt releasing of direct buffer native memory. I
do not want to obstruct that ( it is very informative ), but I’d like to warp
up
the review on the actual moving of Cleaner. To that end, I’ve update th
While there is no blockng reason why the concept could not be pulled up to
ChronoLocalDate, the method signatures would differ.
LocalDate::datesUntil(LocalDate)
LocalDate::datesUntil(LocalDate, Period)
ChronoLocalDate::datesUntil(ChronoLocalDate)
ChronoLocalDate::datesUntil(ChronoLocalDate, Chron
> On 25 Jan 2016, at 18:47, Xueming Shen wrote:
>
> The proposed change looks fine with me.
>
Yes, +1 nice work.
Paul.
Hi Hamlin,
Conservatively I would prefer not to remove data sets if at all possible. It
will affect all tests, and leaf tasks for parallel streams should have enough
data to crunch on.
I suspect the problem of the flatMap test is not necessarily due to the source
sizes being of 1000 elements b
Looks fine to me Chris.
Regards,
Sean.
On 26/01/2016 12:27, Chris Hegarty wrote:
The test groups, that make up jdk_core, should be updated to include
jdk/internal/math and jdk/internal/misc. These updates were overlooked
when doing re-orgaziation and cleanup in preparation for JEP 260.
diff --
Hi Martin,
sorry for jumping on this conversation lately,
please don't be seduced by the dark side,
I understand that the code is 1 byte bigger, but i think that the following code
final int s = this.size;
Object[] elementData = this.elementData;
if (s == elementData.length) {
elementD
Hi Remi,
this is what I am doing. At least using Byte Buddy, you turn a switch
such that Byte Buddy redefines the LambdaMetafactory to spin custom
classes where Byte Buddy also applies a ClassFileTransformer.
Currently this results in the (almost) exact class file as if the
default LambdaMetafacto
what bothers me about instrumenting a lambda expression's target
method is the difficulty of locating the method that contains the code
and setting it into context. This is a lot of work to do since one
needs to first locate any invokedynamic call sites and interpret the
connection via the LambdaM
On 26/01/2016 04:57, Mikael Vidstedt wrote:
I've finally found some time to return to this and have a new version
of the patch which looks more promising:
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/
This uses memcpy to read/write the native data and the preliminary
The test groups, that make up jdk_core, should be updated to include
jdk/internal/math and jdk/internal/misc. These updates were overlooked
when doing re-orgaziation and cleanup in preparation for JEP 260.
diff --git a/test/TEST.groups b/test/TEST.groups
--- a/test/TEST.groups
+++ b/test/TEST.gro
Hi Rafael,
why not providing a LambdaInterceptor as asked ?
My point is that a lambda should be considered as a feature by itself instead
as a way to create a class that implement an interface at runtime.
If you do that, your code will still work when future release (maybe a point
release), th
Hi Tagir,
It is insane :-) in hindsight i cannot believe i missed this trick!
You patch looks reasonable and i don’t see any issue with it. Each leaf-task
will collect at most n elements. The truncation will take care of everything
else.
Note that it is still the case that in almost all scenar
Hi Tagir,
StreamCloseTest.java
—
181 try(Stream s = countTo(100).stream()) {
182 s.map(x -> x).forEach(i -> {});
183 checkISE(() -> s.onClose(() -> fail("2")));
184 }
We don’t need this one, it’s redundant. The other performing the s.close() is i
thin
Hi Tagir,
Looks good. Just small things.
FindOps.java
—
293 if (!this.mustFindFirst) {
310 if (this.mustFindFirst) {
Small thing, no need for “this”.
LambdaTestHelpers
—
404 public static void assertContains(Optional actual, Iterator
it) {
405 if (
Maybe this is a more graphic example of a problem that end-users
currently face:
http://stackoverflow.com/questions/33912026/intercepting-calls-to-java-8-lambda-expressions-using-byte-buddy
2016-01-26 10:02 GMT+01:00 :
> Hello,
>
> - Mail original -
>> De: "Rafael Winterhalter"
>> À: "Re
Hi Christoph,
Instead of trying to access
com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java in your
test - would it be possible for
your test to embed that functionality instead?
I am not sure how much sense that makes - the workings of that
class seemed a bit convoluted - and not
On 26/01/16 04:57, Mikael Vidstedt wrote:
>
> I've finally found some time to return to this and have a new version of
> the patch which looks more promising:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/
>
> This uses memcpy to read/write the native data and the prel
Hello,
- Mail original -
> De: "Rafael Winterhalter"
> À: "Remi Forax"
> Cc: "Vladimir Ivanov" , "Coleen Phillimore"
> ,
> core-libs-dev@openjdk.java.net, "serguei.spit...@oracle.com Spitsyn"
> , "Daniel
> Daugherty"
> Envoyé: Lundi 25 Janvier 2016 20:24:01
> Objet: Re: ClassFileTrans
On 26/01/16 08:39, Rafael Winterhalter wrote:
> Another note on this subject: I found that applying a
> reretransformation on a lambda expression's class does not provide the
> original class file to the retransformer but the class file that
> resulted from a previous retransformation. (If a lambda
Another note on this subject: I found that applying a
reretransformation on a lambda expression's class does not provide the
original class file to the retransformer but the class file that
resulted from a previous retransformation. (If a lambda class is
retransformed several times.) This is differ
55 matches
Mail list logo
