Hi Joe,
generally, you are right, XSLT requires namespace support. For parsing the
stylesheet, it is definitely a hard requirement. Otherwise this would not make
sense at all. For instance xsl directives are in the xsl namespace. That
requirement is what the FAQ you are referencing [1] is talki
> On Jan 18, 2017, at 1:23 PM, Sean Mullan wrote:
>
>> Similar to the feedback I suggest for JDK-8168075. We can move this
>> initialization to the holder class and trigger the initialization in
>> the SecurityManager constructor.
>
> For now, I would prefer to leave it as is. In an earlier re
On 1/13/17 2:38 AM, Mandy Chung wrote:
On Jan 9, 2017, at 11:25 AM, Sean Mullan
wrote:
Please review this JDK 9 change to make the
SecurityManager::checkPackageAccess and checkPackageDefinition
implementations restrict access to the same set of internal JDK
packages as the module system.
Thi
Hi Sherman,
thanks for the update. It looks much better now.
One more thing:
src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java
70 private static ZipCoder utf8 = new UTF8();
I think this field can be final as it never changes.
Best regards,
Andrej Golovnin
> On 18 Jan 2017, at 19:43,
Hi Christoph,
Refer to the previous email, I know we discussed your customer's need to
process legacy sources. However, Xalan inherently requires namespace
aware. I also don't think adding a SAX feature to the Transform API is
appropriate.
Thanks,
Joe
On 1/18/2017 8:44 AM, Langer, Christoph
Hi Christoph,
Xalan requires the underlying parser to be namespace aware. Please refer
to https://xml.apache.org/xalan-j/faq.html#faq-N10207
Thanks,
Joe
On 1/18/2017 8:26 AM, Langer, Christoph wrote:
Hi,
please review a change for JAXP.
Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
> On 18 Jan 2017, at 12:01, Claes Redestad wrote:
>
>
>
> On 2017-01-18 19:57, Paul Sandoz wrote:
>>
>>> On 18 Jan 2017, at 05:40, Claes Redestad wrote:
>>>
>>> Using Stable we could also make the lookup of TARGET_OFFSET lazy:
>>>
>>> http://cr.openjdk.java.net/~redestad/8172905/webrev.02/
On 2017-01-18 19:57, Paul Sandoz wrote:
On 18 Jan 2017, at 05:40, Claes Redestad wrote:
Using Stable we could also make the lookup of TARGET_OFFSET lazy:
http://cr.openjdk.java.net/~redestad/8172905/webrev.02/
+1
Thanks!
You are definitely on a mission to shame off every spare micr
> On 18 Jan 2017, at 05:40, Claes Redestad wrote:
>
> Using Stable we could also make the lookup of TARGET_OFFSET lazy:
>
> http://cr.openjdk.java.net/~redestad/8172905/webrev.02/
>
+1
You are definitely on a mission to shame off every spare micro-second :-)
Paul.
> /Claes
>
> On 01/18/20
Hi Andrej,
Thanks for the review.
I was debating with myself if it's really a good idea to "silently" go with the
default charset in case the specified charset can not be obtained. Given the
charset name is passed via the env map, it might be better to simply let the
runtime exception get throw
Hello Sebastian,
CCing the 2d-dev mailing list which is the apt forum for this topic.
Patches are most welcome but need to be contributed according to the protocol
delineated in [1].
Regards,
Brian
[1] http://openjdk.java.net/contribute/
On Jan 18, 2017, at 9:11 AM, Sebastian Bathke
wrote:
Hi Arne,
The arguments to Instant.ofEpochSecond[1] are seconds and nanoseconds.
So 123400 nanoseconds is more clearly written as 000_123_400.
Regards, Roger
[1]
http://download.java.net/java/jdk9/docs/api/java/time/Instant.html#ofEpochSecond-long-long-
On 1/17/2017 3:07 PM, Arne Ploese wrot
Hi,
I'm runnig
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-3-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
and I encounter the following bug.
TestCase:
@Test
public void testNanos() {
DateTimeFormatter formatter =
DateTimeF
Hi,
I hope this is the correct mailing list for this imageIO issue.
https://bugs.openjdk.java.net/browse/JDK-7132728
I found several workarounds for this by patched ImageReaders but would
rather see it get fixed in the JDK.
I wonder whether a path addressing the issue would be welcome as ?
Rega
Hi,
I have created a new webrev for this enhancement:
http://cr.openjdk.java.net/~clanger/webrevs/8023653.1/
As it bases on the change proposal for the new bug 8172974 [1], it is much
smaller and really only contains the modifications needed for honoring the
feature "namespace-aware" on Transfo
Hi,
please review a change for JAXP.
Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-8023653, I
saw that there's still an issue with StAXInputSource which is
> On 18 Jan 2017, at 17:59, Chris Hegarty wrote:
>
>
>> On 17 Jan 2017, at 15:33, Andrey Nazarov wrote:
>>
>> Thanks for review. I’ve update patch
>> http://cr.openjdk.java.net/~anazarov/8071566/webrev.01/
>
> I think this is ok.
Thanks
>
> -Chris.
>
>>
>> —Andrey
>>> On 3 Jan 2017, at 1
> On 17 Jan 2017, at 15:33, Andrey Nazarov wrote:
>
> Thanks for review. I’ve update patch
> http://cr.openjdk.java.net/~anazarov/8071566/webrev.01/
I think this is ok.
-Chris.
>
> —Andrey
>> On 3 Jan 2017, at 14:25, Chris Hegarty wrote:
>>
>> Andrey,
>>
>>> On 30 Dec 2016, at 14:11, And
Using Stable we could also make the lookup of TARGET_OFFSET lazy:
http://cr.openjdk.java.net/~redestad/8172905/webrev.02/
/Claes
On 01/18/2017 04:38 AM, John Rose wrote:
Using a stable field will consume less meta-space than a nested class, all
other things being equal.
– John
On Jan 17, 2
Hi Peter,
On 01/17/2017 03:10 PM, Peter Levart wrote:
As for the failure reporting: requesting an annotation for invalid
annotation type now always produces AnnotationFormatError. Previously,
some invalid annotations were simply skipped, some produced
AnnotationFormatError and for some of th
20 matches
Mail list logo
