It means we should compare both implementations on the method-by-method base
to understand where there is the performance degradation. Obviously new
tests should be implemented
for this purpose. Those methods look worse should be replaced if they have
no internal representation's dependency.
Now
Look at HARMONY-387.
Example:
1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
Harmony throws ArrayIndexOutOfBoundsException when off0 or/and len
0, while RI throws IndexOutOfBoundsException.
Specification mentions neither ArrayIndexOutOfBoundsException nor
The answer to this question (in my opinion) depends on how TCK processes
similar situations.
If we want to successfully perform this suite on Harmony we should be
compatible with RI.
For certain there are a lot of tests into TCK will fail due to this reason
and we should be ready for this.
2006/4/24, Anton Avtamonov [EMAIL PROTECTED]:
On 4/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Look at HARMONY-387.
Example:
1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
Harmony throws ArrayIndexOutOfBoundsException when off0 or/and len
0, while RI throws
Hi,
I thought that we agreed on utilizing JUnit's exception handling (see [1]).
So the next code from added unit test doesn't follow this convention. Also
why it checks the same code twice?
try {
Inet6Address.getByAddress(123, addr2, 3);
} catch (UnknownHostException e) {
fail(no
Anton Avtamonov wrote:
On 4/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Look at HARMONY-387.
Example:
1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
Harmony throws ArrayIndexOutOfBoundsException when off0 or/and len
0, while RI throws IndexOutOfBoundsException.
Mikhail,
I also thought about this scenario. However, if any TCK tests will fail due
to this reason
we cannot certify our product. Nobody will talk about the invalidity of TCK.
Most likely we will update our sources.
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
There
On 4/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
SNIP
Yeah, in case RI operates with classes not from public API I would
propose to base on spec. Or use the nearest class from public API if
spec doesn't work for some reasons.
Actually, spec even contains sometimes references to the
Stepan Mishura wrote:
Hi,
I thought that we agreed on utilizing JUnit's exception handling (see [1]).
So the next code from added unit test doesn't follow this convention. Also
why it checks the same code twice?
try {
Inet6Address.getByAddress(123, addr2, 3);
} catch (UnknownHostException
On 4/24/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Stepan Mishura wrote:
Hi,
I thought that we agreed on utilizing JUnit's exception handling (see [1]).
So the next code from added unit test doesn't follow this convention. Also
why it checks the same code twice?
try {
That's right, we took in a number of contributions and merged the tests
in as quickly as we could, so we now have most of the tests being run
regularly.
We should go through and rename the packages to a consistent convention
(and it might as well be now as later).
Regards,
Tim
Mark Hindess
Sorry, I should have caught that during review, I'll help Andrew fix it.
Thanks for point it out.
Tim
Andrew Zhang wrote:
Anton Avtamonov wrote:
On 4/24/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Stepan Mishura wrote:
Hi,
I thought that we agreed on utilizing JUnit's exception handling
Has anyone else considered the possibility of splitting the harmony-dev
list ? As a memory manager/VM hacker, I'm interested to keep up with
the high level happenings in the harmony world, but not necessarily with
the low-level details of bugs in the class library (and so forth).
What do
El lun, 24-04-2006 a las 14:48 +0700, Vladimir Gorr escribió:
Mikhail,
I also thought about this scenario. However, if any TCK tests will fail due
to this reason we cannot certify our product. Nobody will talk about the
invalidity of TCK.
Most likely we will update our sources.
Not
On 4/24/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
Thanks,
Vladimir Gorr
Intel Middleware Products Division.
On a totally unrelated matter, I'm amazed and the number of people
apparently working at Intel's middleware division.
It seems there is much more intel middleware than what I've ever
Good question :-). Actually I can say I'm aware about four Vladimirs working
at Intel Middleware Product Division.
There also are a little of Sergeys, Romans ... :-). I suppose you will like
the following signature (others, I'm sorry for spam):
Thanks,
Vladimir.
On 4/24/06, Fernando Cassia
On 4/24/06, Santiago Gala [EMAIL PROTECTED] wrote:
El lun, 24-04-2006 a las 14:48 +0700, Vladimir Gorr escribió:
Mikhail,
I also thought about this scenario. However, if any TCK tests will fail
due
to this reason we cannot certify our product. Nobody will talk about the
invalidity of
I've thought about it, but I think that it's a bit premature. Why?
Because I think that once we fracture the list traffic, we lose a lot of
the intermixing that's important.
I think once we have a lot more VM traffic, it makes perfect sense.
However, I think that as an intermediate step though
Magnusson, Geir skrev den 24-04-2006 14:39:
:)
SSG == Solutions and Software Group
P = product
D = Division
Guess what M stands for...
:)
Geir, I was wondering if you could make an informal statement regarding
how IBM and Intel is backing the harmony project? Sounds like there is
I agree with Geir. It's a good idea to keep classlib and vm people
aware of what the others are doing. Sometimes, issues that might seem
unrelated by classlib or vm people might actually affect the other
group. I much prefer the suggested [topic] approach.
Etienne
Magnusson, Geir wrote:
I've
On 4/24/06, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote:
Magnusson, Geir skrev den 24-04-2006 14:39:
:)
SSG == Solutions and Software Group
P = product
D = Division
Guess what M stands for...
:)
Geir, I was wondering if you could make an informal statement regarding
Magnusson, Geir wrote:
:)
SSG == Solutions and Software Group
P = product
D = Division
Guess what M stands for...
Magnusson's ?
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of
Vasily,
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
Hi Vasily,
I believe we should sum up and start specific threads for each topic;
This is a list of topics and posting names I suggest:
a) Improve Specification -- [rmi] improve spec
We agreed in the problems the spec has. I believe here -Harmony-
is the place to start a request for
I've tried to capture in a webpage the compatibility guidelines that we
have agreed over the last few weeks.
The page is here:
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
I'm sure I'll have forgotten something, so additions / corrections /
etc. are welcome.
oh, you're hilarious...
Tim Ellison wrote:
Magnusson, Geir wrote:
:)
SSG == Solutions and Software Group
P = product
D = Division
Guess what M stands for...
Magnusson's ?
Tim
-
Terms of use :
Thorbjørn Ravn Andersen wrote:
Magnusson, Geir skrev den 24-04-2006 14:39:
:)
SSG == Solutions and Software Group
P = product
D = Division
Guess what M stands for...
:)
Geir, I was wondering if you could make an informal statement regarding
how IBM and Intel is backing the harmony
nice. thanks.
Tim Ellison wrote:
I've tried to capture in a webpage the compatibility guidelines that we
have agreed over the last few weeks.
The page is here:
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
I'm sure I'll have forgotten something, so additions /
Chris Gray wrote:
On Sunday 23 April 2006 02:07, Daniel Fridlender wrote:
I also agree with [Vladimir] that it would be really nice to have a
representative collection of realistic applications of the
functionality of java.math. RSA key generation is definitely one of
them. We should find
Vladimir Gorr wrote:
Mikhail,
I also thought about this scenario. However, if any TCK tests will fail due
to this reason
we cannot certify our product. Nobody will talk about the invalidity of TCK.
Most likely we will update our sources.
1) I hadn't thought about this before, but it seems
Or just put the test in java.lang as an implementation test.
We should resolve this. Among others, we're going to have spec tests,
which Tim and others rightly point out that we need to be careful with
and keep out of the boot classpath to ensure that tests happen in the
context of userland.
There have been some good suggestions, but I want to check and be sure
that the project we propose has enough original work - IOW, there may
be some requirement about new functionality.
Either way, I have another suggestion for a SOC project, which would be
very benficial (IMO) to our
I'd back what Santiago said:
I think the design should not suffer from such a problem, as
the parent says. Only for trivial changes I'd rename an exception.
Thanks,.
Mikhail
2006/4/25, Geir Magnusson Jr [EMAIL PROTECTED]:
Vladimir Gorr wrote:
Mikhail,
I also thought about this
Geir Magnusson Jr wrote:
Vladimir Gorr wrote:
Mikhail,
I also thought about this scenario. However, if any TCK tests will
fail due
to this reason
we cannot certify our product. Nobody will talk about the invalidity
of TCK.
Most likely we will update our sources.
1) I hadn't thought
Vladimir,
Method available() is still used to determine endOfInput parameter.
According to specification the
method should be overridden by subclasses.
'should' does not mean 'must' , moreover it might be a user class who
does not care what the spec says. There could be cases when you do not
Geir Magnusson Jr wrote:
IOW :
VM + host classlib + SpecialTestFramework(candidate classlib)
if that makes any sense...
I think the perfect SoC project could be to have Gump using Harmony.
Either Leo or myself could volunteer to be the mentors.
--
Stefano.
Hi,
Can we at least agree on extension for serialization resource files?
Defining common extension can be a first step in merging serialization
frameworks.
Modules: beans, jndi, logging, luni, nio_char, text – contain serialization
resource files with extension 'ser'. (48 files total)
And files
On 4/25/06, Stepan Mishura wrote:
Hi,
Can we at least agree on extension for serialization resource files?
Defining common extension can be a first step in merging serialization
frameworks.
Sorry, I meant merging testing frameworks to test serialization.
-Stepan.
Modules: beans, jndi,
38 matches
Mail list logo
