Some performance figures, atomic de-serialization using loopback local
network sockets, codebase downloads, dynamic class loading, with
security manager and policies in force and Jini extensible remote method
invocation, there's communication going on between 4 different jvm
instances, the one
A simpler example of production code modified to support @AtomicSerial
that satisfies invariants follows. Note how we can't type check
Generics with the static validator method, but the compiler does it for
us with the constructor :)
I'm wondering if there's scope for secure alternatives of
Hi Alan,
I had meant to remove the commented lines prior to generating the patch
regards
Mark
On 06/02/2015 21:21, Alan Bateman wrote:
On 06/02/2015 18:55, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8068682/webrev/
http://c
Hi Deven
Sorry for the noise, but in fact we are looking into removing the
canonicalization step because of
4141872: FilePermission makes symlinks useless
https://bugs.openjdk.java.net/browse/JDK-4141872
This will be a very big incompatible change and we are still doing a
feasibility study.
On 06/02/2015 18:55, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8068682/webrev/
http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/
which address the issue in
https://bugs.openjdk.java.net/browse/JDK-8068682
this change
On 2/5/15 12:46 AM, Paul Sandoz wrote:
On Feb 5, 2015, at 1:36 AM, Brent Christian
wrote:
I prefer this approach of discouraging/preventing side-effects via
CME, rather than allowing them.
...
Regarding the default methods:
Would we be able to make a "best-effort" detection of
comodification...
On Feb 6, 2015, at 7:46 AM, Brian Burkhalter
wrote:
> On Feb 6, 2015, at 12:51 AM, Paul Sandoz wrote:
>
>> +1, but you should remove the "@throws IAE" on divRemNegativeLong before you
>> push.
>
> Mea culpa. Thanks for pointing out the (failure of) omission. Will remove
> before pushing.
Thanks Paul!
Webrev has been updated to include your test, and to fix that
stackoverflowexception, triggered
by the recursive implementation of StreamEncoder.flushLeftoverChar. The method
really does
not need to be recursive (an alternative is to push the "leftover" from the
input buffer back
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8068682/webrev/
http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/
which address the issue in
https://bugs.openjdk.java.net/browse/JDK-8068682
this change means CORBA ORB is loaded by the extension
On Feb 6, 2015, at 12:51 AM, Paul Sandoz wrote:
> +1, but you should remove the "@throws IAE" on divRemNegativeLong before you
> push.
Mea culpa. Thanks for pointing out the (failure of) omission. Will remove
before pushing.
Brian
Hi,
I propose to remove two methods; they have been deprecated for more
than a decade, do not seem to be in use anywhere, and have degenerate
implementations.
java.lang.Runtime.getLocalizedInputStream(InputStream in)
java.lang.Runtime.getLocalizedOutputStream(OutputStream out)
I have not been
Hi Sean,
I have tried to use different symbols in networking interface name in
Linux. I have added a comment to
https://bugs.openjdk.java.net/browse/JDK-8071458
I am able to use symbols: "-", "+", "=", "#", "@".
I was UNABLE to use: "?", "~", "$", "*", "!", "[", "(", "&", "^", "|",
"/", ":"
On 04/02/2015 15:11, Chris Hegarty wrote:
Agreed. Updated in-place
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
I think the approach and naming is good. A few small comments on the
wording:
1. "used to locate URLStreamHandlerProvider providers" - the wording
On Feb 5, 2015, at 9:50 PM, Xueming Shen wrote:
> On 02/05/2015 12:47 PM, Paul Sandoz wrote:
>> On Feb 5, 2015, at 8:00 PM, Xueming Shen wrote:
>>
>>> Hi,
>>>
>>> Please help review the fix for #8030179
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8030179
>>> webrev: http://cr.ope
On Feb 6, 2015, at 2:43 AM, Brian Burkhalter
wrote:
> Hi Paul,
>
> On Feb 5, 2015, at 6:06 AM, Paul Sandoz wrote:
>
>> I don't claim to understand the fine details of these methods but i can see
>> how the new method avoid loosing bits.
>>
>> 4947 private static long[] divRemNegativeLo
On 26/01/15 21:55, Alan Bateman wrote:
On 26/01/2015 19:23, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8057645/webrev.00/
This patch proposes to move java.xml.ws, java.xml.bind,
java.activation out of the boot loader and be loaded by the extension
class loader. We gr
16 matches
Mail list logo
