| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: Ie61022069e597d9c5c6e7ea4659fd614efe31852
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The input XML file looks something like this:
<foo> <a></a> <b></b> &c; </foo>
The &c; entity expands to <c></c> on the RI. On Android, it is ignored. That
behavior is known.
The results from the RI were 3 elements:
<a> <b> <c>
The results from Android were also 3 elements, but a different 3:
<foo> <a> <b>
With my recent fix, the result is what it should be for a system that doesn't
expand entities:
<a> <b>
I've adjusted the test to expect one fewer element. It now fails on the RI,
because we're not expecting the expanded entity.
http://b/3350005
Change-Id: I20ab5c0521d20075582c0038bcf6e9e15d50597f
|
| |
|
|
|
|
|
|
|
| |
Motivation: in preparation to refactor the Kxml code I'd like
to bring this code to a style consistent with the rest of
Android. This code style currently disagrees with my toolchain.
Change-Id: Ibd24570c131e792532e46f7f44c64abac3a6979a
http://b/3090550
|
| |\
| |
| |
| |
| | |
Conflicts:
libcore/xml/src/test/java/tests/api/javax/xml/parsers/SAXParserFactoryTest.java
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our exception priority has changed for DOM attributes. We
previously used to throw DOMExceptions with namespace error
codes and now throw DOMExceptions with character error codes
when the attribute name is malformed. This caused changes to
many tests.
Another notable behaviour change is that we now supply the
qname (like the RI) where previously we did not. It is optional,
but we now include it for RI-consistency.
Yet another behaviour change is that we don't look at System
properties when choosing a SAX implementation. This simplifies
our internals significantly. End users who want an alternative
SAX implementation should construct it manually.
Also adding @KnownFailure tags for new tests that we have
never yet passed.
Change-Id: I6f81bedd7c2a0867086dc507b3220c2b07c4d3d3
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
libcore/JavaLibrary.mk
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started off with a mission to remove uses of dalvik.annotation.* (stuff
like @TestTargetNew and other useless junk that just makes it harder to
stay in sync with upstream). I wrote a script to go through tests showing
me the diff between what we have and what upstream has, thinking that in
cases where upstream has also added tests, I may as well pull them in at
the same time...
...but I didn't realize how close we were to having dx fill its 1.5GiB heap.
After trying various alternatives, I decided to bite the bullet and break
core-tests up into one .jar per module. This adds parallelism back into this,
the slowest part of our build. (I can do even better, but I'll do that in a
separate patch, preferably after we've merged recent changes from master.)
Only a couple of dependencies were problematic: the worthless TestSuiteFactory
which already contained a comment suggesting we get rid of it, and the fact
that some tests -- most notably the concurrent ones -- also contained main
methods that started the JUnit tty-based TestRunner.
(In the long run, we want to be running the harmony tests directly from a
pristine "svn co" of upstream, using DalvikRunner. But this will be a big
help in the meantime, and starts the work of getting our current copy of
the tests into a state where we can start to extract any meaningful
changes/additions we've made.)
|
| |
|
|
| |
The libcore "core" and "core-test" builds are now warning-free. (For Java.)
|
| | |
|
| |
|
|
| |
support.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New packages for Java 5 compatiblity:
- javax.xml.datatype
- javax.xml.namespace
- javax.xml.parsers (updated)
- javax.xml.transform
- javax.xml.transform.dom
- javax.xml.transform.sax
- javax.xml.transform.stream
- javax.xml.validation
- javax.xml.xpath
- org.w3c.dom (updated)
- org.w3c.dom.events
- org.w3c.dom.ls (load/save)
- org.w3c.dom.traversal
- org.w3c.dom.views
Omitted packages (that otherwise exist in Java 5)
- org.w3c.dom.bootstrap. This package facilitates pluggable implementations of DOM.
I'm not including this because there's little need for it in practice; and
because it adds an unnecessary layer of complexity. This decision is also
reflected in TransformerFactory.newInstance(), SAXParserFactory.newInstance(),
and DocumentBuilderFactory.newInstance().
New packages that pseudo-exist in Java 5
- org.w3c.dom.traversal
This package is referenced by Java 5's org.w3c.dom.ls.LSSerializerFilter, but
isn't included in the Javadoc API. Their spec isn't self-consistent.
- org.w3c.dom.views
This package is referenced by Java 5's org.w3c.dom.events.MouseEvent, but
isn't included in the Javadoc API. Another spec that isn't self-consistent.
This upgrades DOM from v2 to v3. http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/
This includes some API-incompatible changes; notably introducing new methods
into interfaces. I believe this is still safe, and Java made a similar backwards
incompatible change when they upgraded DOM from v2 to v3 between Java 1.4 and
Java 5.0.
Source for the new APIs comes from Apache XML commons.
http://svn.apache.org/repos/asf/xml/commons/trunk rev 901014.
This code currently contains several gaps in its implementation. In particular,
the impelementations of the DOM model classes (AttrImpl, ElementImpl, NodeImpl)
have DOM v3 methods that throw UnsupportedOperationExceptions. I intend to
address this problem in an immediate follow-up CL. All gaps are marked with TODO
comments, and they all live in the org.apache.harmony.xml.dom package.
To implement these APIs, I've included Apache Xalan. In a follow-up change
I intend to remove most of the code we don't actually need. I'm using their
pristine copy from SVN so Git can track our local modifications.
http://svn.apache.org/repos/asf/xalan/java/trunk rev 889881.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
core tests work better in the CTS
environment. Some tests had to be
marked broken either because they
either expose different behavior
than in run-core-tests or they
take too much time (beyond the
CTS' timeout).
BUG=1285921
Automated import of CL 147838
|
| | |
|
| | |
|
| | |
|
| |
|
