Since you're OK with doing brain surgery on the JDK and you control the
entire process, consider controlling your daemon with a bytecode rewriting
agent (e.g. byteman) that changes the definition of System.getenv etc.
(Whose side are you on Martin?! ... I confess I also wish for a faster
gradle .
Looks good.
---
I suspect there's some way to specify the styles more compactly, but I
don't know enough css to say.
---
+table.borderless thead tr th, table.borderless tbody tr th,
table.borderless tr th,
+table.plain > thead > tr > th, table.plain > tbody > tr > th, table.plain
> tr > th,
I
Hi Cedric,
Like Martin I am somewhat surprised by the recent surge in interest in
the JVM environment :)
From a pragmatic perspective it is far too late to do anything about
this in 9.
I am curious what kind of environment variables are being set by the
client, how they are shared with the
Looks good.
Mandy
> On May 10, 2017, at 5:36 PM, Jonathan Gibbons
> wrote:
>
> Mandy,
>
> I have fixed the tables you noted.
>
> jdk (changes to java.base):
> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.02/
>
> API showing the effect of these changes:
> http://cr.openjdk.
Mandy,
I have fixed the tables you noted.
jdk (changes to java.base):
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.02/
API showing the effect of these changes:
http://cr.openjdk.java.net/~jjg/8179479-8179592/api.02/java.base-summary.html
-- Jon
On 05/10/2017 03:50 PM, Mand
> On May 5, 2017, at 3:52 PM, Jonathan Gibbons
> wrote:
>
> This is an updated review for the changes to improve tables in java.base.
> :
> Webrevs:
>
> langtools (the stylesheet):
> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/
>
> jdk (changes to java.base):
> http://cr
> On 10 May 2017, at 13:46, Ron Pressler wrote:
>
> Hi.
> Please review the following doc-only patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180075
>
> There is no change in specification, only an elaboration on a note.
>
+1
Paul.
> Ron
>
>
>
> diff -r fc53a0468c1f
> sr
You're already acquiring superpowers and voiding any warranty by calling
putenv from JNI. Why not go further and do your reflective shenanigans via
JNI as well? In practice, if hotspot has started up and only one java
thread is doing anything, putenv is unlikely to cause a crash (and probably
non
+1
The missing space after the ‘c’ was hard to “see.”
Brian
On May 10, 2017, at 3:04 PM, Lance Andersen wrote:
> Looks fine Stuart
>> On May 10, 2017, at 6:02 PM, Stuart Marks wrote:
>>
>> Hi all,
>>
>> Please review a couple really small fixes to the String javadoc.
>>
>> 1) The String(by
Looks fine Stuart
> On May 10, 2017, at 6:02 PM, Stuart Marks wrote:
>
> Hi all,
>
> Please review a couple really small fixes to the String javadoc.
>
> 1) The String(byte[], int, int, int) constructor refers to converting bytes
> to chars as specified "in the method above" except that the me
Hi all,
Please review a couple really small fixes to the String javadoc.
1) The String(byte[], int, int, int) constructor refers to converting bytes to
chars as specified "in the method above" except that the method "above" has
never converted bytes to chars as far as I can see. It really shou
It seems to be the day for environment variable mutation.
System.getenv was always designed as an immutable snapshot, and more
recently there's emerging consensus that one must never ever mutate
environment variables in a multi-threaded Unix program. One tends to
acquire a biased view on this aft
Hi all,
I'm writing this on behalf of the Gradle team. This email is closely
related to the other thread just posted today, but just a timeline
coincidence (just like the email exchange I had today about this with Alan
Bateman ;)) and not exactly the same issue.
We are in the process of making su
Hi Roger,
Looks all right to me. I assume you will have already built the actual docs and
clicked through the updated links. Always a bit painful …
Thanks,
Brian
On May 10, 2017, at 11:22 AM, Roger Riggs wrote:
> Please review corrections to broken javadoc links:
> - links to the serializati
Thank you.
Your comments, and Paul's, have all been addressed in a revised patch
(same webrev).
Ron
On 08/05/2017 08:30, David Holmes wrote:
Hi Ron,
On 6/05/2017 5:27 AM, Ron Pressler wrote:
Hi,
Please review the following core/hotspot change:
Bug: https://bugs.openjdk.java.net/browse/JDK
Hi.
Please review the following doc-only patch.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180075
There is no change in specification, only an elaboration on a note.
Ron
diff -r fc53a0468c1f
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/java.base/share/cl
Good point, I was nervous that there may have been a reason for not
closing the connection and completely overlooked the obvious.
http://cr.openjdk.java.net/~robm/8175131/webrev.02/
Thanks,
-Rob
On 10/05/17 03:38, Roger Riggs wrote:
> Hi Rob,
>
> If an exception is thrown in createConnecti
Hi Rob,
If an exception is thrown in createConnection, it can't return the
connection that was created
and so it should close it.
I would close the connection at line 298, before throwing the exception.
Roger
On 5/10/2017 3:25 PM, Rob McKenna wrote:
Hi folks,
Looking for a review of the fo
Hi folks,
Looking for a review of the following simple change:
https://bugs.openjdk.java.net/browse/JDK-8175131
http://cr.openjdk.java.net/~robm/8175131/webrev.01/
Note: I've deliberately limited the connection closure to the described
case. If however you feel that it should be applied generall
Hello,
Please review HTML5 related changes to the above modules, please
note there are no changes to the verbiage.
Thanks
Kumar
Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
On 10/05/2017 01:58, Jonathan Gibbons wrote:
Another review for HTML 5 fixes, this time in the java.corba module.
As usual, changes are just to the markup, and not to any specification
text.
JBS: https://bugs.openjdk.java.net/browse/JDK-8180041
Webrev: http://cr.openjdk.java.net/~jjg/8180041
Hi All,
Please review fixes to make the API doc comments HTML5 clean,
there are no changes to the verbiage, and mostly fixes for the table
styles defined here:
http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ee84b7d44339
For tables with many entries I have used "striped", there are few
tables
> On May 10, 2017, at 11:22 AM, Roger Riggs wrote:
>
> Please review corrections to broken javadoc links:
> - links to the serialization spec now in ./specs/serialization
> - links in java.lang to java/util/Spliterator
> - link in ModuleLayer to Classloader
> - Links using ../../../.. do not wor
Please review corrections to broken javadoc links:
- links to the serialization spec now in ./specs/serialization
- links in java.lang to java/util/Spliterator
- link in ModuleLayer to Classloader
- Links using ../../../.. do not work well when they show up in some
indexes; they should use @d
Hi,
I would like to still propose this note for 9, we ain’t gonna resolve the
underlying issue in 9.
It’s currently an api note but it’s more appropriate as an implementation note
(e.g. Ephemerons might help).
We could amend the note with Peter’s suggestion as follows:
@implNote
Care should
Hi,
Looks good. Some minor comments.
Paul.
src/share/vm/classfile/vmSymbols.cpp
—
A prior bug: in the original code the case statements for the
_weakCompareAndSwapLongVolatile were missing, so we need to add:
case vmIntrinsics::_weakCompareAndSeLong
etc.
I think this is mostly benign as
On 5/9/17 4:39 PM, Brent Christian wrote:
On 5/9/17 4:27 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
Can it restore to the default timeout?
Yes. Between the additional @runs and no longer testing automated
modules, I believe that should be fine.
On 10/05/2017 14:33, Andrew Guibert wrote:
:
I need to check with my management to get all the legal approvals
before proposing a patch, so it might take a while. Since it's likely
a very small code change I won't be offended if someone else proposes
the patch for me =)
I don't see too ma
More info at
https://bugs.openjdk.java.net/browse/JDK-8173654
On Wed, May 10, 2017 at 6:47 AM, Roger Riggs wrote:
> providing an unused
> facility to provide access to binary values in the environment.
>
>
The design was to not modify environment variables passed to children even
if they conta
Hi,
I'm not sure I have all the history.
The current implementation seems more complicated than necessary
by trying to avoid copying when not necessary and providing an unused
facility to provide access to binary values in the environment.
On 5/10/2017 9:30 AM, pie...@2bst.fr wrote:
Hi, I've be
> From: Alan Bateman
> To: Andrew Guibert , core-libs-dev@openjdk.java.net
> Date: 05/10/2017 07:32 AM
> Subject: Re: Proposal:
> javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()
>
> On 08/05/2017 23:27, Andrew Guibert wrote:
>
> > :
> >
> > I am not sure why the "no resetting"
Hi, I've been trying to understand how the JVM accesses environment
variables and how they can be mutated.
I sent an email about this list few hours ago on the general-purpose
discuss mailing-list but it appears it would be better posted herein.
For this I've made some assumptions and I would li
On 08/05/2017 23:27, Andrew Guibert wrote:
:
I am not sure why the "no resetting" restriction is on the NamingManager
API in the first place. Is anyone aware why the API has this restriction?
In any case, the solution outlined above seems rather messy (as it only
solves the problem by mitigati
looks fine jon
> On May 9, 2017, at 8:58 PM, Jonathan Gibbons
> wrote:
>
> Another review for HTML 5 fixes, this time in the java.corba module.
>
> As usual, changes are just to the markup, and not to any specification text.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180041
> Webrev: h
34 matches
Mail list logo
