Hi All
Would you like to review the code change for bug:
https://bugs.openjdk.java.net/browse/JDK-8061293, this is a Jigsaw related
bug, it's to clean up the reference to "jre" dir.
webrev: http://cr.openjdk.java.net/~fyuan/8061293/webrev/
Best Regards
Frank
I'm only glancing at parts of this ...
On 5/03/2015 6:21 AM, Andrew Haley wrote:
John's suggestion works well; the code is smaller and neater.
http://cr.openjdk.java.net/~aph/unaligned.jdk.3/
This doesn't make sense to me:
929 // The byte ordering of this machine
930 public final s
On 3/4/2015 1:46 PM, Lance Andersen wrote:
Hi Joe,
A couple other very minor suggestions to consider assuming -Xdoclint
is clean:
- Your new changes just use where the older code used .
It would be nice if we can to be consistent if you have the time. I
think a while a go it was dec
On 3/4/2015 1:15 PM, Alan Bateman wrote:
On 04/03/2015 19:50, huizhe wang wrote:
Hi,
This is the additional specification change after the move from lib
to conf in the jigsaw/m2 forest. Besides the change from lib to conf,
the new specification also made the reference to the location
non-no
On 3/4/15 12:31 AM, Alan Bateman wrote:
On 03/03/2015 23:05, Stuart Marks wrote:
Updated webrev:
http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.2/
This looks good. Minor re-wording suggestions, ignore if you want:
"... reference to an open XXX, which is closed by ..."
=> "..
Hi Joe,
A couple other very minor suggestions to consider assuming -Xdoclint is clean:
- Your new changes just use where the older code used . It would
be nice if we can to be consistent if you have the time. I think a while a go
it was decide that was the way to go.
- In some cases you
I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.
I do want to mention that some libs like liblcms are 3rd party open
source libraries
and it may not always be possible to convince upstream to change their code.
-phil.
On 03/04/2015 08:30 AM
On 04/03/2015 19:50, huizhe wang wrote:
Hi,
This is the additional specification change after the move from lib to
conf in the jigsaw/m2 forest. Besides the change from lib to conf, the
new specification also made the reference to the location non-normative.
Please review:
http://cr.openjdk.
On 3/4/15 11:14 AM, Chris Hegarty wrote:
On 4 Mar 2015, at 18:10, Stuart Marks wrote:
Hi Chris,
Instead of creating a socket factory for this purpose, this test can use RMI's test
library TestLibrary.createRegistryOnUnusedPort(). Now, internally, this uses the now
disfavored "getUnusedRand
John's suggestion works well; the code is smaller and neater.
http://cr.openjdk.java.net/~aph/unaligned.jdk.3/
http://cr.openjdk.java.net/~aph/unaligned.hotspot.3/hotspot.patch
Andrew.
Hello !
The javac team is pleased to inform you that the compiler support for
private methods in interfaces
has been released through here:
JBS: https://bugs.openjdk.java.net/browse/JDK-8071453,
HG: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/592d64800143
into the JDK9 dev stream.
This
Hi,
This is the additional specification change after the move from lib to
conf in the jigsaw/m2 forest. Besides the change from lib to conf, the
new specification also made the reference to the location non-normative.
Please review:
http://cr.openjdk.java.net/~joehw/jdk9/8049378/webrev/
Bug
Stephen and Roger,
This is the DTF.appendZoneOrOffsetId() issues we discussed last year. Somehow
the
ball was dropped somewhere :-)
Here is the proposed change we discussed. The only difference is I leave the
ZoneOffset
to throw the DateTimeException, instead of inside the Parsed.query() direc
> On 4 Mar 2015, at 18:10, Stuart Marks wrote:
>
> Hi Chris,
>
> Instead of creating a socket factory for this purpose, this test can use
> RMI's test library TestLibrary.createRegistryOnUnusedPort(). Now, internally,
> this uses the now disfavored "getUnusedRandomPort" pattern, but it can (a
> On 4 Mar 2015, at 17:56, Stuart Marks wrote:
>
> Hi Chris, Roger,
>
> Just as a background, the loop with System.gc() and sleep() was arrived at
> via review comments between Eric Wang and David Holmes. See this thread:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/0105
java.text.SimpleDateFormat.parse does not recognize time zone ids.
new SimpleDateFormat("-MM-dd HH:mm:ss
").parse("2015-03-03 09:25:00 America/Los_Angeles")
does not recognize "America/Los_Angeles" as a time zone.
"America/Los_Angeles" is a time zone id and the "" format looks
Hi Chris,
Instead of creating a socket factory for this purpose, this test can use RMI's
test library TestLibrary.createRegistryOnUnusedPort(). Now, internally, this
uses the now disfavored "getUnusedRandomPort" pattern, but it can (and should)
be changed to avoid this. In, fact, passing 0 wil
Hi Chris, Roger,
Just as a background, the loop with System.gc() and sleep() was arrived at via
review comments between Eric Wang and David Holmes. See this thread:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010592.html
which continued here:
http://mail.openjdk.java.net/p
Magnus:
Looks good to me as well.
Tim
On 03/04/15 05:31, Erik Joelsson wrote:
Hello,
Really nice to finally see this patch getting done!
Only one comment:
flags.m4:
In the grep expression, could you move the extra [] outside of the
actual command line options to grep so that the command li
On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
I believe all warnings are important to check! Unfortunately, this has
not been done for a lot of warnings for a lot of time. :(
Right, although in the past we had some areas close to be cleared of
warnings, it's just that we didn't keep up the effo
On 04/03/15 15:58, Roger Riggs wrote:
Hi Chris,
ok, though if System.gc is good enough it would not need a loop and
timeout logic.
Ah ok, so some common library function taking a Predicate, or similar. I
got you now.
It would be interesting to know if it ever needs to go through the loop
m
Thanks, looks fine to me.
Roger
On 3/4/2015 10:53 AM, Chris Hegarty wrote:
On 04/03/15 15:26, Roger Riggs wrote:
Hi Chris,
Is the choice of as the ephemeral port ok?
It should be, or it could be any positive integer value.
Though it is artificial is there any chance it will be confus
Hi Chris,
ok, though if System.gc is good enough it would not need a loop and
timeout logic.
It would be interesting to know if it ever needs to go through the loop
more than once.
Maybe some indication of that can be added to the test output.
Thanks, Roger
On 3/4/2015 10:57 AM, Chris Heg
On 04/03/15 15:17, Roger Riggs wrote:
Hi Chris,
looks fine.
Thanks Roger.
Do you suppose the test library should have a function that takes a set
of (Weak)Refs
and does whatever it takes to clear them (or timeout).
Well, the problem is: What is "whatever it takes"? The changes in this
tes
On Mar 4, 2015, at 4:35 PM, Andrew Haley wrote:
> On 03/04/2015 03:07 PM, Paul Sandoz wrote:
>
>> If so then presumably that would be applicable to both get* and
>> set*?
>
> I think so.
>
>> Could those boolean accepting methods be intrinsified or would they
>> always be Java only?
>
> Sure
On 04/03/15 15:26, Roger Riggs wrote:
Hi Chris,
Is the choice of as the ephemeral port ok?
It should be, or it could be any positive integer value.
Though it is artificial is there any chance it will be confused with a
real port?
There should be no confusion since the test is providin
On 03/04/2015 03:07 PM, Paul Sandoz wrote:
> If so then presumably that would be applicable to both get* and
> set*?
I think so.
> Could those boolean accepting methods be intrinsified or would they
> always be Java only?
Sure, but I've been wondering if it's necessary. Suppose we had some
hyp
Hi Chris,
Is the choice of as the ephemeral port ok?
Though it is artificial is there any chance it will be confused with a
real port?
Would a negative number (or zero) work just as well for this purpose?
Or does it get rejected in one of the layers it has to pass through.
typo: "supp
On 03/04/2015 02:29 PM, Andrew Haley wrote:
>> My inclination is to remove the get*Unaligned(..., boolean
>> bigEndian) methods and thereby consistently use Bits.swap in the
>> heap buffer. A similar pattern applies for float/double conversion.
>
> I suggest that you and John argue that between you
Hi Chris,
looks fine.
Do you suppose the test library should have a function that takes a set
of (Weak)Refs
and does whatever it takes to clear them (or timeout).
Perhaps even a public API in Runtime...
Roger
On 3/4/2015 9:59 AM, Chris Hegarty wrote:
This is a small, test only, review reque
On Mar 4, 2015, at 3:29 PM, Andrew Haley wrote:
> On 03/04/2015 02:15 PM, Paul Sandoz wrote:
>
>> The flag UseUnalignedAccesses feels a little awkward. IIUC it seems
>> to be acting as two things, a flag signalling an unaligned
>> architecture and a developer option to disable/enable unaligned
On 2015-03-04 14:48, Alan Bateman wrote:
On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
:
I intend to file individual bugs to handle these remaining warnings,
so the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has
had w
This is a small, test only, review request to fix an intermittently
failing test.
It replaces a "bad" technique, heap exhaustion, with the "less bad"
technique of calling System.gc, potentially multiple times, to clear
weak references. With this change the test runs much quicker, and has
not
This is a small, test only, review request to fix an intermittently
failing test.
There is an inherent race, and possible failure, following the
getUnusedRandomPort pattern. This test can be modified to use a custom
socket factory, supporting listening on an ephemeral port, without
changing t
On 03/04/2015 02:15 PM, Paul Sandoz wrote:
> The flag UseUnalignedAccesses feels a little awkward. IIUC it seems
> to be acting as two things, a flag signalling an unaligned
> architecture and a developer option to disable/enable unaligned
> intrinsics. Should this flag even be allowed to be set
On Mar 2, 2015, at 8:30 PM, Andrew Haley wrote:
> On 02/25/2015 04:43 PM, Andrew Haley wrote:
>> On 02/24/2015 11:18 PM, John Rose wrote:
>>> My bottom line: I think we should use the internal HotSpot
>>> API bytes.hpp by surfacing relevant parts of it up into Unsafe.
>
> I have done this exce
On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
:
I intend to file individual bugs to handle these remaining warnings,
so the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has
had warnings disabled. I expect the outcome of
Hello,
Really nice to finally see this patch getting done!
Only one comment:
flags.m4:
In the grep expression, could you move the extra [] outside of the
actual command line options to grep so that the command line could be
copied to the shell for debugging in the future? Also, how hard would
When building the native code in the jdk repo, a lot of warnings are
generated. So many that it's hard to spot any new issues.
While the ultimate goal must be to address and fix these warnings
individually, this bug is about disabling these warnings where they
occur, so that it is easier to sp
Thanks Alan, thanks Martin!
Sincerely yours,
Ivan
On 03.03.2015 23:24, Alan Bateman wrote:
On 03/03/2015 18:39, Ivan Gerasimov wrote:
:
http://cr.openjdk.java.net/~igerasim/8074067/2/webrev/src/java.base/share/native/libjava/Bits.c.sdiff.html
I think you are good to go too.
-Alan
On 03/03/15 20:48, John Rose wrote:
> On Mar 2, 2015, at 11:30 AM, Andrew Haley wrote:
>>
>> On 02/25/2015 04:43 PM, Andrew Haley wrote:
>> I have done this as much as is possible, but methods which assemble
>> and split sub-words are necessarily endian-dependent. I have
>> separated the native b
On 03/03/2015 23:05, Stuart Marks wrote:
:
Updated webrev:
http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.2/
This looks good. Minor re-wording suggestions, ignore if you want:
"... reference to an open XXX, which is closed by ..."
=> "... reference to an open XXX. The XXX is
42 matches
Mail list logo
