On 02/17/2016 01:17 AM, Kim Barrett wrote:
On Feb 8, 2016, at 5:46 AM, Peter Levart wrote:
If special-casing in ReferenceHandler is removed then an opportunity opens to
get rid of ReferenceHandler thread altogether. VM/GC could enqueue Reference(s)
to their respective ReferenceQueue(s) direc
Hello, Stuart!
Thank you for your comments.
SM> I'd suggest focusing on the API first before worrying about how to track the
SM> stream state with booleans, etc. Is the API convenient to use, and how well
does
SM> it support the use cases we envision for it?
As Brian already noted, the most ben
> On Feb 16, 2016, at 7:20 PM, Kim Barrett wrote:
> src/java.base/share/classes/java/lang/ref/Reference.java
>
> After removal of the special handling of removing Cleaner objects from
> the pending list, do we still need to catch OOMEs from the pending
> list? If not sure, feel free to defer tha
Hi,
Please review a fix on missing property settings read from catalog
files. Values from catalog files shall override any other settings
including those through the API, e.g.
builder().with(CatalogFeatures.Feature.PREFER, "system").
JBS: https://bugs.openjdk.java.net/browse/JDK-8146237
webr
> On Feb 16, 2016, at 11:15 AM, Peter Levart wrote:
>
> Hello everybody,
>
> Thanks for looking into this and for all your comments. Now that it seems we
> have a consensus that replacing internal Cleaner with public Cleaner is not a
> wrong idea, I created an issue for it [1] so that we may o
> On Feb 8, 2016, at 5:46 AM, Peter Levart wrote:
> If special-casing in ReferenceHandler is removed then an opportunity opens to
> get rid of ReferenceHandler thread altogether. VM/GC could enqueue
> Reference(s) to their respective ReferenceQueue(s) directly, so everyone
> could enjoy the ben
> On Feb 15, 2016, at 9:24 PM, David Holmes wrote:
>
>> This patch looks correct to me. The innocuous thread created for common
>> cleaner is of Thread.MAX_PRIORITY - 2 priority whereas the reference handler
>> thread is of MAX_PRIORITY priority. I don’t know if this would impact any
>> re
On 2/16/2016 2:13 PM, Langer, Christoph wrote:
Hi Joe,
thanks for your great suggestions. I'll come up with a new webrev tomorrow.
However, I'm still wondering if the change for the default value of
XML_SECURITY_PROPERTY_MANAGER in XMLDocumentFragmentScannerImpl should be done
anyway as I gu
Laurent may not technically be a reviewer, but he pretty much owns that
code so if he's happy then I'm happy (but I didn't look at any of the
other code outside of Marlin if you are keeping count of "full
reviewers"...).
...jim
On 2/16/2016 2:08 AM, Laurent Bourgès wro
Hi Joe,
thanks for your great suggestions. I'll come up with a new webrev tomorrow.
However, I'm still wondering if the change for the default value of
XML_SECURITY_PROPERTY_MANAGER in XMLDocumentFragmentScannerImpl should be done
anyway as I guess an XMLObject is more expected rather than a St
Hi David,
Webrev updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-signal-9149750/
On 2/14/2016 11:55 PM, David Holmes wrote:
Hi Roger,
A few mostly minor comments ...
On 13/02/2016 3:47 AM, Roger Riggs wrote:
Please review moving the functionality of sun.misc.Signal to
jdk.inte
Hi Chris,
Webrev updated in place:
http://cr.openjdk.java.net/~rriggs/webrev-signal-9149750/
On 2/15/2016 6:22 AM, Chris Hegarty wrote:
On 12/02/16 17:47, Roger Riggs wrote:
Please review moving the functionality of sun.misc.Signal to
jdk.internal.misc and
creating a wrapper sun.misc.Signal
Regarding wildcards: you definitely want Predicte, which is
what we use elsewhere. For UnaryOperator, you're stuck with invariance.
On 2/16/2016 8:32 AM, Paul Sandoz wrote:
Hi Tagir,
The implementation approach looks good. I agree with Brian on the
documentation, esp. about the connection to
Hi Aleksey,
> http://cr.openjdk.java.net/~shade/8149835/webrev.jdk.01/
701 return (pkg != null ? pkg.getName().replace(".", "/") +
"/" : "") + "Stubs$$StringConcat";
702 } else {
703 return hostClass.getName().replace(".", "/") +
"$$Strin
On Feb 16, 2016, at 11:19 AM, Chris Hegarty wrote:
>
> The Modular Run-Time image, integrated in b41, no longer has JAR files,
> see JEP 220 [1], The meta-index is no longer generated or used. This
> issue proposes to remove the meta-index support from the runtime and
> the build.
>
> http://cr.
Hi,
Please review a StringConcatFactory fix that makes generated String
concat stubs to be named "$$StringConcat/", instead of
"java/lang/String$$Concat/":
https://bugs.openjdk.java.net/browse/JDK-8149835
Among other things, this helps to dodge the failure caught by stricter
access controls in
Hi Christoph,
At initialization of XSDHandler (in reset), note there are two local
variables for the security / property manager, change them to instance
variables, then when you need to create annotation validator, set both
on the validator, e.g.:
fAnnotationValidator.setProperty(SE
The Modular Run-Time image, integrated in b41, no longer has JAR files,
see JEP 220 [1], The meta-index is no longer generated or used. This
issue proposes to remove the meta-index support from the runtime and
the build.
http://cr.openjdk.java.net/~chegar/8068686/
https://bugs.openjdk.java.net/bro
+2
On Feb 16, 2016, at 10:59 AM, Roger Riggs wrote:
> +1
>
> Roger
>
> On 2/16/2016 1:35 PM, joe darcy wrote:
>> Hello,
>>
>> *sigh* The one set of regression tests related in JDK-8149896 I forgot run
>> run before pushing had a dependency on the removed constants in
>> DoubleConsts. Please
+1
Roger
On 2/16/2016 1:35 PM, joe darcy wrote:
Hello,
*sigh* The one set of regression tests related in JDK-8149896 I forgot
run run before pushing had a dependency on the removed constants in
DoubleConsts. Please review this straightforward change to fix up the
Formatter test template and
Hi Miran
Looks OK though you might want to check the spacing on line 454 as it should
probably be moved over but no additional review needed
Best
Lance
On Feb 16, 2016, at 10:42 AM, Miroslav Kos wrote:
> Hi Lance,
> could you review this minor patch? It is just minor overlook I didn't catch
>
Hello,
*sigh* The one set of regression tests related in JDK-8149896 I forgot
run run before pushing had a dependency on the removed constants in
DoubleConsts. Please review this straightforward change to fix up the
Formatter test template and regenerate the tests:
http://cr.openjdk.java
Finally integrated! Nothing in the jsr166 queue at the moment. (I'm
sure we'll fix that ...)
On Thu, Feb 11, 2016 at 2:56 AM, Chris Hegarty wrote:
>
> On 11 Feb 2016, at 01:37, Martin Buchholz wrote:
>
>> and ... webrev regenerated
>
> Thank you Martin, this is better.
>
> For completeness, th
Hi Liam,
Sorry for the delay,
On Sat, 30 Jan 2016 at 04:45 Liam Miller-Cushon wrote:
> On Thu, Jan 28, 2016 at 11:50 AM, Joel Borggrén-Franck <
> joel.borggren.fra...@gmail.com> wrote:
>
> But, the reason we didn't fix this the last two times we looked at it
>> (that I am aware of) is the compa
Hi Laurent,
On 2/16/2016 2:08 AM, Laurent Bourgès wrote:
Hello,
Joe, I tested your changes in the Marlin renderer as it works well !
> A quick note on the 2d changes, several constants (and a copy
from a package-private method from java.lang) were used to
initialize a double value
From: joe darcy
Hello,
The the FloatConsts and DoubleConsts classes, while moved to an
internal
package recently (JDK-8145990), contain constants now available via the
public API. All such uses of the redundant values should be removed as
well as the redundant constants themselves.
http:
Hello everybody,
Thanks for looking into this and for all your comments. Now that it
seems we have a consensus that replacing internal Cleaner with public
Cleaner is not a wrong idea, I created an issue for it [1] so that we
may officially review the implementation. I also created an updated
Hi Lance,
could you review this minor patch? It is just minor overlook I didn't
catch while doing 8138699.
Filed a new JBS issue: https://bugs.openjdk.java.net/browse/JDK-8149923
webrev: http://cr.openjdk.java.net/~mkos/8149923/jaxws.01/
Thanks
Miran
On 15 Feb 2016, at 20:05, Mandy Chung wrote:
>
>> On Feb 15, 2016, at 9:06 AM, Uwe Schindler wrote:
>>
>> Hi,
>>
>>> On 15/02/2016 14:57, Chris Hegarty wrote:
Peter,
http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/
>
> This patch looks corr
Hi Tagir,
The implementation approach looks good. I agree with Brian on the
documentation, esp. about the connection to a for loop.
Testing-wise adding to the spliterator data sources is ok. Because you have
done that there is no need to explicitly use SpliteratorTestHelper in
IterateTest, as
Hi,
can you please review the following change for JDK-8149915:
http://cr.openjdk.java.net/~clanger/webrevs/8149915.0/
I'm not sure if it is the right thing to set the default for
XML_SECURITY_PROPERTY_MANAGER to a new XMLSecurityPropertyManager() object
instead of the String "all". But it mus
Vladimir, Aleksey, thanks for the reviews.
Current Unsafe::getCharUnaligned Java implementation isn't fully
optimized by C2: it never constant folds such loads from char fields.
C2 matches the types of a load and a location and does constant folding
only if they match. For getCharUnaligned it se
Hi Dave,
You've pretty much got it right, although I'm not proposing making the
permissions fine grained to class name level.
There are different DeSerializationPermission's however:
"PROXY" - controls dynamic proxy creation (Some basic invariants are
checked prior, the InvocationHandler fie
Hello,
Joe, I tested your changes in the Marlin renderer as it works well !
> A quick note on the 2d changes, several constants (and a copy from a
> package-private method from java.lang) were used to initialize a double
> value POWER_2_TO_32; this can be accomplished more directly using a
> hex
> On 16 Feb 2016, at 07:23, joe darcy wrote:
>
> Hello,
>
> The the FloatConsts and DoubleConsts classes, while moved to an internal
> package recently (JDK-8145990), contain constants now available via the
> public API. All such uses of the redundant values should be removed as well
> as th
On 02/16/2016 09:23 AM, joe darcy wrote:
> Please review the webrev
>
> http://cr.openjdk.java.net/~darcy/8149896.0/
+1, nice cleanup.
-Aleksey
(not a Reviewer)
36 matches
Mail list logo
