Why not put all the tests that control String's behavior to the suite?
Are there any possible harmful differences that are untestable?
Thanks,
Mikhail
2006/4/21, bootjvm [EMAIL PROTECTED]:
I have been watching this issue closely because it will directly
affect my work on BootJVM with the
Ok I see :)
Would you mind if I integrate your testcase into the current test?
Thanks,
Mikhail
2006/4/21, Mark Hindess [EMAIL PROTECTED]:
On 4/21/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Mark
Is there some reason why you are not putting new regression tests into an
existing
Not at all.
-Mark.
On 4/21/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Ok I see :)
Would you mind if I integrate your testcase into the current test?
Thanks,
Mikhail
2006/4/21, Mark Hindess [EMAIL PROTECTED]:
On 4/21/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Mark
Is there some
Mark,
This is the test from the second patch, it is not quite clear which test
from the first patch do you mean. Am I missing something?
=
Author: mloenko
Date: Thu Apr 20 23:23:20 2006
New Revision: 395794
URL:
+1.Unit tests that control the critical behavior usually are more useful
than any kind of locking or byte-to-byte comparison.
On 4/21/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Why not put all the tests that control String's behavior to the suite?
Are there any possible harmful differences
I suggest you write a helper method to create a String with that
constructor using reflection (setAccessible(true)).
Regards,
Tim
Nathan Beyer wrote:
Since I probably share some responsibility in the String is special topic
being brought up, I wanted to try out the golden ticket bit for some
Mark Hindess wrote:
To celebrate the opening of my 100th JIRA earlier today, I thought I'd
produce some simple statistics - using 138 lines of ugly Perl - for
the HARMONY JIRAs.
The columns are key, percentage, count. The letters in the bars
are the first characters of the Resolutions from
Hi Daniel,
I've taken a look at ITC's implementation of java.math (original
Harmony-199 donation) and tried to compare it to one donated by
Harmony-39 on the method-by-method base.
For example, I've tested about 30 BigInteger's methods and the result is
the following:
- 10 ITC's methods
2006/4/21, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Well, the reason is we did not discuss the topic here
Sure. What would you like to discuss?
1. Do we put all the messages into one file or per-module?
2. When I tried to internationalize it with Eclipse it suggested me
keys
On Fri, Apr 21, 2006 at 10:15:38AM +0100, Tim Ellison wrote:
Mark Hindess wrote:
To celebrate the opening of my 100th JIRA earlier today,
Whoah! :-)
I thought I'd
produce some simple statistics - using 138 lines of ugly Perl - for
the HARMONY JIRAs.
kewl. Lets keep this our little
Nathan,
My work on java.util.Formatter blocks on this issue and Harmony-348,
because you are the contributor of initial StringBuilder implementation,
so I'd like to know if you are willing to patch them? Otherwise I'll
try. Thank you. :-)
Paulex Yang (JIRA) wrote:
java.lang.StringBuilder
Mikhail Loenko wrote:
2006/4/21, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Well, the reason is we did not discuss the topic here
Sure. What would you like to discuss?
1. Do we put all the messages into one file or per-module?
I'd prefer one catalog per module now that we have
On 4/21/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
2006/4/21, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Well, the reason is we did not discuss the topic here
Sure. What would you like to discuss?
1. Do we put all the messages into one file or
On 4/21/06, Anton Avtamonov wrote:
On 4/21/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
2006/4/21, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Well, the reason is we did not discuss the topic here
Sure. What would you like to discuss?
1. Do we
On 4/21/06, Stepan Mishura [EMAIL PROTECTED] wrote:
SNIP
Creating and maintaining these (accessor/strings) is trivial in the
Eclipse string externalization tool.
Right.
And what about developers that don't use Eclipse?
They can create an accessor manually. Eclipse just helps to
On 4/21/06, Anton Avtamonov wrote:
On 4/21/06, Stepan Mishura wrote:
SNIP
Creating and maintaining these (accessor/strings) is trivial in the
Eclipse string externalization tool.
Right.
And what about developers that don't use Eclipse?
They can create an accessor manually.
2006/4/21, Anton Avtamonov [EMAIL PROTECTED]:
On 4/21/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
2006/4/21, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Well, the reason is we did not discuss the topic here
Sure. What would you like to discuss?
Anton Avtamonov wrote:
On 4/21/06, Tim Ellison [EMAIL PROTECTED] wrote:
snip
I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
I'm not sure. Module name IMHO doesn't make too much sense since it is
already 'coded' into accessor location and class location. I would
prefer
Stepan Mishura wrote:
snip
And what about developers that don't use Eclipse?
The code that Eclipse produces is pretty much what you would do by hand
anyway IMHO. In any case, we can create the accessors in Eclipse and
commit them for everyone to use, then the other folk just have to worry
about
On 4/21/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
SNIP
I'm not sure. Module name IMHO doesn't make too much sense since it is
already 'coded' into accessor location and class location. I would
prefer class_name.message intention like
RandomAccessFile.file_is_closed
or something similar
Stuart,
Any chance that we can get a link to Harmony results on the
http://www.kaffe.org/~stuart/japi/ page, to show people who come via
your tool?
Thanks!
Tim
Stuart Ballard wrote:
Japi diff jdk11 vs harmony:
Full results:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony.html
On 4/21/06, Tim Ellison [EMAIL PROTECTED] wrote:
Anton Avtamonov wrote:
On 4/21/06, Tim Ellison [EMAIL PROTECTED] wrote:
snip
I'd prefer the module name '.', i.e. beans.1, beans.2, and so on.
I'm not sure. Module name IMHO doesn't make too much sense since it is
already 'coded' into
Hi Alex,
Alex Orlov wrote,
BTW do we have any way to include stress/reliability tests in the
project?
We still don't have a solution about stress/reliability testing in
Harmony. I think this is important part of testing if we want to enable
Enterprise servers running on Harmony stack for years.
Hi,
Could somebody please explain me do we mix up regression and unit tests?
I noticed that the luni module has two kind of test packages (under
the luni/src/test/java directory). A name of one of them starts with
the org.apache.harmony.tests string. Another one starts with the
tests string.
Daniel Fridlender wrote:
Dear all,
on behalf of ITC I have updated our contribution of the package
java.math including some recent optimizations (HARMONY-199). I think
it would be interesting to compare our implementation with the one
donated by Intel (HARMONY-39). In order to do that, it
This is great stuff. It will be fun to integrate all of this together
to get the best of both.
Now, with that happy and positive yet blatantly naive statement out there...
How monolithic are these implementations? Will it even be possible to
integrate, or do the internals reflect enough
So howabout a firmer test that will break when string is changed? that
might at least let you sleep better.
geir
Tim Ellison wrote:
Ok, so reading everyone's post it seems that:
- we agree that there should be some way to ensure people do
not inadvertently modify String's shape, but
regarding policytool, are there any current foss implementations in
progress that anyone knows of..
On 4/21/06, Tim Ellison [EMAIL PROTECTED] wrote:
Sanket Sharma wrote:
Performance analysis sounds interesting...
Any links/pointers to get started?
I suggest that you look around for some
Daniel,
I'm really sorry I can't provide you with a reasonable doc.
Of course we had some drafts and outlines when we were planning
the development, but it never took the form of a formal document.
Vasily
-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED]
Sent: Friday,
Tim Ellison wrote:
Mikhail Loenko wrote:
2006/4/21, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Well, the reason is we did not discuss the topic here
Sure. What would you like to discuss?
1. Do we put all the messages into one file or per-module?
I'd prefer one catalog per
Daniel,
black-box testing (reverse engineering I would call the complete
procedure)
Black-box testing is NOT reverse engineering, as the latter could
suggest disassembling the code or something like that, that would
violate the clean-room procedures and that we certainly didn't do. What
we were
Hi Vladimir,
Yes, I can make our results public of course. We have tested both
implementations for RSA key generation, which is a mix of random prime
generation and modular arithmetic (such as multiplicative inverse
calculation).
The testing platform was:
CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz
Hi Elena,
thank you very much for having a look at our contribution and
reporting the results of your tests. We have also done some
method-by-method comparisons, our results were similar to yours.
I agree with you that the difference in performance in methods of
BigInteger is due to the
Daniel Fridlender wrote:
Hi Vladimir,
Yes, I can make our results public of course. We have tested both
implementations for RSA key generation, which is a mix of random prime
generation and modular arithmetic (such as multiplicative inverse
calculation).
The testing platform was:
CPU:
Thanks for the heads up. I posted a patch on the issue.
-Nathan
-Original Message-
From: Paulex Yang [mailto:[EMAIL PROTECTED]
Sent: Friday, April 21, 2006 5:07 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-383) java.lang.StringBuilder should
Hi Geir,
Unfortunately both implementations have different internal representation.
Therefore all algorithms have been implemented in accordance with them.
I see no way to integrate them.
I'd also like to note it's insufficiently to measure the performance
using only one of the real applications
36 matches
Mail list logo
