+1
Android's core libraries are derived from Harmony. In my mind that makes
Harmony one of Apache's most successful projects.
Occasionally Android developers are confused about which project they
should report bugs to. Moving Harmony to the Attic prevents
Android-specific bugs from going to the
Harmony folks,
Here on Android, we've been running Harmony's test suite on our devices. The
extensive test suite includes many large test methods that exercise many
behaviors. For example, consider this test method from
StringBuffer2Test.java:
public void test_insertI$CII() { // Test for method
On Sat, Oct 9, 2010 at 5:58 AM, Alexei Fedotov alexei.fedo...@gmail.comwrote:
I'm trying to understand best coding practices. Do you mean replacing
assertTrue to assertEquals for assertions like a = b? isAvailable()
assertions still may be implemented via assertTrue?
Mostly I prefer this:
Giampaolo,
The javax.print has an API
dependencyhttp://download.oracle.com/javase/6/docs/api/javax/print/ServiceUI.html
on
Java AWT, which is a desktop windowing UI. This will make it quite difficult
to implement the full API on Android. If you only need a narrower API, the
job may be
On Mon, Jul 5, 2010 at 8:02 PM, Deven You devyo...@gmail.com wrote:
I have written some simple benchmarks for harmony regex and find the
performance of harmony is poor compared to RI. For example, Mathcer.find()
only reach 60% of that of RI. I heard Android use icu4jni re-implement this
On Sun, Jul 4, 2010 at 8:05 PM, regi...@apache.org wrote:
File.counter could be accessed by multiple threads, so use AtomicInteger to
make
sure each thread using different int value to create temp file.
Is this a sufficient fix for the problem? The file system may be shared by
multiple
On Thu, May 27, 2010 at 4:04 PM, Joshua Bloch j...@google.com wrote:
I was a bit surprised to see efforts being made to improve Android docs.
The previous common wisdom had been ignore them; everyone with any sense
will read JDK JavaDocs instead.
The new goal of our team is, write better
On Tue, Mar 9, 2010 at 5:01 PM, Nathan Beyer ndbe...@apache.org wrote:
One concept I've been working with is using annotations to describe
the tests for the purposes of exclusions and for platform definition.
The annotations can then be utilized in many ways via JUnit - method
rules, request
I noticed something weird in commit 910980:
Author: hindessm
Date: Wed Feb 17 14:07:42 2010
New Revision: 910980
URL: http://svn.apache.org/viewvc?rev=910980view=rev
Log:
Thought I'd reverted this already ... reverting r903454. See:
http://markmail.org/thread/cdxlmi26mjgor3om
Modified:
On Wed, Feb 17, 2010 at 9:03 AM, Mark Hindess
mark.hind...@googlemail.comwrote:
I have solid evidence that this change is wrong... it breaks Harmony
tests that pass on the RI. I've no solid evidence that this change is
required. So my inclination is not to put the check back.
That's
On Tue, Jan 26, 2010 at 5:28 AM, Mark Hindess
mark.hind...@googlemail.comwrote:
I've just done a merge of the classlib tr...@901560 to the java6 branch.
There were quite a few conflicts this time around in particular with
TreeMap, TreeSet, and Properties so if you committed changes to these
On Tue, Jan 26, 2010 at 2:37 PM, Mark Hindess
mark.hind...@googlemail.comwrote:
Jesse,
Do you have a test case for the problem solved by adding this check? We
should probably include it in the test suite and it would be helpful in
finding an appropriate fix for the java6 branch.
Mark,
With commit
goog_1264006155813901123http://svn.apache.org/viewvc?view=revisionrevision=901123you
switched our CopyOnWriteArrayList from the JSR166 implementation to
Harmony's implementation. Could you give me some quick insight on the
tradeoffs here? If our implementation is indeed
On Tue, Jan 12, 2010 at 7:47 PM, Charles Lee littlee1...@gmail.com wrote:
What's the reason of bad idea? limited memory?
A cache that cannot be cleared is a disservice to users. It's an error in
our implementation (and the RI!) to assume that an application requesting
the canonical path two
On Mon, Nov 30, 2009 at 2:08 AM, Tim Ellison t.p.elli...@gmail.com wrote:
The method JarFile#getInputStream(ZipEntry) is spec'd to return an
InputStream, not a ZipInputStream.
Furthermore, as I showed, the RI returns a stream that answers with
available() 1, i.e. it follows the InputStream
On Thu, Nov 26, 2009 at 10:44 AM, Tim Ellison t.p.elli...@gmail.com wrote:
I know the arguments that say available() should not be used to judge
the total number of bytes that can be read, but it seems that a number
of applications (including our generated parser?) use it in this way.
And if
On Tue, Nov 24, 2009 at 6:31 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Name Tests Errors Failures
org.apache.harmony.logging.tests.java.util.logging13 1 0
This particular failure isn't being reported by Hudson...
On Tue, Nov 24, 2009 at 9:12 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Seems to be caused by a change in the implementation of available() for
InputStreams on Zip entries.
The failing code is in
org.apache.harmony.sound.utils.ProviderService#getProviders(String) when
it tries to read the
Yup; my bad. I can roll it back.
On Mon, Nov 23, 2009 at 7:36 AM, Oliver Deakin oliver.dea...@googlemail.com
wrote:
Looks like the commit at r882798 is causing some pack200 tests to fail:
org.apache.harmony.pack200.tests.ArchiveTest.testSQL
Rolled back as r883400. I'll investigate the Pack200 test problems and push
this back in after code freeze.
On Mon, Nov 23, 2009 at 8:40 AM, Jesse Wilson jessewil...@google.comwrote:
Rolled back as r883400. I'll investigate the Pack200 test problems and push
this back in after code freeze.
FYI: The root problem is a bug in our ZIP decoding. It fails to cope with
Z_SYNC_FLUSH blocks and crashes
My bad for committing during the code freeze.
Does it make sense to limit test changes during the code freeze? I don't see
any benefit.
On Mon, Nov 23, 2009 at 12:45 PM, sebb seb...@gmail.com wrote:
FYI:
I can open the jar using the RI jar application on WinXP, but Winzip
9.0 complains.
On people.apache.org the jar tool works but UnZip 6.00 reports:
6 extra bytes at beginning or within zipfile
(attempting to process
On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison t.p.elli...@gmail.com wrote:
On 23/Nov/2009 20:27, Jesse Wilson wrote:
My bad for committing during the code freeze.
So you're going to rollback, esp. so we don't exclude all the other
tests in that type?
I can certainly rollback the changes
On Mon, Nov 23, 2009 at 6:01 PM, Nathan Beyer ndbe...@apache.org wrote:
I'd love to see the exclude files dropped in favor of JUnit @Ignore +
reporting for those ignored tests. That would be extremely helpful in
pointing out all of the excluded tests.
Yes!
On Wed, Nov 18, 2009 at 8:47 AM, Nathan Beyer ndbe...@apache.org wrote:
I haven't browsed the code either, but I don't believe viewing this
code would kick in additional restrictions. If that's true, then Jesse
and other Android folks wouldn't be able to contribute much of
anything.
Yeah,
On Wed, Nov 18, 2009 at 9:43 AM, Tim Ellison t.p.elli...@gmail.com wrote:
You'd have to look a bit closer to see if these data
structures are used heavily,
Please avoid adding nonblocking behaviour where it isn't required by the
API. Of the usages that Tim pointed out, all either don't
On Wed, Nov 18, 2009 at 10:07 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Being consistent on checked exceptions like IOException is still
beneficial,
and we should continue to maintain our current behaviour.
Being consistent ... on throwing priority? So you are suggesting that
we
I should clarify that I'm only thinking about a particular set of unchecked
exceptions from java.lang: NullPointerException, IllegalArgumentException,
IllegalStateException, NoSuchElementException and IndexOutOfBoundsException.
Being consistent on checked exceptions like IOException is still
On Tue, Nov 17, 2009 at 7:56 AM, Tim Ellison t.p.elli...@gmail.com wrote:
The difference I see, by just staring at the code and without running
it, is that if the 'thrown' Throwable that was caught earlier is not one
of the tested types (IOException | RuntimeException | Error) then the
For better or for worse, Dalvik was changed long ago to ignore exception
priorities. We get exception messages for NPEs and save branches. The full
set of deltas are here:
http://www.google.com/codesearch?q=multiple+errors+lang:java+package:git://android.git.kernel.org/platform/dalvik.git
On Tue, Nov 17, 2009 at 8:53 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Now I've gone back and looked, they were never the real last 10 lines of
the close() method. More a case of, rather than code it like this ... I
did it like this ..., right?
Yes, I named the wrong file. But for a few
On Fri, Nov 13, 2009 at 1:48 AM, Mark Hindess
mark.hind...@googlemail.comwrote:
Anyone tried this? I wonder if we could use this to avoid arbitrary
sleeps that slow down our tests and potentially make them unstable?
That's what Weaver is intended for! And it also lets you test concurrency
On Fri, Nov 13, 2009 at 9:22 AM, Tim Ellison t.p.elli...@gmail.com wrote:
This commit breaks a couple of existing compatibility tests for
BufferedReader:
Yup, I saw this and I'm fixing it. I suspect it's just a bogus test. Sorry
about that!
On Fri, Nov 13, 2009 at 9:41 AM, Tim Ellison t.p.elli...@gmail.com wrote:
I took a look at the tests briefly, they are checking exception throwing
compatibility, something that we aim to maintain with the RI as rightly
or wrongly apps depend upon non-spec'd behavior.
Sorry about this guys.
Harmony team,
In the process of fixing a bug, I just checked in
SneakyThrowhttp://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/util/SneakyThrow.java?revision=835972view=markup.
This is a weird API that probably won't see much use. But it
Harmony team,
I'm skeptical of the utility of being exception-priority compatible with the
RI. We have a wiki
pagehttp://wiki.apache.org/harmony/Exception-throwing_compatibility
describes
our goals, but I don't think these are worth their costs.
Recently I broke tests by breaking exception
On Tue, Nov 10, 2009 at 1:47 AM, Mark Hindess
mark.hind...@googlemail.comwrote:
Since they aren't active on the list I'm not sure how much we should let
this influence our decision. It does suggest that we should be cautious
about making assumptions about what downstream users might like to
On Mon, Nov 9, 2009 at 4:14 AM, Tim Ellison t.p.elli...@gmail.com wrote:
I didn't mean to ask Why is a CopyOnWriteArrayList useful?, rather
what did it contribute to your logging improvements, e.g. correctness
that would require tons of duplicate coding otherwise, or performance
numbers, etc.
On Wed, Nov 4, 2009 at 4:11 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Like everyone else, I'm avoiding studying sources of Sun code, so can
you show the test case here (or on a JIRA)?
I attached it in the first message, but it looks like the mailing list
software silently discards
On Wed, Nov 4, 2009 at 2:53 PM, Mark Hindess mark.hind...@googlemail.comwrote:
That's not to say we shouldn't fix it. I just thought I'd mention it
in case anyone else is trying the same thing or in case anyone has any
other ideas on reproducing on our supported platforms.
Have you tried
Harmony team,
There's a bug in the RI's FilterOutputStream that causes exceptions to be
ignored. I'm unsure why they don't have a fix; perhaps they don't grasp how
dangerous this problem is.
http://bugs.sun.com/view_bug.do?bug_id=6390383
I've attached a program that demonstrates the bug. In
On Tue, Oct 27, 2009 at 7:20 AM, Tim Ellison t.p.elli...@gmail.com wrote:
The improvement in performance is impressive. What is the contribution
made by the use of the CopyOnWriteArrayList?
CopyOnWriteArrayList is ideal for situations when the following are all
true:
- reads are frequent
-
On Mon, Oct 26, 2009 at 8:26 AM, Oliver Deakin oliver.dea...@googlemail.com
wrote:
Wouldn't it be more appropriate to just relax the constraints on
hysock_connect_with_timeout?
Sure, what would you suggest? I believe the reason the portlib function was
implemented this way (only a short
Harmony Team,
Some of the Java code in Harmony suffers from being written in a non-Java
style. In particular, our Java code often attempts to limit the number of
exit points from a method. This approach is common in C/C++ programs because
of the need to manually collect garbage. But the approach
Harmony Team,
Continuing along with a theme, there's another C/C++ism in our Java code
that frustrates me. Our Java code frequently inverts conditions from their
natural language form. From HttpURLConnectionImpl:
if (null == resHeader) {
resHeader = new Header();
On Mon, Oct 26, 2009 at 3:44 PM, Mark Hindess
mark.hind...@googlemail.comwrote:
Modern programmers do refactoring and testing. I'm more than happy with
this. I want our code to be readable and using idiomatic style goes a
long way to achieving that. Working is important but being
On Fri, Oct 23, 2009 at 6:32 AM, odea...@apache.org wrote:
Author: odeakin
Date: Fri Oct 23 13:32:06 2009
New Revision: 829056
URL: http://svn.apache.org/viewvc?rev=829056view=rev
Log:
The port library hysock_connect_with_timeout() function only takes an
unsigned 32bit value as a timeout
On Mon, Oct 12, 2009 at 7:18 PM, Nathan Beyer nbe...@gmail.com wrote:
Honestly, the synchronization probably isn't appropriate on any of the
accessor/mutators - the granularity isn't correct. The locking
probably needs to encompass the entire method on DatagramSocket while
working on a
On Sun, Oct 11, 2009 at 3:15 PM, Mark Hindess
mark.hind...@googlemail.comwrote:
due to the change in HARMONY-6346 Several archive bugfixes and
optimizations.
This test passes on the RI but fails on Harmony as:
InflaterOutputStream.write(-1);
no longer throws a ZipException. Jesse
Mark,
Thanks for hanging along with me on these changes, and also for the heads up
on Regis' holiday.
On Thu, Oct 8, 2009 at 2:57 AM, Mark Hindess mark.hind...@googlemail.comwrote:
I think there is usually quite a lot of overlap between the goals of memory
efficiency and high throughput.
On Wed, Oct 7, 2009 at 1:26 PM, Tim Ellison t.p.elli...@gmail.com wrote:
I know that the InputStream here can only be a RAFStream or
InflaterInputStream, and both of them return available() as 1 so long as
the stream is not at the end, but in general I guess it is better to
read to the -1 eof
Mark and Tim,
Of the two giant patches I've submitted thus far
(archivehttps://issues.apache.org/jira/browse/HARMONY-6346and
crypto https://issues.apache.org/jira/browse/HARMONY-6347), you guys
omitted the MsgHelp changes. That's fine; those changes were
out-of-scope. But since I think the MsgHelp
On Thu, Oct 8, 2009 at 4:23 PM, Mark Hindess mark.hind...@googlemail.comwrote:
If I was in your position I'd probably try to:
1) Revert the author removal or justify why I thought it made sense
to the upstream and do it in one big change. It looks like you
are doing this with
On Thu, Oct 8, 2009 at 2:23 PM, Mark Hindess mark.hind...@googlemail.comwrote:
I was wondering about our modules and potential for re-use.
For example, archive, auth, awt, imageio, nio, prefs, sql, security,
suncompat, swing, and x-net modules depend on non-API packages in luni.
This sucks
On Thu, Oct 8, 2009 at 9:31 AM, odea...@apache.org wrote:
Add null check to equals() method.
// Checks two CredOwner objects for equality.
@Override
public boolean equals(Object obj) {
+if (obj == null) {
+return false;
+}
On Thu, Oct 1, 2009 at 7:19 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Could somebody please take a look a the patch below and see if they
believe my explanation for why it fixes a findbugs problem in InputStream?
Looks good to me.
Yes, this should fix the concurrency problem.
So Regis and I disagree on the merit of maintaining indices. Actually
disagreeing on such things is generally healthy since mobile/Android prefers
simplicity and memory efficiency, whereas serverside prefers high
throughput. Yet I still feel that the index optimizations were misguided,
On Tue, Sep 29, 2009 at 1:20 AM, Regis xu.re...@gmail.com wrote:
I think changes to the selected keys set doesn't help to show more
things.
Because there is no much difference in processSelectResult. And the reason
for maintaining readableFDs/writableFDs and mapping is avoiding O(num(keys))
On Mon, Sep 28, 2009 at 1:58 AM, Regis Xu (JIRA) j...@apache.org wrote:
In my understanding, SelectorBenchmark.java try to simulate a real
scenario of using selector, so I picked benchmark from HARMONY-4879 which
*only* test Selector.selectNow(), the result:
svn + no mapping
clients/active
Guys,
I recently updated the OS on my AMD64 box from 32-bit Ubuntu to 64-bit
Ubuntu. After updating and rebuilding Harmony (from clean), the J9 java
process just hangs forever. And I was careful to put the J9 files in their
proper place before I compiled anything.
Here's the output from file:
On Wed, Aug 19, 2009 at 5:44 AM, Mark Hindess
mark.hind...@googlemail.comwrote:
Since the latter is rather contrived case (and extra elapsed time for me is
only 4 seconds) then I think we can live with that.
Awesome!
On Mon, Aug 3, 2009 at 10:23 PM, Nathan Beyer ndbe...@apache.org wrote:
This reminds me, we need to put the standard Apache header on all
these files. Since they are under public domain (not actually a
license), we are actually taken ownership of the files. We can check
with legal-discuss@ if
Harmony folks,
I've started to watch the Harmony commit logs and I saw a commit that I
disagree with! I figured that it was a good opportunity for a discussion...
The commit fixed some style problems in the java.util.concurrent package. It
fixed whitespace problems and Javadoc inconsistencies,
On Tue, Jul 28, 2009 at 10:56 AM, Mark Hindess
mark.hind...@googlemail.comwrote:
Which commit? (Are you mistakenly referring to the recent trunk -
java6 branch merge commit?)
Yes, I'm mistakenly referring to a merge commit. It turns out that the
reformatting actually comes from upstream, so
2009/4/29 Alexei Fedotov alexei.fedo...@gmail.com
Also it needs checking why Android uses different XML parsers (maybe we can
switch to better ones as well?)
Harmony's XML stack is quite large. We Androids created our own
implementation that omits features like XSLT. Our code is built on
On Thu, Apr 16, 2009 at 6:05 PM, Jesse Wilson jessewil...@google.comwrote:
We Androids would love to contribute this documentation to Harmony.
Alongside improving the Harmony doc at large, it brings our copy of the code
closer in-sync with yours, which is a big win for us.
Update:
Javadoc
On Sat, Apr 18, 2009 at 12:34 PM, Nathan Beyer ndbe...@apache.org wrote:
Can you and anyone else looking to make contributions go through the
contribution policy [1] and get an ICLA/CCLA and an ACQ submitted?
I faxed the paperwork to Apache this morning.
Thanks,
Jesse
Hi!
I'm a developer on the Android core libraries, many of which are derived
from Harmony. In October, Android Dan Bornstein
saidhttp://markmail.org/message/7o2w7asiftn7o3dl that
A Day Of Reckoning would someday come, where we reintegrate Android and
Harmony sources. I'm working on that effort.
70 matches
Mail list logo
