Hi Vicente,
I recall an (internal?) discussion about updating ASM somewhen in JDK 11TF, and
AFAIR it was decided not to update ASM b/c nothing in JDK needs that, has it
been changed? put somewhat differently, why are we doing this?
in any case, I don't like the changes in mlvm tests. I
On 07/11/2018 16:42, Enrico Olivelli wrote:
Hi,
I am investigating this case about PowerMock, which is not able to
remove the 'final' modifier from a Field
https://github.com/powermock/powermock/issues/939
Is there any suggested alternate way to remove such modifier ?
I understand clearly that
Also, you might want to take a look at JLS 13.4.9 "final Fields and Constants".
Primitive static final constants can be folded at compile time, so even if you
were able to change it at runtime, it wouldn't have any effect...
Thanks,
Andrew
-Original Message-
From: core-libs-dev On
Hi Andrew,
I am Lead for Hotspot [1]. Alan is Group Lead for core libs and he gave review
already.
I don't see any reference to Hotspot in JEP so I am not sure what to review. Do you need any new
optimizations/intrinsics in Hotspot for this JEP?
You need to ask Alan or Brian Goetz (as Area
Thanks Ivan!
I agree that the upfront edge case checks aren't really necessary, after
all, the great majority of the use cases won't hit the edge case (with
the size being a factor of the buffer). We're therefore better off
without the checks.
Here's an updated webrev:
Hi,
I am investigating this case about PowerMock, which is not able to
remove the 'final' modifier from a Field
https://github.com/powermock/powermock/issues/939
Is there any suggested alternate way to remove such modifier ?
I understand clearly that it is against how the JVM works and I really
Thank you Joe!
I like the last variant.
With kind regards,
Ivan
On 11/7/18 9:59 AM, Joe Wang wrote:
Thanks Ivan!
I agree that the upfront edge case checks aren't really necessary,
after all, the great majority of the use cases won't hit the edge case
(with the size being a factor of the
Hi,
being aware that there has been a discussion quite some time ago (
http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003768.html)
I wanted to come up again with this topic as this feature would be
beneficial especially for framework developers who wants to appoint
behaviour to
Hi Roger
On 11/6/18 8:17 AM, Roger Riggs wrote:
While working to reduce startup time initializing properties, a pair
of improvements are proposed.
8185496: Improve performance of system properties initialization in
initPhase1 [1]
8213424: VersionProps duplicate initialization [2]
1) The
Hello!
I see myself having to often call count() as a terminal operation on a
Stream immediately after performing a filter operation. How feasible would
it be to add an overloaded count() method that accepts a Predicate, which
it uses as a filter before returning the count of elements in the
Hi Daniel,
> On Nov 7, 2018, at 3:49 AM, Daniel Fuchs wrote:
>
> I am not sure whether you can trust that a skip implementation
> that returns -1 has actually rewind 1 byte - for instance:
>
>
Hi Igor,
On 11/7/18 2:33 PM, Igor Ignatyev wrote:
Hi Vicente,
I recall an (internal?) discussion about updating ASM somewhen in JDK
11TF, and AFAIR it was decided not to update ASM b/c nothing in JDK
needs that, has it been changed? put somewhat differently, why are we
doing this?
we need
Hi Vicente,
All of the javadoc comment reformatting makes it nearly impossible to
see the actual substantive changes :(
ASM 7 also supports the Nestmate attributes and I was trying to see
how/where that appeared but its somewhat obscure. Oh well.
Is it that case that the code the uses the
findFirst(Predicate predicate) would be nice too
чт, 8 нояб. 2018 г. в 8:01, Jacob Glickman :
> Hello!
>
> I see myself having to often call count() as a terminal operation on a
> Stream immediately after performing a filter operation. How feasible would
> it be to add an overloaded count()
Hi Naoto,
Thanks for reviewing the fix. As you mentioned in review comment, I will add
the copyright year 2018 in test case.
Regards,
Deepak
-Original Message-
From: Naoto Sato
Sent: Monday, November 5, 2018 11:58 PM
To: Deepak Kejriwal ; core-libs-dev
; i18n-...@openjdk.java.net
Hi Brian,
I am not sure whether you can trust that a skip implementation
that returns -1 has actually rewind 1 byte - for instance:
http://hg.openjdk.java.net/jdk/jdk/file/44f34d2c3243/src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java#l99
Not sure there's anything
> Sorry, I haven't had time to look at this in more detail yet. But, let's
> take a step back first. Can you or Matthias explain in more detail why
> this fix is necessary? What are the use cases and motivation?
Hello,
adding paths (or maybe more details) to exception messages just makes
On 07/11/2018 13:13, Jaikiran Pai wrote:
:
My impression, based on that javadoc, was that the implementation of
that API will use the underlying _filesystem_ to decide whether or not
its case sensitive. However, my experiments on a macOS which is case
insensitive and also a basic check of the
On 06/11/18 10:17, Andrew Dinn wrote:
> Ping!
>
> Is it possible to get a response on this.
>
> To summarise: I am happy to rename isPersistent to isSync and/or make it
> private as well as change the enum tags to use SYNC instyead of
> PERSISTENT if that is what is needed to get the JEP
In one of the projects that I'm involved in, we do a bunch of file
operations which sometimes need to check if a particular filesystem is
case sensitive. I was thinking of using java.io.File#equals since its
javadoc states:
/**
* Tests this abstract pathname for equality with the given
Hi,
by providing a LambdaFormEditor transform which applies the same filter
repeatedly on some selected arguments, we can optimize for cases where
there are repeated conversions. This allows the runtime to optimize the
internal setup of public API methods such as
Hi Alan,
On 07/11/18 7:15 PM, Alan Bateman wrote:
> On 07/11/2018 13:13, Jaikiran Pai wrote:
>> :
>>
>>
>> My impression, based on that javadoc, was that the implementation of
>> that API will use the underlying _filesystem_ to decide whether or not
>> its case sensitive. However, my experiments
Hi Jaikiran,
To check if two pathnames are the same file,
java.nio.file.Files.isSameFile(path1, path2)
is cleaner. It uses the file system specific mechanisms to determine if
the two paths
refer to the identical file. Traversing symbolic links, etc.
Something like:
Path dir =
Hi,
Version 7.0 of ASM has been released. This version supports condy, yay!,
and we want to include it in JDK 12. Please review [1] which includes:
- the new version perse substituting the preview ASM internal version in
the JDK
- changes to additional files in particular some tests, mostly
Hello Roger,
That indeed is a much cleaner approach. Thank you for that example.
-Jaikiran
On 07/11/18 8:37 PM, Roger Riggs wrote:
> Hi Jaikiran,
>
> To check if two pathnames are the same file,
> java.nio.file.Files.isSameFile(path1, path2)
> is cleaner. It uses the file system specific
Hi Ilya,
If you are contributing on behalf of your organization, then a person
authorized to sign document on behalf of your organization (usually a VP
or higher) must sign the OCA, indicating his or her title, for the
organization. If you intend to (also) contribute changes individually,
26 matches
Mail list logo
