Here is one more case when 1.5 RI is inconsistent and contradicts the spec.
Consider the following code:
Provider[] pp = Security.getProviders(Provider.id);
System.out.println((pp==null? null : pp[0]));
pp = Security.getProviders(Provider.id name:SUN);
Hi Mark,
Update 396968 renamed tests in 'text' module. Could you provide a new patch
for this module?
Thanks,
Stepan.
On 4/25/06, Stepan Mishura wrote:
It would be nice to have a new combined patch.
Thanks,
Stepan.
On 4/25/06, Mark Hindess wrote:
Stepan
These patches have lots
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Chris Gray wrote:
On Monday 24 April 2006 23:34, Geir Magnusson Jr wrote:
1) Could we simply have a classloader that can be put in a special
mode
so it doesn't that unit tests for bootclasspath-resident packages are
What I'm trying to convey is:
1) We should be doing spec-driven development, not development based on
probing the behavior of any particular implementation of the spec (even
the RI).
I believe this is in best keeping with the spirit of Sun's intent for
independent implementations of Java.
2)
If nobody objects to this patch to String I'll go ahead and apply it --
looks good to me.
http://issues.apache.org/jira/browse/HARMONY-292
(Writing the 'brutal' VMI tests is still on my to-do list)
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Mikhail Loenko wrote:
Hello
I'd like to bring this thread back.
Number of tests is growing and it is time to put them in order.
So far we may have:
1) implementation-specific tests that designed to be run from bootclasspath
2) implementation-specific tests that might be run from classpath
3)
George Harley wrote:
Mikhail Loenko wrote:
Hello
I'd like to bring this thread back.
Number of tests is growing and it is time to put them in order.
So far we may have:
1) implementation-specific tests that designed to be run from
bootclasspath
2) implementation-specific tests that might
On 26 April 2006 at 14:50, Stepan Mishura [EMAIL PROTECTED] wrote:
Hi Mark,
Update 396968 renamed tests in 'text' module. Could you provide a new
patch for this module?
It should just be:
sed
Looks like a conversation best conducted on the dev list...
Original Message
Subject: [jira] Commented: (HARMONY-410) method decode(ByteBuffer,
CharBuffer, boolean) should set correct position in ByteBuffer
Date: Wed, 26 Apr 2006 08:25:03 + (GMT+00:00)
From: Vladimir Strigun
Oliver Deakin wrote:
George Harley wrote:
Mikhail Loenko wrote:
Hello
I'd like to bring this thread back.
Number of tests is growing and it is time to put them in order.
So far we may have:
1) implementation-specific tests that designed to be run from
bootclasspath
2)
how about 'specific'? impl seems to be not very informative.
I have a concern abou proposed package naming guidelines:
package name
org.apache.harmony.security.tests.org.apache.harmony.security
is not much better then 1000-character long test name.
Thanks,
Mikhail
2006/4/26, Paulex Yang
Hi Vladimir,
I think we both understand the spec :)
Here I propose two solutions:
1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in
decoder. Invokers doesn't care the position of in. If the result is
UNDERFLOW and there're furthur input, just pass the new input to the
Mark Hindess wrote:
On 26 April 2006 at 14:50, Stepan Mishura [EMAIL PROTECTED] wrote:
Hi Mark,
Update 396968 renamed tests in 'text' module. Could you provide a new
patch for this module?
It should just be:
sed
Mikhail Loenko wrote:
how about 'specific'? impl seems to be not very informative.
+1 to Oliver's impl :-)
I have a concern abou proposed package naming guidelines:
package name
org.apache.harmony.security.tests.org.apache.harmony.security
is not much better then 1000-character long
I agree with Mikhail here: package names should be short and informative.
Thanks,
Stepan.
On 4/26/06, Mikhail Loenko wrote:
how about 'specific'? impl seems to be not very informative.
I have a concern abou proposed package naming guidelines:
package name
On 26 April 2006 at 10:36, George Harley
[EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 26 April 2006 at 14:50, Stepan Mishura
[EMAIL PROTECTED] wrote:
Hi Mark,
Update 396968 renamed tests in 'text' module. Could you provide a
new patch for this module?
It
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi Vladimir,
I think we both understand the spec :)
Here I propose two solutions:
1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in
decoder. Invokers doesn't care the position of in. If the result is
UNDERFLOW and
Hi Tim,
May I ask for minor clarification just to make sure (looks like it is
not fully covered here).
In case the spec definitely says something which is not true for RI we should:
- base on spec
- base on RI
- discuss in the mailing list
I think that is the very core question which we cannot
Tim Ellison wrote:
Looks like a conversation best conducted on the dev list...
I have to admit I actually laughed out loud. Thx :)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe,
Seems like implemantation-specific tests for java.security package do not
fit well into the proposed solution
I think we do not have to stick to requirement about
organization name in the tests: we already have tests in package java.*
why don't have package tests.*?
Thanks,
Mikhail
2006/4/26,
On 4/26/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Seems like implemantation-specific tests for java.security package do not
fit well into the proposed solution
I think we do not have to stick to requirement about
organization name in the tests: we already have tests in package java.*
why
Vladimir Strigun wrote:
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I try to find best solution for Harmony-166 and during fix preparation
I've found current issue.
Method test_read from tests.api.java.io.InputStreamReaderTest failed
and first fix I've created was with in.available()
2006/4/26, Andrew Zhang [EMAIL PROTECTED]:
Vladimir Strigun wrote:
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I try to find best solution for Harmony-166 and during fix preparation
I've found current issue.
Method test_read from tests.api.java.io.InputStreamReaderTest failed
Mikhail Loenko wrote:
Seems like implemantation-specific tests for java.security package do not
fit well into the proposed solution
I think we do not have to stick to requirement about
organization name in the tests: we already have tests in package java.*
why don't have package tests.*?
IMHO discuss on the mailing list is always a good option, I just
wouldn't expect any discussion around items that work in the RI the way
they are described in the spec :-) we just do those!
Where there is some discrepancy or question, I see no problem with
people giving a heads up to their
Mikhail Loenko wrote:
2006/4/26, Andrew Zhang [EMAIL PROTECTED]:
Vladimir Strigun wrote:
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I try to find best solution for Harmony-166 and during fix preparation
I've found current issue.
Method test_read from
Andrew Zhang wrote:
Mikhail Loenko wrote:
2006/4/26, Andrew Zhang [EMAIL PROTECTED]:
Vladimir Strigun wrote:
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I try to find best solution for Harmony-166 and during fix preparation
I've found current issue.
Method test_read from
2006/4/26, Paulex Yang [EMAIL PROTECTED]:
Andrew Zhang wrote:
Mikhail Loenko wrote:
2006/4/26, Andrew Zhang [EMAIL PROTECTED]:
Vladimir Strigun wrote:
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I try to find best solution for Harmony-166 and during fix preparation
I've found
George Harley wrote:
Mikhail Loenko wrote:
Hello
I'd like to bring this thread back.
Number of tests is growing and it is time to put them in order.
So far we may have:
1) implementation-specific tests that designed to be run from
bootclasspath
2) implementation-specific tests that
Oliver Deakin wrote:
George Harley wrote:
Mikhail Loenko wrote:
Of course, the text module has only implementation-independent tests
that designed to be run from classpath. For modules that have got
implementation-specific tests then I suppose we could use something
like
Richard Liang wrote:
Mikhail Loenko wrote:
how about 'specific'? impl seems to be not very informative.
+1 to Oliver's impl :-)
I have a concern abou proposed package naming guidelines:
package name
org.apache.harmony.security.tests.org.apache.harmony.security
is not much better
Mikhail Loenko wrote:
Hello
I'd like to bring this thread back.
Number of tests is growing and it is time to put them in order.
So far we may have:
1) implementation-specific tests that designed to be run from bootclasspath
2) implementation-specific tests that might be run from classpath
Geir Magnusson Jr wrote:
George Harley wrote:
Of course, the text module has only implementation-independent tests
that designed to be run from classpath. For modules that have got
implementation-specific tests then I suppose we could use something
like
Tim Ellison wrote:
What I'm trying to convey is:
1) We should be doing spec-driven development, not development based on
probing the behavior of any particular implementation of the spec (even
the RI).
I believe this is in best keeping with the spirit of Sun's intent for
independent
+1
Stepan Mishura wrote:
Ok, let's it be rule number 1 for testing serialization:
- resource file for testing serialilzation MUST have 'ser' extention.
Thanks,
Stepan.
On 4/25/06, Tim Ellison wrote:
.ser is commonly used for Java serialized form
Geir,
The problem is that no one yet suggested a consistent solution
that would fit for all the tests and would not get into packages like
org.apache.harmony.security.tests.org.apache.harmony.security.util
Everybody seems to agree that SOME implementation specific tests are
in the same package
2006/4/27, Geir Magnusson Jr [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Hello
I'd like to bring this thread back.
Number of tests is growing and it is time to put them in order.
So far we may have:
1) implementation-specific tests that designed to be run from bootclasspath
2)
Vladimir Strigun wrote:
On 4/26/06, Paulex Yang [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
Mikhail Loenko wrote:
2006/4/26, Andrew Zhang [EMAIL PROTECTED]:
Vladimir Strigun wrote:
On 4/26/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I try to find best
Mikhail Loenko wrote:
Geir,
The problem is that no one yet suggested a consistent solution
that would fit for all the tests and would not get into packages like
org.apache.harmony.security.tests.org.apache.harmony.security.util
Everybody seems to agree that SOME implementation specific tests
Hi,
I'd like to discuss naming conventions for serialization tests - does it
make sense to separate serialization tests from unit tests?
For example, in module security tests for serialization were placed into
separate packages:
java.security.serialization
java.security.cert.serialization
Paulex,
we have at least 8 categories of tests:
running from classpath or bootclasspath
implementation specific or independent
testing org.apache.harmony.* or java.*
Could you please list how all the tests will be named
Thanks,
Mikhail
2006/4/27, Paulex Yang [EMAIL PROTECTED]:
As far as most of serialization tests extend SerializationTest then
having serialization test cases included into a regular unit tests
would cause that ALL the tests will extend SerializationTest that is
not very good.
Thanks,
Mikhail
2006/4/27, Stepan Mishura [EMAIL PROTECTED]:
Hi,
I'd like
42 matches
Mail list logo
