Re: [doc] Compatibility guidelines
Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary source is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. Another minor comment regarding to the serialization compatibility: What if serialization form is not specified and the spec states that serialization form will not be compatible with future releases? Does it mean we want to copy the existing serialization form? Or we are going to define our own? Should it be reflected in the guidelines? Wishes, -- Anton Avtamonov, Intel Middleware Products Division On 4/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: 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 / corrections / etc. are welcome. Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
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 not on the boot classpath? If you mean that the custom classloader would try to load classes named (say) java.*.Test* itself instead of delegating to its parent, then you should find that the VM won't let you - I'm pretty sure that's in the spec somewhere. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Jimmy, Jing Lv wrote:
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 about this before, but it seems much cleaner to
throw A (rather than B extends A) if the spec says to throw A.
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
throws IOException rather than throws
ConnectionException,UnknownHostException. And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
+1, and other instances where super-types or super-interfaces declare
compatible throws clauses that are implemented in subclasses that throw
more specific subtypes. I do not agree that we should be bound to throw
and exception of the identical type as the declaration.
2) and we may find some javadoc as ...then an unspecified error is
thrown. For an example, in java.util.jar.Pack200.newPacker(). We can do
nothing to meet such compatibility.
You can throw any Error to comply with that specification!
Regards,
Tim
In summary, I think we shall follow doc in throwing exception; but if we
find it inconvenient indeed or even impossible, let it be. :)
2) You can challenge TCK tests and have them eliminated. We've done
it for J2EE and other specs. I believe that we're going to be in for
quite a bit of it because for all practical purposes, we'll be the
first use of the TCK on an independent implementation of Java SE.
geir
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
There is nothing about TCK here: if the spec requires to throw A
and we throw B that extends A then we follow the spec
And if there is a TCK test that verifies that we throw A and only A
then the test is invalid and we will not have to pass it
Sometimes it is an easy fix to throw A rather then B.
But there could be two RI methods - one throwing A and another one
throwing B
such that in our implementation they both refer to some third method.
In this case if we throw B in that 3rd method - then we conform the
spec,
we won't break existing apps and it might cause design weakening
if we choose to go coping how RI works.
So if the fix is easy then I'd agree to what folks say here, but in
general case
I'd not set the rule to follow RI this way.
Thanks,
Mikhail
2006/4/24, Vladimir Gorr [EMAIL PROTECTED]:
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.
Thanks,
Vladimir.
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.
Specification mentions neither ArrayIndexOutOfBoundsException nor
IndexOutOfBoundsException.
Actually ArrayIndexOutOfBoundsException is a sub class of
IndexOutOfBoundsException.
So the statement both Harmony and RI throw
IndexOutOfBoundsException
is
true.
But do we have to throw exactly those exceptions that are thrown by
RI?
Can we throw
o.a.h.VMRisenNPE that extends NullPointerException?
What if they throw kind of
sun.internal.SunFavoriteSubClassOfNullPointerException ?
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
Anton Avtamonov wrote: Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary source is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. That's what I thought we agreed. If the guide does not make that clear then I am happy to clarify. Another minor comment regarding to the serialization compatibility: What if serialization form is not specified and the spec states that serialization form will not be compatible with future releases? Does it mean we want to copy the existing serialization form? Or we are going to define our own? Should it be reflected in the guidelines? I suggest that we copy the current RI form (if we can deduce it honestly) to get better interoperability. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resource files for testing serialization - .dat or .ser?
.ser is commonly used for Java serialized form http://filext.com/detaillist.php?extdetail=SER Regards, Tim 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. Modules: beans, jndi, logging, luni, nio_char, text – contain serialization resource files with extension 'ser'. (48 files total) And files in modules auth, crypto, security, x-net have extension '.dat'. (296 files total) So which one? Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary source is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. That's what I thought we agreed. If the guide does not make that clear then I am happy to clarify. Guidelines clearly mentioned that. I could not recall if everyone was agree or not :-). As I remember there were lots of people who proposed to base on RI behavior only (to be as much comatible as possible). Personally I'm completely agree with guidelines approach. Another minor comment regarding to the serialization compatibility: What if serialization form is not specified and the spec states that serialization form will not be compatible with future releases? Does it mean we want to copy the existing serialization form? Or we are going to define our own? Should it be reflected in the guidelines? I suggest that we copy the current RI form (if we can deduce it honestly) to get better interoperability. +1. -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote:
Jimmy, Jing Lv wrote:
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
throws IOException rather than throws
ConnectionException,UnknownHostException. And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
+1, and other instances where super-types or super-interfaces declare
compatible throws clauses that are implemented in subclasses that throw
more specific subtypes. I do not agree that we should be bound to throw
and exception of the identical type as the declaration.
If we want to follow the spec and if we want to restrain ourself from
improving the spec, I think we really need to throw IOException. If
this exception can be caused by different ways we apparently have to
throw IOException with an appropriate cause.
Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [admin] Split the list (was RE: Split the list ?)
Nathan Beyer wrote: I'll add my vote to using the [topic] markers. This works well for other Apache projects like Jakarta Commons. I think they've split of some separate mailing lists, but this was based on the sheer volume for certain projects. +1. We could also give some common-used topic list. e.g., [classlib], [admin], etc. Maybe we already have them in place. ;-) I'd also add using the [topic] markers in subject line of JIRA issues too, but that may not be everyone's liking. -Nathan -Original Message- From: Etienne Gagnon [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 8:51 AM To: harmony-dev@incubator.apache.org Subject: Re: [admin] Split the list (was RE: Split the list ?) 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 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 we should all work very hard to tag our subject lines with a [topic] :) -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM
Re: [classlib] resource files for testing serialization - .dat or .ser?
Tim Ellison wrote: .ser is commonly used for Java serialized form http://filext.com/detaillist.php?extdetail=SER So we will rename the 296 files? wow ;-) Regards, Tim 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. Modules: beans, jndi, logging, luni, nio_char, text – contain serialization resource files with extension 'ser'. (48 files total) And files in modules auth, crypto, security, x-net have extension '.dat'. (296 files total) So which one? Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM
Re: svn commit: r396803 - in /incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/tests/api/java/math: BigDecimalTest.java BigIntegerTest.java
On 25 April 2006 at 7:34, [EMAIL PROTECTED] wrote:
Author: mloenko
Date: Tue Apr 25 00:34:21 2006
New Revision: 396803
URL: http://svn.apache.org/viewcvs?rev=396803view=rev
Log:
applied changes for the tests from HARMONY-319:
BigDecimal and Biginteger test failures should be fixed
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigDecimalTest.java
incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigIntegerTest.java
Modified: incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/jav
a/tests/api/java/math/BigDecimalTest.java
URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/
modules/math/src/test/java/tests/api/java/math/BigDecimalTest.java?rev=396803
r1=396802r2=396803view=diff
=
=
--- incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigDecimalTest.java (original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigDecimalTest.java Tue Apr 25 00:34:21 2006
[ SNIP ]
@@ -128,22 +127,48 @@
/**
* @tests java.math.BigDecimal#BigDecimal(java.lang.String)
*/
+ public void test_constructor_String_empty() {
+ boolean gotNFE = false;
+ try {
+ new BigDecimal();
+ } catch (NumberFormatException e) {
+ gotNFE = true;
+ } catch (Throwable e) {
+ fail(Unexpected exception for new BigDecimal(\\) +
e);
+ }
+ if (!gotNFE) {
+ fail(Expected NumberFormatException for new BigDecimal
(\\));
+ }
+ }
I thought we'd agreed to write tests like this as:
public void test_constructor_String_empty() {
try {
new BigDecimal();
fail(Expected NumberFormatException for new BigDecimal(\\));
} catch (NumberFormatException e) {
// expected
}
}
and let junit handle the unexpected exception cases?
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/25/06, Dmitry M. Kononov [EMAIL PROTECTED] wrote:
On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote:
Jimmy, Jing Lv wrote:
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
throws IOException rather than throws
ConnectionException,UnknownHostException. And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
+1, and other instances where super-types or super-interfaces declare
compatible throws clauses that are implemented in subclasses that throw
more specific subtypes. I do not agree that we should be bound to throw
and exception of the identical type as the declaration.
If we want to follow the spec and if we want to restrain ourself from
improving the spec, I think we really need to throw IOException. If
this exception can be caused by different ways we apparently have to
throw IOException with an appropriate cause.
From the general perspective, in the example above re-throwing
IOException looks quite ugly. Besides, it hides some important
information (since Java uses exception sub-classing to represent the
particular type of problem). However we are not free with design, I
think. Could someone please remind me an idea: for the example above
do we mean that the spec states IOException and RI throws exactly
IOException (I traversed the thread, but still not sure what was
meant)?
The idea behind the question is: why not just copy RI in this case
(conforming Tim's guidelines)?
--
Anton Avtamonov,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resource files for testing serialization - .dat or .ser?
On 4/25/06, Richard Liang [EMAIL PROTECTED] wrote: Tim Ellison wrote: .ser is commonly used for Java serialized form http://filext.com/detaillist.php?extdetail=SER So we will rename the 296 files? wow ;-) If we will be affraid to beautify different contributions to be in the single style we will have something very ugly and consisting of different patches rather than a product. IMHO, it is fine to rename :-) Wishes, -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry
On 25 April 2006 at 9:22, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-162?page=all ] Paulex Yang updated HARMONY-162: Attachment: Harmony162.zip Please try this patch, thanks Paulex, In the interest of getting more eyes on patches, it might be better not to zip attachments unless there are an excessive number of them. In this case, attaching the three files individually would mean that others could scan the .sh and .diff files using a browser rather than having to download and unzip the .zip. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Anton Avtamonov wrote:
On 4/25/06, Dmitry M. Kononov [EMAIL PROTECTED] wrote:
On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote:
Jimmy, Jing Lv wrote:
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
throws IOException rather than throws
ConnectionException,UnknownHostException. And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
+1, and other instances where super-types or super-interfaces declare
compatible throws clauses that are implemented in subclasses that throw
more specific subtypes. I do not agree that we should be bound to throw
and exception of the identical type as the declaration.
If we want to follow the spec and if we want to restrain ourself from
improving the spec, I think we really need to throw IOException. If
this exception can be caused by different ways we apparently have to
throw IOException with an appropriate cause.
From the general perspective, in the example above re-throwing
IOException looks quite ugly. Besides, it hides some important
information (since Java uses exception sub-classing to represent the
particular type of problem). However we are not free with design, I
think. Could someone please remind me an idea: for the example above
do we mean that the spec states IOException and RI throws exactly
IOException (I traversed the thread, but still not sure what was
meant)?
For the example 1) I mean the spec usually merge several exceptions into
one parent exception. In this situation, commonly RI throws child
exception itself, although it is hard to tell what RI exactly throw in
some special situation.
And I think we are not improving the spec if we throw child
exceptions, it is just convention or something writing throws
IOException instead of writing throws connectionException,
UnknownHostException. We do follow spec if we throw child exception.
The idea behind the question is: why not just copy RI in this case
(conforming Tim's guidelines)?
Yes,I firmly agree with Tim's guidelines. We should first follow spec
and then RI. In this case, we still follow the spec, right? :)
--
Anton Avtamonov,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (HARMONY-353) improvements to junit test method usage
Stepan These patches have lots of clashes now. I have new versions if you'd like me to upload them - or I can upload a new combined patch? -Mark. On 25 April 2006 at 9:56, Stepan Mishura (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-353?page=all ] Stepan Mishura reassigned HARMONY-353: -- Assign To: Stepan Mishura improvements to junit test method usage --- Key: HARMONY-353 URL: http://issues.apache.org/jira/browse/HARMONY-353 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Stepan Mishura Priority: Trivial Attachments: 01.assertnull.diff, 02.assertequals.string.diff, 03.assertequ als.constants.diff, 04.assertequals.char.constants.diff, 05.assertnotnull.dif f, assert.usage.combined.diff, improved.assertequals.usage.diff While fixing the test in HARMONY-352, I found some confusing junit error messages. They were things like: error expected actual but got expected rather than: error expected expected but got actual Because the arguments to the assertEquals method were the wrong way around. The expected value should come first. Anyway, I fixed these for that one test. We should try to fix these when we find them and we should try to avoid adding any more. This JIRA is because I decided that it was reasonable to fix any method lik e: assertEquals(..., constant); since a constant couldn't very well be the value being tested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (HARMONY-353) improvements to junit test method usage
It would be nice to have a new combined patch. Thanks, Stepan. On 4/25/06, Mark Hindess wrote: Stepan These patches have lots of clashes now. I have new versions if you'd like me to upload them - or I can upload a new combined patch? -Mark. On 25 April 2006 at 9:56, Stepan Mishura (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-353?page=all ] Stepan Mishura reassigned HARMONY-353: -- Assign To: Stepan Mishura improvements to junit test method usage --- Key: HARMONY-353 URL: http://issues.apache.org/jira/browse/HARMONY-353 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Stepan Mishura Priority: Trivial Attachments: 01.assertnull.diff, 02.assertequals.string.diff, 03.assertequ als.constants.diff, 04.assertequals.char.constants.diff, 05.assertnotnull.dif f, assert.usage.combined.diff, improved.assertequals.usage.diff While fixing the test in HARMONY-352, I found some confusing junit error messages. They were things like: error expected actual but got expected rather than: error expected expected but got actual Because the arguments to the assertEquals method were the wrong way around. The expected value should come first. Anyway, I fixed these for that one test. We should try to fix these when we find them and we should try to avoid adding any more. This JIRA is because I decided that it was reasonable to fix any method lik e: assertEquals(..., constant); since a constant couldn't very well be the value being tested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resource files for testing serialization - .dat or .ser?
On Tuesday 25 April 2006 11:23, Anton Avtamonov wrote: If we will be affraid to beautify different contributions to be in the single style we will have something very ugly and consisting of different patches rather than a product. A patchy implementation of J2SE? That would never do. (8-) -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry
Mark, Good point. I preferred zip because it is much smaller than separated files. In most cases, comparing with the total size of all separated files, the zip's size is about 1/7, so that it is also easier to download(someone still need to download the bytes even browsing in browser). And IMHO, the JIRA system is not so stable, so probably I'm a little too closehanded ;). I'm glad to be more helpful if most ones prefer separated files. Mark Hindess wrote: On 25 April 2006 at 9:22, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-162?page=all ] Paulex Yang updated HARMONY-162: Attachment: Harmony162.zip Please try this patch, thanks Paulex, In the interest of getting more eyes on patches, it might be better not to zip attachments unless there are an excessive number of them. In this case, attaching the three files individually would mean that others could scan the .sh and .diff files using a browser rather than having to download and unzip the .zip. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/25/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: SNIP For the example 1) I mean the spec usually merge several exceptions into one parent exception. In this situation, commonly RI throws child exception itself, although it is hard to tell what RI exactly throw in some special situation. And I think we are not improving the spec if we throw child exceptions, it is just convention or something writing throws IOException instead of writing throws connectionException, UnknownHostException. We do follow spec if we throw child exception. The idea behind the question is: why not just copy RI in this case (conforming Tim's guidelines)? Yes,I firmly agree with Tim's guidelines. We should first follow spec and then RI. In this case, we still follow the spec, right? :) Absolutely! The question was: why we decided to throw sub-classing exceptions. If the answer is: because RI does I completely support such decision (which completely complies Tim's guidelines). -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r396803 - in /incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/tests/api/java/math: BigDecimalTest.java BigIntegerTest.java
We did. I'll fix it.
Would you volunteer providing a patch that replaces assertTrue with assertEquals
in the remaining test methods?
Thanks,
Mikhail
2006/4/25, Mark Hindess [EMAIL PROTECTED]:
On 25 April 2006 at 7:34, [EMAIL PROTECTED] wrote:
Author: mloenko
Date: Tue Apr 25 00:34:21 2006
New Revision: 396803
URL: http://svn.apache.org/viewcvs?rev=396803view=rev
Log:
applied changes for the tests from HARMONY-319:
BigDecimal and Biginteger test failures should be fixed
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigDecimalTest.java
incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigIntegerTest.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/jav
a/tests/api/java/math/BigDecimalTest.java
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/
modules/math/src/test/java/tests/api/java/math/BigDecimalTest.java?rev=396803
r1=396802r2=396803view=diff
=
=
---
incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigDecimalTest.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/math/src/test/java/test
s/api/java/math/BigDecimalTest.java Tue Apr 25 00:34:21 2006
[ SNIP ]
@@ -128,22 +127,48 @@
/**
* @tests java.math.BigDecimal#BigDecimal(java.lang.String)
*/
+ public void test_constructor_String_empty() {
+ boolean gotNFE = false;
+ try {
+ new BigDecimal();
+ } catch (NumberFormatException e) {
+ gotNFE = true;
+ } catch (Throwable e) {
+ fail(Unexpected exception for new BigDecimal(\\)
+
e);
+ }
+ if (!gotNFE) {
+ fail(Expected NumberFormatException for new
BigDecimal
(\\));
+ }
+ }
I thought we'd agreed to write tests like this as:
public void test_constructor_String_empty() {
try {
new BigDecimal();
fail(Expected NumberFormatException for new BigDecimal(\\));
} catch (NumberFormatException e) {
// expected
}
}
and let junit handle the unexpected exception cases?
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry
On 25 April 2006 at 18:25, Paulex Yang [EMAIL PROTECTED] wrote: Mark, Good point. I preferred zip because it is much smaller than separated files. In most cases, comparing with the total size of all separated files, the zip's size is about 1/7, so that it is also easier to download(someone still need to download the bytes even browsing in browser). And IMHO, the JIRA system is not so stable, so probably I'm a little too closehanded ;). I'm glad to be more helpful if most ones prefer separated files. Sure, I'd use an archive if the files were large, but the largest in this case is only 6k which isn't really a big deal (even for Geir on-a-plane). Of course, I realise that browsing is just a more convinient form of downloading. But, IMHO, the 85% saving per download on attachments this size is insignificant. The real saving obtained by using a zip file comes from the fact that fewer people will bother to download it! This is a saving that I think the project would be better to manage without. ;-) Regards, Mark. Mark Hindess wrote: On 25 April 2006 at 9:22, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-162?page=all ] Paulex Yang updated HARMONY-162: Attachment: Harmony162.zip Please try this patch, thanks Paulex, In the interest of getting more eyes on patches, it might be better not to zip attachments unless there are an excessive number of them. In this case, attaching the three files individually would mean that others could scan the .sh and .diff files using a browser rather than having to download and unzip the .zip. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Jimmy, Jing Lv wrote:
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 about this before, but it seems much cleaner to
throw A (rather than B extends A) if the spec says to throw A.
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
throws IOException rather than throws
ConnectionException,UnknownHostException. And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
Agreed. What I meant was not throwing some internal class whose
ancestor is ...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: relying on 'available()' (was: RE: [jira] Updated: (HARMONY-166) method read() in InputStreamReader failed to read one character)
psst... hey, Mikhail... how about a [classlib] on this subject line? :)
Mikhail Loenko wrote:
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
know how many bytes are available and you have to return 0.
So I think the patch should be modified to avoid 'available()'
Thanks,
Mikhail
-Original Message-
From: Vladimir Strigun (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Monday, April 24, 2006 5:14 PM
To: [EMAIL PROTECTED]
Subject: [jira] Updated: (HARMONY-166) method read() in
InputStreamReader failed to read one
character
[ http://issues.apache.org/jira/browse/HARMONY-166?page=all ]
Vladimir Strigun updated HARMONY-166:
-
Attachment: InputStreamReader.java.patch
Mikhail,
please review my patch. Now method read() is not modified. I just
add decoding operations to
fillBuf() method.
Method available() is still used to determine endOfInput parameter.
According to specification the
method should be overridden by subclasses.
method read() in InputStreamReader failed to read one character
---
Key: HARMONY-166
URL: http://issues.apache.org/jira/browse/HARMONY-166
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Attachments: InputStreamReader.java.patch, InputStreamReader.patch.txt,
InputStreamReaderTest.java
I've started to play with harmony-57 contribution and found bug in
InputStreamReader class.
Method read() should read a single character from input stream but it
works incorrectly for 2
bytes-per-char charsets. Example below shows that it failed to read
one character in UTF-16
charset. Sorry for so ugly test, it's just a part of
InputStreamReaderTest from Harmony-57
contribution.
import java.io.*;
import junit.framework.TestCase;
public class InputStreamReaderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InputStreamReaderTest.class);
}
public void test_ISR_read() throws Exception {
InputStream in;
InputStreamReader reader;
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16BE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u6172');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
e.printStackTrace();
fail(UTF-16BE unexpected 1: + e);
}
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16LE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 2: + e);
}
try {
in = new LimitedByteArrayInputStream(1);
reader = new InputStreamReader(in, UTF-16);
assertTrue(Incorrect byte UTF-16BE, reader.read() == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 3: + e);
}
try {
in = new LimitedByteArrayInputStream(2);
reader = new InputStreamReader(in, ISO2022JP);
int ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 1: + ch, ch == '\u4e5d');
ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 2: + ch, ch == '\u7b2c');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
fail(ISO2022JP unexpected: + e);
}
}
static class LimitedByteArrayInputStream extends ByteArrayInputStream {
// A ByteArrayInputStream that only returns a single byte per read
byte[] bytes;
int count;
public LimitedByteArrayInputStream(int type) {
super(new byte[0]);
switch (type) {
case 0:
bytes = new byte[] { 0x61, 0x72 };
break;
case 1:
bytes = new byte[] { (byte) 0xff, (byte) 0xfe, 0x61, 0x72 };
break;
case 2:
bytes = new byte[] { '\u001b', '$', 'B', '6', 'e', 'B', 'h',
'\u001b', '(', 'B' };
break;
}
count = bytes.length;
}
public int read() {
if (count == 0)
return -1;
count--;
return bytes[bytes.length - count];
}
public int read(byte[] buffer, int offset, int length) {
if (count == 0)
return -1;
if (length == 0)
return 0;
buffer[offset] = bytes[bytes.length - count];
count--;
return 1;
}
public int available() {
return count;
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry
I'm convinced, and have practiced in your way, see Harmony-346:) Mark Hindess wrote: On 25 April 2006 at 18:25, Paulex Yang [EMAIL PROTECTED] wrote: Mark, Good point. I preferred zip because it is much smaller than separated files. In most cases, comparing with the total size of all separated files, the zip's size is about 1/7, so that it is also easier to download(someone still need to download the bytes even browsing in browser). And IMHO, the JIRA system is not so stable, so probably I'm a little too closehanded ;). I'm glad to be more helpful if most ones prefer separated files. Sure, I'd use an archive if the files were large, but the largest in this case is only 6k which isn't really a big deal (even for Geir on-a-plane). Of course, I realise that browsing is just a more convinient form of downloading. But, IMHO, the 85% saving per download on attachments this size is insignificant. The real saving obtained by using a zip file comes from the fact that fewer people will bother to download it! This is a saving that I think the project would be better to manage without. ;-) Regards, Mark. Mark Hindess wrote: On 25 April 2006 at 9:22, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-162?page=all ] Paulex Yang updated HARMONY-162: Attachment: Harmony162.zip Please try this patch, thanks Paulex, In the interest of getting more eyes on patches, it might be better not to zip attachments unless there are an excessive number of them. In this case, attaching the three files individually would mean that others could scan the .sh and .diff files using a browser rather than having to download and unzip the .zip. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
Yes, that would be another great project, but will there be enough of a coding element? I was reading through the SOC docs, and while it's not beaten over the readers head, there does appear to be a strong requirement of developing new code. As an example, working on an OSS project doing documentation isn't sufficient (which is a shame, IMO) geir Stefano Mazzocchi wrote: 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. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
Tim Ellison wrote: Anton Avtamonov wrote: Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary source is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. That's what I thought we agreed. If the guide does not make that clear then I am happy to clarify. I don't recall that. When Paulex first summarized our discussion, I thought that we decide those on a case by case basis, as our intention is to have SDK/JRE that works identically to that from IBM, BEA, Sun... Another minor comment regarding to the serialization compatibility: What if serialization form is not specified and the spec states that serialization form will not be compatible with future releases? Does it mean we want to copy the existing serialization form? Or we are going to define our own? Should it be reflected in the guidelines? I suggest that we copy the current RI form (if we can deduce it honestly) to get better interoperability. +1 geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
Anton Avtamonov wrote: On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary source is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. That's what I thought we agreed. If the guide does not make that clear then I am happy to clarify. Guidelines clearly mentioned that. I could not recall if everyone was agree or not :-). As I remember there were lots of people who proposed to base on RI behavior only (to be as much comatible as possible). Personally I'm completely agree with guidelines approach. The problem is that in the real world, we're going to have trouble defending why everyone else is wrong, and we are correct. This is why I'd like to discuss and be able to go w/ RI behavior, and in either case, WRITE EVERYTHING DOWN so that for diversions from the RI we can make it easy for users to see why their code breaks on Harmony when it runs everywhere else and for diversions from spec, we can eventually come back after some time when we have achieved World Dominance(tm) and fix them... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
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 not on the boot classpath? If you mean that the custom classloader would try to load classes named (say) java.*.Test* itself instead of delegating to its parent, then you should find that the VM won't let you - I'm pretty sure that's in the spec somewhere. We are writing the VM - what I meant was have that mode for the Vm... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry
+1 Mark Hindess wrote: On 25 April 2006 at 9:22, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-162?page=all ] Paulex Yang updated HARMONY-162: Attachment: Harmony162.zip Please try this patch, thanks Paulex, In the interest of getting more eyes on patches, it might be better not to zip attachments unless there are an excessive number of them. In this case, attaching the three files individually would mean that others could scan the .sh and .diff files using a browser rather than having to download and unzip the .zip. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry
Mark Hindess wrote: On 25 April 2006 at 18:25, Paulex Yang [EMAIL PROTECTED] wrote: Mark, Good point. I preferred zip because it is much smaller than separated files. In most cases, comparing with the total size of all separated files, the zip's size is about 1/7, so that it is also easier to download(someone still need to download the bytes even browsing in browser). And IMHO, the JIRA system is not so stable, so probably I'm a little too closehanded ;). I'm glad to be more helpful if most ones prefer separated files. Sure, I'd use an archive if the files were large, but the largest in this case is only 6k which isn't really a big deal (even for Geir on-a-plane). I either have them on the plane, or not. I don't fly cool airlines w/ broadband. I did once, on BA about 3 years ago, but that was only once. It was very cool. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
On 4/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary source is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. That's what I thought we agreed. If the guide does not make that clear then I am happy to clarify. Guidelines clearly mentioned that. I could not recall if everyone was agree or not :-). As I remember there were lots of people who proposed to base on RI behavior only (to be as much comatible as possible). Personally I'm completely agree with guidelines approach. The problem is that in the real world, we're going to have trouble defending why everyone else is wrong, and we are correct. This is why I'd like to discuss and be able to go w/ RI behavior, and in either case, WRITE EVERYTHING DOWN so that for diversions from the RI we can make it easy for users to see why their code breaks on Harmony when it runs everywhere else and for diversions from spec, we can eventually come back after some time when we have achieved World Dominance(tm) and fix them... I see I was right that we didn't have an agreement :-) Geir, I completely understood you point and even agree with you. My idea (and I believe Tim's guidelines support it) was to avoid copying of definite RI bugs. Just because I believe that there are no (or almost no) applications which are based on something which is definitely bug, not feature. However your proposal just to be as good as RI does for now, 'mark' all problems and revise them later definitely makes sense. Let's say I'm neutral and wait for others opinions. I'm sure that this is very key question and we have to achieve an agreement here. Wishes, -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
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 not on the boot classpath? If you mean that the custom classloader would try to load classes named (say) java.*.Test* itself instead of delegating to its parent, then you should find that the VM won't let you - I'm pretty sure that's in the spec somewhere. We are writing the VM - what I meant was have that mode for the Vm... The point of the VMI is to support multiple VM implementations, so unless you require this mode from every Harmony-compatible VM ... Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
Anton, look at Do we want to be bug compatible? thread everybody agreed to the scheme: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with spec; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case 5. Log every difference from either the spec or the RI in JIRA. Thanks, Mikhail 2006/4/25, Anton Avtamonov [EMAIL PROTECTED]: On 4/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Anton Avtamonov wrote: Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary source is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. That's what I thought we agreed. If the guide does not make that clear then I am happy to clarify. Guidelines clearly mentioned that. I could not recall if everyone was agree or not :-). As I remember there were lots of people who proposed to base on RI behavior only (to be as much comatible as possible). Personally I'm completely agree with guidelines approach. The problem is that in the real world, we're going to have trouble defending why everyone else is wrong, and we are correct. This is why I'd like to discuss and be able to go w/ RI behavior, and in either case, WRITE EVERYTHING DOWN so that for diversions from the RI we can make it easy for users to see why their code breaks on Harmony when it runs everywhere else and for diversions from spec, we can eventually come back after some time when we have achieved World Dominance(tm) and fix them... I see I was right that we didn't have an agreement :-) Geir, I completely understood you point and even agree with you. My idea (and I believe Tim's guidelines support it) was to avoid copying of definite RI bugs. Just because I believe that there are no (or almost no) applications which are based on something which is definitely bug, not feature. However your proposal just to be as good as RI does for now, 'mark' all problems and revise them later definitely makes sense. Let's say I'm neutral and wait for others opinions. I'm sure that this is very key question and we have to achieve an agreement here. Wishes, -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
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 not on the boot classpath? If you mean that the custom classloader would try to load classes named (say) java.*.Test* itself instead of delegating to its parent, then you should find that the VM won't let you - I'm pretty sure that's in the spec somewhere. We are writing the VM - what I meant was have that mode for the Vm... The point of the VMI is to support multiple VM implementations, so unless you require this mode from every Harmony-compatible VM ... No, just the one we're going to use to test the classlibrary. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Testing Convention] Stress tests: requirements review needed
Hi Alexander, Let me question the following requirement from your list: o System should have a possibility to vary test behavior and stress conditions using arguments Actually I'm thinking here about a test suite built from a simple blocks like small and fast unit tests, or functional tests Do you have in mind some standard glue for these simple building blocks as well? See examples below. * Loop generator If we have some simple unit or functional test, the reasonable stress is to execute this test in a loop. * Thread generator It makes sense to put GC-stressing activity in a loop in parallel with some test. * Stress precondition We can fill most of the memory, and run a simple test afterwards. * Wildcards in test names We may like to stress in some way each test from the package of tests. Do you mean all this rich set of possibilities should be passed via command line arguments? How can we make this notation compact and understandable? With best regards, Alexei Fedotov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[admin] Build status messages
Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
On 4/25/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Anton, look at Do we want to be bug compatible? thread everybody agreed to the scheme: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with spec; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case 5. Log every difference from either the spec or the RI in JIRA. Mikhail, I suppose that Tim's guidelines are generally about the same. Am I wrong? And as you can see it is not something which everyone agreed on: at least Geir's position is different. Or I got him wrong? -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: relying on 'available()' (was: RE: [jira] Updated: (HARMONY-166) method read() in InputStreamReader failed to read one character)
Mikhail,
OK, I'll prepare new patch. I've found other 2 issues that can affect
InputStreamReader and I'll submit it soon.
Thanks.
Vladimir.
On 4/25/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
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
know how many bytes are available and you have to return 0.
So I think the patch should be modified to avoid 'available()'
Thanks,
Mikhail
-Original Message-
From: Vladimir Strigun (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Monday, April 24, 2006 5:14 PM
To: [EMAIL PROTECTED]
Subject: [jira] Updated: (HARMONY-166) method read() in
InputStreamReader failed to read one
character
[ http://issues.apache.org/jira/browse/HARMONY-166?page=all ]
Vladimir Strigun updated HARMONY-166:
-
Attachment: InputStreamReader.java.patch
Mikhail,
please review my patch. Now method read() is not modified. I just
add decoding operations to
fillBuf() method.
Method available() is still used to determine endOfInput parameter.
According to specification the
method should be overridden by subclasses.
method read() in InputStreamReader failed to read one character
---
Key: HARMONY-166
URL: http://issues.apache.org/jira/browse/HARMONY-166
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Attachments: InputStreamReader.java.patch, InputStreamReader.patch.txt,
InputStreamReaderTest.java
I've started to play with harmony-57 contribution and found bug in
InputStreamReader class.
Method read() should read a single character from input stream but it
works incorrectly for 2
bytes-per-char charsets. Example below shows that it failed to read
one character in UTF-16
charset. Sorry for so ugly test, it's just a part of
InputStreamReaderTest from Harmony-57
contribution.
import java.io.*;
import junit.framework.TestCase;
public class InputStreamReaderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InputStreamReaderTest.class);
}
public void test_ISR_read() throws Exception {
InputStream in;
InputStreamReader reader;
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16BE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u6172');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
e.printStackTrace();
fail(UTF-16BE unexpected 1: + e);
}
try {
in = new LimitedByteArrayInputStream(0);
reader = new InputStreamReader(in, UTF-16LE);
int xx = reader.read();
assertTrue(Incorrect byte UTF-16BE, xx == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 2: + e);
}
try {
in = new LimitedByteArrayInputStream(1);
reader = new InputStreamReader(in, UTF-16);
assertTrue(Incorrect byte UTF-16BE, reader.read() == '\u7261');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
} catch (IOException e) {
fail(UTF-16BE unexpected 3: + e);
}
try {
in = new LimitedByteArrayInputStream(2);
reader = new InputStreamReader(in, ISO2022JP);
int ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 1: + ch, ch == '\u4e5d');
ch = reader.read();
assertTrue(Incorrect byte ISO2022JP 2: + ch, ch == '\u7b2c');
} catch (UnsupportedEncodingException e) {
// Can't test without the converter
System.out.println(e);
} catch (IOException e) {
fail(ISO2022JP unexpected: + e);
}
}
static class LimitedByteArrayInputStream extends ByteArrayInputStream {
// A ByteArrayInputStream that only returns a single byte per read
byte[] bytes;
int count;
public LimitedByteArrayInputStream(int type) {
super(new byte[0]);
switch (type) {
case 0:
bytes = new byte[] { 0x61, 0x72 };
break;
case 1:
bytes = new byte[] { (byte) 0xff, (byte) 0xfe, 0x61, 0x72 };
break;
case 2:
bytes = new byte[] { '\u001b', '$', 'B', '6', 'e', 'B', 'h',
'\u001b', '(', 'B' };
break;
}
count = bytes.length;
}
public int read() {
if (count == 0)
return -1;
count--;
return bytes[bytes.length - count];
}
public int read(byte[] buffer, int offset, int length) {
if (count == 0)
return -1;
if (length == 0)
return 0;
buffer[offset] = bytes[bytes.length - count];
count--;
return 1;
}
public int available() {
return count;
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one
Re: [admin] Build status messages
I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [admin] Build status messages
Seems that SVN was unreachable from here for a while. I see it is building now so fingers-crossed for a BUILD SUCCESSFUL message any time soon. Regards, Tim Geir Magnusson Jr wrote: I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [admin] Build status messages
From my nag system messages, there was a problem in infra, but things look like they are back together. geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 11:09 AM To: harmony-dev@incubator.apache.org Subject: Re: [admin] Build status messages Seems that SVN was unreachable from here for a while. I see it is building now so fingers-crossed for a BUILD SUCCESSFUL message any time soon. Regards, Tim Geir Magnusson Jr wrote: I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [admin] Build status messages
So note that there may be delay in recovery - gettting the mail that queued up back out... geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [admin] Build status messages From my nag system messages, there was a problem in infra, but things look like they are back together. geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 11:09 AM To: harmony-dev@incubator.apache.org Subject: Re: [admin] Build status messages Seems that SVN was unreachable from here for a while. I see it is building now so fingers-crossed for a BUILD SUCCESSFUL message any time soon. Regards, Tim Geir Magnusson Jr wrote: I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Testing
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) implementation-specific tests that designed to be run from classpath 4) implementation-independent tests that designed to be run from bootclasspath 5) implementation-independent tests that might be run from classpath 6) implementation-independent tests that designed to be run from classpath Also we seem to have the following packages, where the tests are: 1) the same package as implementation 2) org.apache.harmony.tests.[the same package as implementation] 3) tests.api.[the same package as implementation] I suggest that we work out step-by-step solution as we could not reach an agreement for the general universal one So for the first step I suggest that we separate i-independent tests that must or may be run from classpath I suggest that we put them into package tests.module.compatible.[package of implementation being tested] Comments? Thanks, Mikhail 2006/3/24, George Harley [EMAIL PROTECTED]: Geir Magnusson Jr wrote: Leo Simons wrote: On Wed, Mar 22, 2006 at 08:02:44AM -0500, Geir Magnusson Jr wrote: Leo Simons wrote: On Wed, Mar 22, 2006 at 07:15:28AM -0500, Geir Magnusson Jr wrote: Pulling out of the various threads where we have been discussing, can we agree on the problem : We have unique problems compared to other Java projects because we need to find a way to reliably test the things that are commonly expected to be a solid point of reference - namely the core class library. Further, we've been implicitly doing integration testing because - so far - the only way we've been testing our code has been 'in situ' in the VM - not in an isolated test harness. To me, this turns it into an integration test. Sure, we're using JUnit, but because of the fact we are implmenting core java.* APIs, we aren't testing with a framework that has been independently tested for correctness, like we would when testing any other code. I hope I got that idea across - I believe that we have to go beyond normal testing approaches because we don't have a normal situation. Where we define 'normal situation' as running a test framework on top of the sun jdk and expecting any bugs to not be in that jdk. There's plenty of projects out there that have to test things without having such a stable reference JDK luxury.I imagine that testing GCC is just as hard as this problem we have here :-) Is it the same? We need to have a running JVM+classlibarary to test the classlibrary code. Well you need a working C compiler and standard C library to compile the compiler so you can compile make so you can build bash so you can run perl (which uses the standard C library functions all over the place of course) so you can run the standard C library tests so that you know that the library you used when compiling the compiler were correct so you can run the compiler tests. I don't think they actually do things that way, but it seems like basically the same problem. Having a virtual machine just makes it easier since you still assume the native world as a baseline, which is a lot more than the hardware. There's a difference. You can use a completely separate toolchain to build, test and verify the output of the C compiler. In our case, we are using the thing we are testing to test itself. There is no known good element possible right now. We use the classlibrary we are trying to test to execute the test framework that tests the classlibrary that is running it. The tool is testing itself. So I think there are three things we want to do (adopting the terminology that came from the discussion with Tim and Leo ) : 1) implementation tests 2) spec/API tests (I'll bundle together) 3) integration/functional tests I believe that for #1, the issues related to being on the bootclasspath don't matter, because we aren't testing that aspect of the classes (which is how they behave integrated w/ the VM and security system) but rather the basic internal functioning. I'm not sure how to approach this, but I'll try. I'd love to hear how Sun, IBM or BEA deals with this, or be told why it isn't an issue :) Implementation tests : I'd like to see us be able to do #1 via the standard same-package technique (i.e. testing a.b.C w/ a.b.CTest) but we'll run into a tangle of classloader problems, I suspect, becuase we want to be testing java.* code in a system that already has java.* code. Can anyone see a way we can do this - test the classlibrary from the integration point of view - using some test harness + any known-good JRE, like Sun's or IBM's? Ew, that won't work in the end since we should assume our own JRE
Re: [doc] Compatibility guidelines
Geir agreed to 1-5 guidline in Do we want to be bug compatible? thread. Probably doc does not exactly match them. Let's ask Geir Thanks, Mikhail 2006/4/25, Anton Avtamonov [EMAIL PROTECTED]: On 4/25/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Anton, look at Do we want to be bug compatible? thread everybody agreed to the scheme: 1. we should comply with spec 2. if RI is contradict with spec, and RI is not logical(sometimes it is very obvious, you know what I mean), we comply with spec; else, we discuss it case by case. 3. if spec is not so clear, we should comply with RI 4. if some application failing on that different behavior, we discuss it case by case 5. Log every difference from either the spec or the RI in JIRA. Mikhail, I suppose that Tim's guidelines are generally about the same. Am I wrong? And as you can see it is not something which everyone agreed on: at least Geir's position is different. Or I got him wrong? -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
