for that purpose.
I've taken an initial look at this and I'm wondering about
SchemeFactory.newInstance throwing SchemaFactoryConfigurationError.
Technically this is an incompatible change but in practical terms it
may not be concern as this provider interface may not be used very much.
Joe Wang
On 1/11/2013 11:14 AM, Daniel Fuchs wrote:
On 1/11/13 8:05 PM, Joe Wang wrote:
I don't have any data on how much the service mechanism may be used,
Xerces would surely be the one most frequently used. I'm more concerned
with the spec change that would require TCK change (the addition
with existing code, I am sorely
tempted to recommend that we do 3. and clarify
the spec on this point.
(3: Only call ServiceLoader.load(type) when the provided
factoryId is equal to type.getName())
Best regards,
-- daniel
On 12/19/12 10:45 AM, Daniel Fuchs wrote:
On 12/19/12 12:10 AM, Joe Wang wrote
On 1/3/2013 3:33 AM, Daniel Fuchs wrote:
On 12/27/12 12:06 AM, Joe Wang wrote:
Hi,
This is a patch to clean up compiling warnings in jaxp.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473
Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/
Thanks,
Joe
Hi Joe
Thanks all!
I've updated the webrev with Remi's suggestion.
-Joe
On 12/27/2012 5:25 AM, Remi Forax wrote:
On 12/27/2012 12:06 AM, Joe Wang wrote:
Hi,
This is a patch to clean up compiling warnings in jaxp.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473
Webrev: http
Hi,
This is a patch to clean up compiling warnings in jaxp.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473
Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/
Thanks,
Joe
The cause of the LoadAndStoreXML test failure appeared to be that of
8005281 that Alan just fixed. Before the 8005281 patch, I was able to
get the tests to pass when I isolated the relevant tests (that is, copy
LoadAndStoreXML and remove other test cases). After the 8005281 patch,
On 12/21/2012 4:05 AM, Alan Bateman wrote:
On 21/12/2012 08:37, Joe Wang wrote:
The cause of the LoadAndStoreXML test failure appeared to be that of
8005281 that Alan just fixed. Before the 8005281 patch, I was able to
get the tests to pass when I isolated the relevant tests (that is,
copy
On 12/21/2012 11:08 AM, Alan Bateman wrote:
On 21/12/2012 18:03, Joe Wang wrote:
:
Files are renamed. I added a new test CompatibilityTest to test
behavior compatibility with the regular JDK XML provider.
Webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8005280/webrev/
-Joe
Thanks
On 12/21/2012 12:35 PM, Alan Bateman wrote:
On 21/12/2012 19:56, Joe Wang wrote:
:
I searched by properties.dtd and found the CDATA usage. So I went
ahead experimenting what would not be rejected by the regular
provider and tested against the small parser. I agree the cases
other than
On 12/19/2012 6:34 AM, Daniel Fuchs wrote:
Hi,
Please find below an updated webrev for the javax.xml.transform
package, taking into account Mandy's Joe's comments - namely:
1. Fixed call to creationMethod.invoke.
2. Got rid of the 4 args FactoryFinder.newInstance method.
3. Got rid of the
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is
simply made final.
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/
Test:
No new test needed.
Thanks,
Joe
Thanks Chris!
On 12/18/2012 12:53 AM, Chris Hegarty wrote:
Looks ok to me Joe.
-Chris
On 18 Dec 2012, at 08:47, Joe Wanghuizhe.w...@oracle.com wrote:
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is simply
made final.
webrev:
On 12/18/2012 12:55 AM, David Holmes wrote:
Joe,
On 18/12/2012 6:47 PM, Joe Wang wrote:
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is
simply made final.
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/
Obviously it was known
Hi Daniel,
The call: T provider = findServiceProvider(type) in static T T
find(ClassT type, String factoryId, ClassLoader cl, String
fallbackClassName) ignored factoryId, and assumed it's the same as
type.getName(). I looked back I had the same bug in my original patch.
-Joe
On 12/18/2012
Hi Daniel,
Looks great! I see you've added many verifications.
One minor note, creationMethod is used in place of the object instance
for the creationMethod.invoke call, although it's ignored for a static
method anyways. Is there a reason for doing that?
-Joe
On 12/18/2012 8:42 AM,
On 12/18/2012 10:00 AM, Daniel Fuchs wrote:
On 12/18/12 6:29 PM, Joe Wang wrote:
Hi Daniel,
The call: T provider = findServiceProvider(type) in static T T
find(ClassT type, String factoryId, ClassLoader cl, String
fallbackClassName) ignored factoryId, and assumed it's the same
On 12/18/2012 2:23 PM, Daniel Fuchs wrote:
On 12/18/12 8:00 PM, Joe Wang wrote:
On 12/18/2012 10:00 AM, Daniel Fuchs wrote:
On 12/18/12 6:29 PM, Joe Wang wrote:
Hi Daniel,
The call: T provider = findServiceProvider(type) in static T T
find(ClassT type, String factoryId, ClassLoader cl
it may be a good idea to add the
final, but make it a non-compile time constant. We can also remove the
duplication.
public static final String fVersion = getVersion();
Tom
On 18/12/2012 08:47, Joe Wang wrote:
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion
= getVersion();
Tom
On 18/12/2012 08:47, Joe Wang wrote:
Hi,
This is the 2nd of the three [findbug] issues. The field fVersion is
simply made final.
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/
Test:
No new test needed.
Thanks,
Joe
Network Drive x-apple-data-detectors://28/0
Burlington, MA 01803 x-apple-data-detectors://28/0
lance.ander...@oracle.com mailto:lance.ander...@oracle.com
Sent from my iPhone
On Dec 18, 2012, at 8:51 PM, Joe Wang huizhe.w...@oracle.com
mailto:huizhe.w...@oracle.com wrote:
Thanks Tom. I changed
On 12/18/2012 7:08 PM, David Holmes wrote:
On 19/12/2012 12:21 PM, Joe Wang wrote:
On 12/18/2012 3:43 PM, David Holmes wrote:
On 19/12/2012 3:49 AM, Tom Hawtin wrote:
Not that it's particularly important, but it's /possible/ clients are
relying on the non-compile time constant nature
be easier for one of you
to run the tests yourself.
You may ask Patrick for instructions on how to run regression test. It
needs to be run separately since they are not in the jdk repo yet.
Thanks,
Joe
Cheers,
-Buck
On 2012/12/13 4:14, Joe Wang wrote:
Hi David,
You didn't apply the original
Hi,
This is one of the three [findbug] issues. I've checked with Drew. None
of them are vulnerabilities. Nonetheless, the fields should have been
private or package private.
webrev:
http://cr.openjdk.java.net/~joehw/7u12/8003260/webrev/
Test:
No new test. Existing regression tests passed.
Best
Lance
On Dec 14, 2012, at 1:33 PM, Joe Wang wrote:
Hi,
This is one of the three [findbug] issues. I've checked with Drew. None of them
are vulnerabilities. Nonetheless, the fields should have been private or
package private.
webrev:
http://cr.openjdk.java.net/~joehw/7u12/8003260/webrev
it is fine
Best
Lance
On Dec 14, 2012, at 1:33 PM, Joe Wang wrote:
Hi,
This is one of the three [findbug] issues. I've checked with Drew. None of them
are vulnerabilities. Nonetheless, the fields should have been private or
package private.
webrev:
http://cr.openjdk.java.net/~joehw/7u12/8003260
Hi Daniel,
This looks good. We had some discussion over if there's a difference in
classloading between the original sequence and that of ServiceLoader. I
understand you have the full regression testsuite from SQE. Just would
like to make sure they pass just fine.
Thanks,
Joe
On
On 12/12/2012 2:35 AM, Alan Bateman wrote:
On 12/12/2012 09:31, Paul Sandoz wrote:
http://cr.openjdk.java.net/~alanb/8004371/webrev.02/src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java.html
Why are the element qualified names compared ignoring case?
I'll leave this
Review for jaxp ]
http://cr.openjdk.java.net/~dbuck/8003147/webrev.00/
My understanding is that the test cases for our copy of the jaxp code
are handled in a separate repository / test suite. I have been in
contact with Patrick Zhang (Oracle QA) and Joe Wang and have provided
a junit test
Hi Daniel,
Looks good!
Joe
On 12/10/2012 9:12 AM, Daniel Fuchs wrote:
Hi,
After further discussion with Joe Alan, I changed the call
to ServiceLoader to simply return the first provider it finds,
or null.
This is closer to what was present in JDK 7 - and looping is
not necessary in JDK 8
I would think that it's good to merge the 3rd and 4th steps for a jdk in
module mode. In regular mode or JDK8, where the existence of the default
implementation is guaranteed, the last step is still necessary. It is a
requirement for the API implementation.
I probably was wrong to use
Thanks for reviewing the changes. Please see comments inline.
On 12/7/2012 11:38 AM, Mandy Chung wrote:
On 12/5/12 10:58 AM, Alan Bateman wrote:
http://cr.openjdk.java.net/~alanb/8004371/webrev/
Yay! Properties no longer requires JAXP to be present in order to
load/store properties in
Hi Daniel,
Looks good to me!
-Joe
On 12/5/2012 8:17 AM, Daniel Fuchs wrote:
Hi,
Please find below a revised version of the changes for
the javax.xml.parsers package.
It hopefully incorporates all comments I have received so far.
Thanks Lance!
On 10/9/2012 7:55 AM, Lance Andersen - Oracle wrote:
Look OK Joe
On Oct 9, 2012, at 12:31 AM, Joe Wang wrote:
This is an issue found while I was working with SQE to expand test
coverage. For a non-validating parser, when load-external-dtd is
false, entity references
This is an issue found while I was working with SQE to expand test
coverage. For a non-validating parser, when load-external-dtd is false,
entity references are skipped. However, the skippedEntity() event was
not reported.
The problem was due to missing infoset augmentations when document
On 8/30/2012 2:20 PM, Alan Bateman wrote:
On 30/08/2012 19:38, Joe Wang wrote:
Hi Paul, Alan,
I've read your latest comments. Before getting back to you on those
items, I felt it's important we get the classloader handling
correctly. If it's as what I suspected (as I described in the last
On 8/31/2012 4:20 AM, Alan Bateman wrote:
On 31/08/2012 08:59, Joe Wang wrote:
Yes, it works just fine under normal conditions.
Note the old process: read the service file using TCCL (if null,
system cl), if nothing found, then BCL
Somehow I was under the impression ServiceLoader does
ServiceLoader?
--Joe
On 8/29/2012 3:27 AM, Alan Bateman wrote:
On 28/08/2012 05:57, Joe Wang wrote:
:
In DocumentBuilderFactory and SAXParserFactory the javadoc reads
Otherwise the default implementation is returned if it is on the
classpath or installed as a module. I think this statement
Hi Paul, Alan,
I've read your latest comments. Before getting back to you on those
items, I felt it's important we get the classloader handling correctly.
If it's as what I suspected (as I described in the last email), we may
have problem with using ServiceLoader.
I've read Paul's
I actually updated the webrev yesterday with your suggestion.
Recall our discussions back in June, the suggestion was to delegate to
the ServiceLoader, e.g. ServiceLoader.load(serviceClass). The rational
was that the ServiceLoader uses context and then bootstrap class loader.
The spec for
Paul, Alan,
Confusion was what jaxp meant to give :) I was told that the
factory/object finders, security support classes were duplicated, and
needed to be kept in sync. But they are not even in their original
form, unfortunately.
Both of you mentioned that it's desirable to make SCE the
On 8/28/2012 1:19 AM, Paul Sandoz wrote:
Hi Joe,
On Aug 28, 2012, at 7:35 AM, Joe Wanghuizhe.w...@oracle.com wrote:
--
datatype/FactoryFinder.java:
244 } catch (ServiceConfigurationError e) {
245 throw new DatatypeConfigurationException(e.getMessage(),
On 8/27/2012 6:19 AM, Alan Bateman wrote:
On 24/08/2012 17:52, Joe Wang wrote:
Hi,
Here is a modified patch:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
The factory finders contain some format changes, a NetBeans format
work. The real changes are as the follows:
1) In factory
On 8/27/2012 6:19 AM, Paul Sandoz wrote:
Hi Joe,
This is starting to look cleaner.
Yeah, if Alan hasn't asked, I'd sooner keep them as they were :) JAXP
is old, I never fancied getting those formats corrected. But I can't do
this much to classes I'd update, but probably not to the impl
2) In factory finders: replaced findJarServiceProvider with
findServiceProvider
3) In factory finders: removed ConfigurationError class, using
FactoryConfigurationError instead
Please review.
Thanks,
Joe
On 7/29/2012 11:59 PM, Joe Wang wrote:
Hi Paul, Alan,
I'm back on this change
Thanks, Lance!
On 8/17/2012 8:26 AM, Lance Andersen - Oracle wrote:
Hi Joe,
Looks fine.
Best
Lance
On Aug 17, 2012, at 12:07 AM, Joe Wang wrote:
In the patch for 6756677, we fixed errors in StAX's input and output
factories where factoryId such as 'javax.xml.stream.XMLInputFactory
In the patch for 6756677, we fixed errors in StAX's input and output
factories where factoryId such as 'javax.xml.stream.XMLInputFactory was
taken as factory class e.g.
com.sun.xml.internal.stream.XMLInputFactoryImpl. Unfortunately, we
missed XMLEventFactory in that patch.
So this is a
Hi Paul, Alan,
I'm back on this change.
On 6/25/2012 12:19 PM, Joe Wang wrote:
On 6/25/2012 9:34 AM, Paul Sandoz wrote:
H Joe,
I just focused on javax.xml.datatype and assumed the rest follows the
same pattern :-)
Yeah, they are mostly similar, except Schema and XPath that do a
little
Lance, Paul,
Thanks!
Joe
On 7/12/2012 3:55 AM, Lance Andersen - Oracle wrote:
+1
Best
Lance
On Jul 12, 2012, at 5:42 AM, Paul Sandoz wrote:
Hi Joe,
On Jul 11, 2012, at 7:59 AM, Joe Wang wrote:
Hi Paul,
This is now for 7u8, so I started a new thread.
As we discussed, I've removed
On 7/9/2012 10:59 PM, Paul Sandoz wrote:
Hi Joe,
What happens when someone logs a bug for system IDs containing IPv6 addresses
and non-percent encoded international characters?
Exception would be expected just as if Xerces is used.
On Jul 10, 2012, at 3:42 AM, Joe Wang wrote:
Hi Paul
/2012 12:26 PM, Paul Sandoz wrote:
Hi Joe,
If you are gonna fix things to support IPv6 addresses in URLs i really think
you need to make it work for URLs with international characters too.
On Jul 10, 2012, at 8:50 PM, Joe Wang wrote:
602 if (reader == null) {
603 stream
, at 11:59 PM, Joe Wang wrote:
Hi Paul,
That method was contributed by engineers from Korea and intended to handle
paths that contained international characters, so that was how it was named.
It was an extra processing added. Outside of that scenario, we'd want to skip
the process and get back
escapeNonUSAscii is slightly misleading, it should be really called something
like escapeCharactersInUriString.
Note that '[' and ']' are not valid URI characters outside of an IPv6 encoded
address.
Paul.
On Jun 23, 2012, at 1:09 AM, Joe Wang wrote:
Hi,
This is a patch to fix the IPv6 issue
it in as it
stands now and work out another patch for the duplicated classes once we
have a solution.
New webrev:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
Thanks,
Joe
On 6/22/2012 10:24 AM, Joe Wang wrote:
On 6/22/2012 2:39 AM, Alan Bateman wrote:
On 21/06/2012 22:53, Joe Wang wrote
On 6/25/2012 5:14 AM, Alan Bateman wrote:
On 25/06/2012 08:38, Joe Wang wrote:
Hi all,
Thanks for all the comments!
I've updated the patch for the following recommended changes:
1. ServiceConfigurationError instead of ConfigurationError
2. Use factory class, class.forName section removed
3
().getContextClassLoader().
Good catch, yes we do! We're virtually delegating those calls to the
ServiceLoader that could be blocked when security is on.
Joe
Paul.
On Jun 25, 2012, at 9:38 AM, Joe Wang wrote:
Hi all,
Thanks for all the comments!
I've updated the patch for the following
On 6/22/2012 2:39 AM, Alan Bateman wrote:
On 21/06/2012 22:53, Joe Wang wrote:
:
We're not considering this change for jdk7 or older, i.e. I haven't
thought about fixing 6975142. For jdk8, it seems we have to live
with the way it is in (2), a seemly incompatible behavior in backward
Hi,
This is a patch to replace the manual process in the 3rd step of the
JAXP implementation resolution mechanism with ServiceLoader. Please see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for more
details about the issue.
Note that FactoryFinder is duplicated for each JAXP
jaxp tck passed.
Joe
On 6/21/2012 12:55 AM, Joe Wang wrote:
Hi,
This is a patch to replace the manual process in the 3rd step of the
JAXP implementation resolution mechanism with ServiceLoader. Please
see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for
more details about
was that .load returns an
instance. There's a situation where a static method or constructor with
a parameter instead of the default constructor may be called to initiate
the provider.
-Joe
Paul.
On Jun 21, 2012, at 9:55 AM, Joe Wang wrote:
Hi,
This is a patch to replace the manual
On 6/21/2012 5:44 AM, Alan Bateman wrote:
On 21/06/2012 08:55, Joe Wang wrote:
:
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
It's great to get this work started.
The javadoc changes look okay to me and fine for this change. However
there are a few areas that could
On 6/21/2012 11:04 AM, Alan Bateman wrote:
On 21/06/2012 18:34, Joe Wang wrote:
:
When iterating over the service instances you are catching
ConfigurationError
264 ServiceLoader loader =
ServiceLoader.load(serviceClass, cl);
265 final Iterator providers
On 6/21/2012 2:00 PM, Alan Bateman wrote:
On 21/06/2012 19:02, Joe Wang wrote:
:
For the class loader, as discussed with Paul, since the ServiceLoader
does so much, we may be able to skip the 'using different
classloader' part, that is, simply calling load without classloader
Hi Lance,
The changes look good to me.
Joe
On 6/13/2012 4:09 AM, Paul Sandoz wrote:
On Jun 13, 2012, at 1:04 PM, Lance Andersen - Oracle wrote:
Hi Paul,
Thank you for taking the time to review the code.
I made the change you suggested below
Thanks Lance, Paul!
Joe
On 6/12/2012 5:48 AM, Lance Andersen - Oracle wrote:
looks fine
best
lance
On Jun 11, 2012, at 7:23 PM, Joe Wang wrote:
Hi,
This is patch to make sure the cause of the error is properly
reported. It has been in jaxp since Feb.
webrev: http://cr.openjdk.java.net
Looks good to me, Lance.
Best,
Joe
On 6/12/2012 1:21 PM, Lance Andersen - Oracle wrote:
Still looking for a reviewer on this.
All SQE, unit tests, JCK and TCK tests pass.
Best
Lance
Begin forwarded message:
From: Lance Andersen - Oraclelance.ander...@oracle.com
Date: May 25, 2012
As reported in 7157610, when
setFeature(http://apache.org/xml/features/disallow-doctype-decl;, true)
is set on SAXParserFactory object, XMLReader object or
DocumentBuilderFactory object, NullPointerException will be thrown when
parsing XML document that has DOCTYPE declaration.
The cause of
//return fSupportDTD? next() : dtdEvent;
in XMLDocumentScannerImpl? If not you might consider removing it.
Best
Lance
On Jun 11, 2012, at 3:08 PM, Joe Wang wrote:
As reported in 7157610, when
setFeature(http://apache.org/xml/features/disallow-doctype-decl;,
true) is set on SAXParserFactory
Hi,
This is patch to make sure the cause of the error is properly reported.
It has been in jaxp since Feb.
webrev: http://cr.openjdk.java.net/~joehw/7u6/7143711/webrev/
Please review.
Thanks,
Joe
Lance,
It looks fine to me.
Best,
Joe
On 6/5/2012 7:16 AM, Lance Andersen - Oracle wrote:
Looking for a reviewer here as well still
Best
Lance
Begin forwarded message:
From: Lance Andersen - Oraclelance.ander...@oracle.com
Date: May 26, 2012 9:33:40 AM EDT
Cc: core-libs-dev
The feature is: http://apache.org/xml/features/standard-uri-conformant
True: Requires that a URI has to be provided where a URI is expected.
False: Some invalid URI's are accepted as valid values when a URI
is expected. Examples include: using platform dependent file separator
in
On 4/16/2012 7:20 AM, Sean Mullan wrote:
On 4/12/12 6:25 PM, Joe Wang wrote:
This is a follow-up update on Kelly's change that dropped the jaxp
source drop bundle process. With this update, the jaxp source in JDK8
will be sync-ed with the current JAXP 1.4.5, and also JDK7u (the last
change
I've added the testcase. The new webrev is here:
http://cr.openjdk.java.net/~joehw/jdk8/7160380/jdk/webrev/
Also, Lance has reviewed the long list of the source changes.
Thanks!
-Joe
On 4/16/2012 7:20 AM, Sean Mullan wrote:
On 4/12/12 6:25 PM, Joe Wang wrote:
This is a follow-up update
In the patch for 7053556, the ObjectFactory/SecuritySupport classes that
were duplicated in many packages were replaced by a unified set under
xerces/internal/utils and xalan/internal/utils (Note that those under
xpath/internal/utils were old). When the jaxp 1.4.5 source bundle was
dropped
I'd thank them for the services over the last 8 years :)
On 4/13/2012 2:08 PM, Lance Andersen - Oracle wrote:
looks good joe, say goodbye to them :-)
On Apr 13, 2012, at 1:17 PM, Joe Wang wrote:
In the patch for 7053556, the ObjectFactory/SecuritySupport classes
that were duplicated in many
This is a follow-up update on Kelly's change that dropped the jaxp
source drop bundle process. With this update, the jaxp source in JDK8
will be sync-ed with the current JAXP 1.4.5, and also JDK7u (the last
change was 7151484). Going forward, we'll follow the process to put any
changes into
After removing the jaxp source drop bundle process, refer to 7150324,
the source structure needs to be changed to be consistent with that of
jdk7. I will rename jdk8/jaxp/src/share/classes to jdk8/jaxp/src before
updating it to the current jaxp source (7160380).
webrev for the build files:
Hi,
This is a one line fix: adding a return statement as suggested in the
bug report to guard against null value of the name parameter.
webrev: http://cr.openjdk.java.net/~joehw/7u6/cr7151484/webrev/
Please review.
Thanks,
Joe
Thanks!
On 3/30/2012 5:41 AM, Lance Andersen - Oracle wrote:
Hi Joe,
Looks fine
-lance
On Mar 30, 2012, at 3:24 AM, Joe Wang wrote:
Hi,
This is a one line fix: adding a return statement as suggested in the
bug report to guard against null value of the name parameter.
webrev: http
Thanks for the quick review!
Now, if only I can get the approval today, I can actually catch the code
freeze... :)
--Joe
On 3/21/2012 5:26 AM, Lance Andersen - Oracle wrote:
Thank you Joe, good to go from my perspective.
Best
Lance
On Mar 20, 2012, at 11:36 PM, Joe Wang wrote:
Thanks
*/
Corrected the typo: is should have been if
The updated webrev:
http://cr.openjdk.java.net/~joehw/7u4/cr7150537/webrev/
http://cr.openjdk.java.net/%7Ejoehw/7u4/cr7150537/webrev/
Regards,
Joe
Best
lance
On Mar 20, 2012, at 1:32 PM, Joe Wang wrote:
Hi,
This is an issue introduced
Hi all,
This is a low risk, proven patch made in Xerces back in 2007 [1],
removing unnecessary synchronization in DTDDVFactory. As reported in
7147666, this patch improves performance in one of the xml test.
Webrev : http://cr.openjdk.java.net/~joehw/7u4/cr7147666/webrev/
[1]
the class to show up in any future diff operation.
-Joe
On 3/5/2012 1:02 PM, Lance Andersen - Oracle wrote:
looks ok joe
-lance
On Mar 5, 2012, at 1:46 PM, Joe Wang wrote:
Hi all,
This is a low risk, proven patch made in Xerces back in 2007 [1],
removing unnecessary synchronization
Thanks Tom.
Joe
On 2/13/2012 8:54 AM, Tom Hawtin wrote:
Looks good to me.
Tom
On 08/02/2012 22:13, Joe Wang wrote:
Hi,
The 7053556 patch added a (Oracle) implementation-only feature to allow
users to skip the plugability layer. In the same patch, there was also a
change that in secure mode
Hi,
The 7053556 patch added a (Oracle) implementation-only feature to allow
users to skip the plugability layer. In the same patch, there was also
a change that in secure mode, dependent components should be loaded in a
hardwired mode. The implementation-only feature therefore should not
require a bit of effort.
-Alan
On 27/01/2012 23:05, Joe Wang wrote:
/ Hi,
//
// With this additional patch, I'm fixing a SpecJvm2008 failure against
// 7u4 b07 (7098746), along with a couple of other fixes and accumulated
// Xalan update. The changes are listed below and at
// http
Hi,
With this additional patch, I'm fixing a SpecJvm2008 failure against 7u4
b07 (7098746), along with a couple of other fixes and accumulated Xalan
update. The changes are listed below and at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133220.
The webrev is at:
that fate. And maybe, this could be a tiny tiny tiny bit of it - no one
knows, but since no one else has done it, we can claim that that was it
when 12/13 comes ;-)
-Joe
-kto
On Dec 30, 2011, at 10:11 AM, Joe Wang wrote:
On 12/30/2011 6:14 AM, Alan Bateman wrote:
On 28/12/2011 17:18
On 12/30/2011 6:14 AM, Alan Bateman wrote:
On 28/12/2011 17:18, Joe Wang wrote:
Kelly asked for 6-open and jdk8 as well. Since we're changing the
jaxp bundle process, we thought we would do the same for 6-open and
jdk8 once this works out. But we can take the change to jdk8 first
On 12/28/2011 2:56 AM, Alan Bateman wrote:
On 23/12/2011 21:27, Joe Wang wrote:
Hi All,
We have prepared a jaxp update for 7u4. The listed changes have been
posted to the jdk7u-dev alias with 7u4 Request for approval for CR
7121110 - JAXP 1.4.5 update 1 for 7u4.
With this update, we
O'Hair wrote:
Looks great to me.
There is still the issue of making sure the right people (like you :^) are the
ones patching this code, so we know
what we have matches the public JAXP project.
-kto
On Dec 23, 2011, at 1:27 PM, Joe Wang wrote:
Hi All,
We have prepared a jaxp update for 7u4
are in the same repository. But we can deal with that when the
time comes.
-kto
On Dec 27, 2011, at 10:21 AM, Joe Wang wrote:
Thanks Kelly!
Indeed, that was the original intention when you designed the bundle process.
Besides the unfortunate download problem, it actually works great in terms
Hi All,
We have prepared a jaxp update for 7u4. The listed changes have been
posted to the jdk7u-dev alias with 7u4 Request for approval for CR
7121110 - JAXP 1.4.5 update 1 for 7u4.
With this update, we are adding jaxp sources back into the jdk7
repository, which means we are abandoning
On 12/23/2011 2:11 PM, Omair Majid wrote:
On 12/23/2011 04:27 PM, Joe Wang wrote:
Hi All,
We have prepared a jaxp update for 7u4. The listed changes have been
posted to the jdk7u-dev alias with 7u4 Request for approval for CR
7121110 - JAXP 1.4.5 update 1 for 7u4.
With this update, we
: http://jaxp.java.net/
you'll see that the latest formal release mentioned is 1.4.4.
Is JDK7 going to ship with a development release of JAXP or will
1.4.5 get formally released before JDK7 FCS?
I've cc'ed Joe Wang from the JAXP project and I'm sure he can help
(and maybe suggest the mailing
Sorry for the late answer to this question. I was on a long vacation.
Please see inline below.
On 4/7/2011 7:04 AM, Dalibor Topic wrote:
On 4/7/11 3:49 PM, Dr Andrew John Hughes wrote:
On 07/04/2011, Dalibor Topic dalibor.to...@oracle.com wrote:
On 3/3/11 3:01 AM, Dr Andrew John
Kelly,
Thanks for the quick action! So I may even have time to handle any
regressions before my vacation :)
I double-checked both paths, and also the checksum. They are all good to me.
Thanks,
Joe
On 3/2/2011 11:38 AM, Kelly O'Hair wrote:
Need reviewer for change in jaxp source drop
801 - 897 of 897 matches
Mail list logo