Thanks David,
I'd originally considered something like that, but I later realised I'd
need to grant DeserializationPermission to other domains I might not
want allow objects to be deserialized with, simply because their domain
is included in the call stack. It looked like it would widen the s
> On Feb 11, 2016, at 6:04 AM, Chris Hegarty wrote:
>
> In preparation for JEP 260, InnocuousThread should be moved out of the
> sun.misc package and placed into a more appropriate package where it
> can be encapsulated.
>
> http://cr.openjdk.java.net/~chegar/8149653/
Looks good.
Mandy
Hi Igor,
The change to the test list in and of itself looks fine. Once some
stable subset of the svc tests can be committed to, it would be good to
have them back in tier 2.
Thanks,
-Joe
On 2/11/2016 1:03 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev/8149700/webrev.00/
2
http://cr.openjdk.java.net/~iignatyev/8149700/webrev.00/
>
> 2 lines changed: 0 ins; 1 del; 1 mod;
Hi all,
could you please review the tiny patch which removes jdk_svc test group from
tier2 test group? Many of svc tests fail intermittently due to different
reasons, that prevents us from having
Hi all,
Please review a fix for
Bug Id https://bugs.openjdk.java.net/browse/JDK-8032051
webrev http://cr.openjdk.java.net/~ntv/8032051/webrev.01/
--
Thanks and Regards,
Nadeesh TV
Hi Iris,
The change looks good.
Two of the previously included classes appeared twice in the webrev
index page :-)
Thanks,
Joe
On 2/11/2016 11:06 AM, Iris Clark wrote:
Hi.
A private review comment as noted that I missed a few files in the jaxp
repository.
The webrev has been updated in p
Hi, Chris.
>> http://cr.openjdk.java.net/~iris/verona/8149601/webrev/
>
> Looks fine.
Thanks for the Review.
Regards,
Iris
Hi.
A private review comment as noted that I missed a few files in the jaxp
repository.
The webrev has been updated in place.
Thanks,
iris
-Original Message-
From: Iris Clark
Sent: Thursday, February 11, 2016 9:13 AM
To: [email protected]; [email protected]
Cc:
Currently the pendulum is swinging away from multiple applications
sharing common libraries towards every application being
self-contained, perhaps because disk space is dirt cheap and because
of the rise of "containers". It may be that much of the packaging of
jdks will be picked up by third part
On 11 Feb 2016, at 17:13, Iris Clark wrote:
> Hi.
>
> Please review the following changes to the jaxp and jdk
> repositories to fix a few additional references to "1.9".
>
> Bug
>
> 8149601 Update references from "1.9" to "9"
> https://bugs.openjdk.java.net/browse/JDK-8149601
>
> Webrev
>
Am Mittwoch, 10. Februar 2016, 14:03:44 schrieben Sie:
> On 9/02/2016 5:29 AM, Thomas Kamps wrote:
> > Hi everyone,
> >
> > Did you ever think about a new Collection framework for Java?
>
> A new framework would need to be significantly better than the existing
> one to ever consider any kind of
Hi.
Please review the following changes to the jaxp and jdk
repositories to fix a few additional references to "1.9".
Bug
8149601 Update references from "1.9" to "9"
https://bugs.openjdk.java.net/browse/JDK-8149601
Webrev
http://cr.openjdk.java.net/~iris/verona/8149601/webrev/
This is
Thanks, looks good.
On 2/11/2016 11:28 AM, Chris Hegarty wrote:
On 11 Feb 2016, at 15:59, Roger Riggs wrote:
Hi Chris,
ok, but can I suggest using 65535 instead of 16384, it will match the length
of the short encoded strings in writeObjectStream.writeString.
That sounds reasonable. So the f
On 11 Feb 2016, at 15:59, Roger Riggs wrote:
> Hi Chris,
>
> ok, but can I suggest using 65535 instead of 16384, it will match the length
> of the short encoded strings in writeObjectStream.writeString.
That sounds reasonable. So the final change is:
diff --git a/src/java.base/share/classes/ja
Hi Chris,
ok, but can I suggest using 65535 instead of 16384, it will match the length
of the short encoded strings in writeObjectStream.writeString.
Thanks, Roger
On 2/11/2016 10:45 AM, Chris Hegarty wrote:
Ha, such a seemingly innocuous little perf change has generated much noise ;-)
You a
Ha, such a seemingly innocuous little perf change has generated much noise ;-)
You are of course right.
On 11 Feb 2016, at 15:23, Roger Riggs wrote:
> Hi Chris,
>
> The change to preallocate the StringBuffer is fine.
>
> But I have misgivings about not consuming the data from the stream and
On 11 Feb 2016, at 15:32, Roger Riggs wrote:
> Hi Chris,
>
> Looks fine.
Thanks Roger.
> I did wonder why src/java.base/share/classes/sun/nio/ch/ThreadPool.java
> didn't use the import while all the other cases did. But it would be just
> for consistency of style.
I can go either way. I’l
Hi Chris,
Looks fine.
I did wonder why src/java.base/share/classes/sun/nio/ch/ThreadPool.java
didn't use the import while all the other cases did. But it would be
just for consistency of style.
Roger
On 2/11/2016 9:04 AM, Chris Hegarty wrote:
In preparation for JEP 260, InnocuousThread sh
Hi Chris,
The change to preallocate the StringBuffer is fine.
But I have misgivings about not consuming the data from the stream and
returning the empty string
for out of range lengths. It will silently leave the input stream in an
unusable state.
I think it should throw an exception (Stream
In preparation for JEP 260, InnocuousThread should be moved out of the
sun.misc package and placed into a more appropriate package where it
can be encapsulated.
http://cr.openjdk.java.net/~chegar/8149653/
-Chris.
On 02/11/2016 03:52 AM, Peter Firmstone wrote:
An example might be more useful.
Traditionally, when the first non serializable superclass zero argument
constructor is called, the domains of the subclasses aren't present on
the call stack. Any security checks performed in the constructor of the
Hi Peter,
That’s a clever little wrapper, but it seems very particular.
What if we could have (excuse the name):
StringBuilder.toStringWithReset();
That would reset it’s own array to that as if by the default constructor. A
copy is still required but… we could make this intrinsic (as is the
The OneShortStringBuilder looks nice. I would have to specify the Charset in
its constructor, or somehow specify the capacity in bytes rather than
characters, for it to optimally allocate the underlying byte array. It’s
otherwise very similar, though probably more generally useful, to the builde
On 11 Feb 2016, at 01:37, Martin Buchholz wrote:
> and ... webrev regenerated
Thank you Martin, this is better.
For completeness, the specdiff has been updated too:
http://cr.openjdk.java.net/~chegar/jsr166-jdk9-integration-CompletableFuture/CompletionStage.html
-Chris.
> On Wed, Feb 10,
On 11/02/2016 00:25, Xueming Shen wrote:
One of the benefits of moving to the system libz is actually for
better/easy
maintenance. Just replacing the offending version of libz with an
earlier/later
version that works, instead of waiting for a customized jdk/jre image
with a
working/bundled l
An example might be more useful.
Traditionally, when the first non serializable superclass zero argument
constructor is called, the domains of the subclasses aren't present on
the call stack. Any security checks performed in the constructor of the
superclass will not include the subclasses do
The use case here is:
Do we trust the code to deserialize unverified data from an untrusted
source?
For example, an attacker might look for the following:
1. Deserialization into privileged context
2. Deserialization with a class that catches and ignores IOException.
3. A hash collissio
27 matches
Mail list logo
