[classlib]bug-to-bug compatibility: HashMap
Pls. try the test case on HashMap below.
On RI, it print out:
null
null
On Harmony, it print out
null
value1
it is definitely bad practice to reuse a object as hash key by modify
its hashcode, but I DID see some similar cases before, after all, you
cannot force but only can *suggest* developers what to do.
So, what should we do? Try to replicate RI's behavior?
public class HashMapTest {
public static void main(String[] args) {
ReusableKey k = new ReusableKey();
HashMap map = new HashMap();
k.setKey(1);
map.put(k, value1);
k.setKey(18);
//both RI and Harmony get null here
System.out.println(map.get(k));
k.setKey(17);
//RI get null
//Harmony get value1
//the number of 17 is *magic* because the default length of HashMap is 16.
System.out.println(map.get(k));
}
}
class ReusableKey{
private int key = 0;
public void setKey(int key){
this.key = key;
}
public int hashCode(){
return key;
}
public boolean equals(Object o){
if(o == this){
return true;
}
if(!(o instanceof ReusableKey)){
return false;
}
return key == ((ReusableKey)o).key;
}
}
--
Paulex Yang
China Software Development Lab
IBM
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Stefano, I think we should take Geir's advice and pipe down a bit. Those whose task it is to resolve this issue are by now pretty aware of the issues involved, and our explanations to eachother serve only to increase entropy. Meanwhile we may meditate on Jorge Luís Borges' story _Pierre Menard, Author of Don Quixote_: http://charleswjohnson.name/essays/can-don-quixote-tilt-at-william-james :-) Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: Excluded tests in x-net module or back to bootclasspath issue
Hi Tim, On 3/14/06, Tim Ellison [EMAIL PROTECTED] wrote: I agree that they need to be reinstated Stepan, I'd just like to separate out the suite of tests that are pure API tests (and therefore expected to run on all compliant implementations, modulo their known bugs/departures) and the internal implementation tests that we would only expect to pass on Harmony code. I had hoped that we could separate them using JUnit test suites, but as Geir pointed out the Ant support for JUnit suites produces very limited reports. I'd always run suites directly from Eclipse and could see all the required info. So it seems that the options are to (a) figure out why Ant is hiding the data, and fix that; or (b) live with it and invent a naming scheme for Harmony implementation tests that keep them separate from the API tests. I'd suggest the following tests separation: MODULE_ROOT/src/test/java (java|javax|org)/**/*Test.java (excluding org/apache/harmony/tests) org/apache/harmony/tests/**/*Test.java First folder contains tests for 'package access' functionality and tested classes must be on bootclasspath. Second folder keeps tests for public API ( i.e. 'compliant' tests). To avoid test code duplication the preferred folder for placing new tests is the second one - if a test doesn't depend on package access functionality them it goes to 'compliant' tests. So it is up to a developer to decide where to place a test. Also it may be makes sense to compile tests to different 'bin' folders. So we'll have the next 'testing modes': 1) Compliant mode: 'compliant' tests are run on some java certified implementation. 2) Cross-compliant mode: all tests run against the following JRE configuration - a module's jar + compliant java implementation (i.e. a module's jar and 'package access' tests are on the bootclasspath) 3) Self-testing mode: all tests run against Harmony implementation As (I think it was) Mikhail pointed out a while ago, using class naming schemes is far from ideal, as there may be a significant repetition of test cases and the suites they fit into. I believe that the separation suggested above may solve this issue. If we want to support testing with 'exotic' configurations then we will need some 'suites' that assume basic set-up, and others that can assume a test http server, ldap server, database, and so on. I'd prefer to avoid external dependencies for unit testing as much as possible. Otherwise specific (some special set-up is required) tests should be placed to a separate test suite. Thanks, Stepan. So my preference is to figure out why Ant produces its limited report for JUnit suites. Matt: can you shed any light on this? Regards, Tim Stepan Mishura wrote: Hi Tim, Currently you excluded 12 tests in 'x-net' module. The ant script file contains the following comments for them: The following tests are excluded because they fail for reasons to be determined The reason is well known and it was discussed a lot. These tests depend on package access functionality and BC provider jar is still required to be on bootclasspath (I don't remember that we solved this issue). I know that you are allergic to putting all stuff on bootclasspath but I'd prefer keep them running to track regressions rather then adding them to exclude list and forgetting about them for a long time. Thanks, Stepan Mishura Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Thanks, Stepan Mishura Intel Middleware Products Division
Re: Location of test data files
Hi George,
I'd like to fix outcome of this discussion. I think a JIRA issue should
filed to track tests reorg. As far as it'll be next massive reorg. and can
not be applied right now (there are other massive updates pending in JIRA).
And JIRA won't let us to forget about our decision.
Thanks,
Stepan
On 3/14/06, George Harley wrote:
Stepan Mishura wrote:
On 3/13/06, George Harley wrote:
Richard Liang wrote:
George Harley wrote:
Hi Mikhail (again),
Just a couple of brief observations about the SerializationTest.java
code as it stands in SVN today :
1) The reference/golden .dat files for Serializable classes in a
given module could be added under the module's src/test/resources
directory (in sub-folders corresponding to their package names). In
an Ant build these would be copied under the test bin using a tweaked
version of the copy-test-resources target (see the proposed changes
to make/build-java.xml contained in the HARMONY-57). At runtime this
would make the .dat files available from the classpath.
Hello George,
It's good to put all test data files for one module into one folder,
such as src/test/resources. However, there may be other options,
personally I'd like to put the test data file into the same directory
of the test case which uses the data file. This may make the
maintenance work easy. :-)
Anyway, I think we shall follow the same style.
Hi Richard,
Just to avoid any ambiguity here, what I proposed was to place the
reference serialization files *under* a given module's
src/test/resources folder in sub-folders that matched the package name
of the test class - and not just have them all in one folder.
For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
located in the folder
MODULE_ROOT/src/test/resources/serialization/tests/api/java/util
Another alternative would be to use a tree structure that mirrored the
package name of the Serializable type under test.
e.g.
MODULE_ROOT/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
To make it more clear because we talked only about data files for
testing
serialization but I'm aware of all resource files. So we have the
following
proposal:
MODULE_ROOT/src/test/resources
img/ == image files
net/ == net resource files
other/ == disembodied files, for example, policy files
serialization/ == data files for serialization
And during the build all resource files will be copied to:
build/resources
directory. Right?
Thanks,
Stepan
Hi Stepan,
Yes, that sounds great - with the very minor suggestion that at build
time these test resource files go to their corresponding sub-directories
under the test bin (e.g. bin/test) which is separate from the bin folder
(e.g. bin/main) that the stuff getting tested is compiled to.
Best regards,
George
I think that separating out all test artefacts from actual source code
is cleaner and IMHO makes the maintenance easier :-)
Using either Ant or IDE of choice it is pretty straightforward to get
these resources placed on the classpath when the tests are run.
Best regards,
George
2) The need for the TEST_SRC_DIR system property goes away if
method getDataFile() were updated to use java.net.URI.
e.g,
protected File getDataFile(int index) {
String name = / + this.getClass().getName().replace('.', '/') +
.
+ index + .dat;
return new
File(URI.create(this.getClass().getResource(name).toString()));
It seems to me that the src/test/resources directory would be an
ideal place to keep a module's reference .dat files.
Best regards,
George
George Harley wrote:
Mikhail Loenko wrote:
2006/3/9, George Harley [EMAIL PROTECTED]:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is
currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs
inside. Actually
almost all serializable security-related classes are tested with
this framework.
Does it make sense to move the framework to a common place?
Hi Mikhail !
I've spent a little bit of time running this (with a couple of my
own
little concrete subclasses of SerializationTest) and I really like
it.
It was pretty straightforward to create a JUnit error for the case
of
java.util.TimeZone after my overridden version of getData() used
TimeZone.getDefault() to generate a couple of TimeZone instances
from
the RI.
I can definitely see a case for broadening this approach outside
just
the security classes. Really impressive stuff !
Best regards,
George
Thanks,
Mikhail
--
Thanks,
abstract templates (was: Re: How to deal with this kind of serialization compatibility issue?)
Hello We can discuss the problem in general and then apply the decision to serialization framework. So, can we have standard test templates i.e. abstract classes with prepared test scenarios implemented as test methods such that specific tests would extend a template (and thus inherit all test methods) and override some possibly trivial methods to adopt for specific class. If we do this, we can hide similar scenarios in a framework super class, and actual tests will be simple and lightweight. But, we will not be able to subclass two different templates, we might have multiple tests extending different abstract classes for a single class. Thoughts? Thanks, Mikhail
Re: [classlib]bug-to-bug compatibility: HashMap
Hi Paulex,
IMHO from compatibility point of view any behavior is legal.
HashMap is mostly designed for keys that do not change over time, at least
spec silent about changing the keys. So, I think implementation specsific is
allowed here.
But I think that aiming stability we'd better compare current hash
with the original one - in this case get() result will depend on the hash
rather that on the inernal state of HashMap (such as HashMap length)
Thanks,
Mikhail
2006/3/15, Paulex Yang [EMAIL PROTECTED]:
Pls. try the test case on HashMap below.
On RI, it print out:
null
null
On Harmony, it print out
null
value1
it is definitely bad practice to reuse a object as hash key by modify
its hashcode, but I DID see some similar cases before, after all, you
cannot force but only can *suggest* developers what to do.
So, what should we do? Try to replicate RI's behavior?
public class HashMapTest {
public static void main(String[] args) {
ReusableKey k = new ReusableKey();
HashMap map = new HashMap();
k.setKey(1);
map.put(k, value1);
k.setKey(18);
//both RI and Harmony get null here
System.out.println(map.get(k));
k.setKey(17);
//RI get null
//Harmony get value1
//the number of 17 is *magic* because the default length of HashMap is 16.
System.out.println(map.get(k));
}
}
class ReusableKey{
private int key = 0;
public void setKey(int key){
this.key = key;
}
public int hashCode(){
return key;
}
public boolean equals(Object o){
if(o == this){
return true;
}
if(!(o instanceof ReusableKey)){
return false;
}
return key == ((ReusableKey)o).key;
}
}
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Hi, Mikhail,
Mikhail Loenko wrote:
Hi Paulex,
2006/3/14, Paulex Yang [EMAIL PROTECTED]:
Mikhail
I spent a little time on the framework, and I must say that this
framework is very easy to use. Impressive!
But I still have some thoughts on it:
1. Sometime assertEquals() is not enough for the deserialized objects,
i.e., if the predefined constants is serialized first by JRE instance A
and deserialized later on JRE instance B, it should has same object
identity with the existing constants in B, for example, the Locale.CHINA
should be unique in any JRE instance. So it will be perfect if some
helper method like assertSame() is provided.
It is also worth mentioning that some other time assertEquals() is too
strict, because some serializable class may not override j.l.Object's
equals(), so that the assertEquals() is equivalent to assertSame(), and
it may not necessary.
There is assertDeserialized() method in the framework (SerializationTest.java)
do you mean something like that?
Yes, something like that, but invoke assertSame() instead of
assertEquals(), or switch case by some configuration.
2. I have some concerns on the abstract-class mode of SerializationTest,
i.e., if some test want to leverage it, it must subclass this abstract
class at first. What to do if it needs to inherited other abstract test
cases, say, PerformanceTest? So personally I prefer the less
intrusive way like utility class. Another option is make the test case
implements an interface with getData(), say ISerializationTest, and pass
an instance of this interface to the utility class(similar with command
pattern).
SerializationTest.java has bodies of two test methods:
testSelf()
testGolden()
These methods are inherited and called by JUnit, so test developer do not have
to care about them.
Sure, that's the advantages of abstract class mode, but the utility
class is more *flexible*, i.e. less intrusive to the concrete test
classes.
Maybe there is another way to achieve both convenience and flexibility,
by separate test case for serialization to a single file, say ,
for:
public class AClass implements Serializable{...}
we have:
AClassTest, for common test cases,
and
AClassSerializationTest extends SerializationTest, for serialization test.
btw, I noticed there is also a serialization test utility class in the
Harmony-57 contribution. The class is located in
Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
It is a helper class which only providing some handy utility methods.
But seems it lacks of adaptability to generate GoldenFile by reading
configuration and not well documented.
What I suggest is to merge the two classes in some way, so that the
whole class library test suites can leverage the benefits of unified
serialization test framework/utility/anything.
I need to study H-57 SerializationTester, likely it makes sense taking
best ideas from both
Thanks,
Mikhail.
thoughts?
Mikhail Loenko wrote:
2006/3/9, George Harley [EMAIL PROTECTED]:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs inside. Actually
almost all serializable security-related classes are tested with this framework.
Does it make sense to move the framework to a common place?
Thanks,
Mikhail
--
Paulex Yang
China Software Development Lab
IBM
--
Paulex Yang
China Software Development Lab
IBM
Re: [tools] Eclipse JRE support
Tim Ellison wrote: That URL is a bit of a mouthful though, perhaps we need a redirect from http://incubator.apache.org/harmony/updates ? Personally I'd rather have a XML file to import in the Update dialogue since it gives the correct values for both fields. -- Thorbjørn
Re: How to deal with this kind of serialization compatibility issue?
Hi Paulex,
2006/3/15, Paulex Yang [EMAIL PROTECTED]:
Hi, Mikhail,
Mikhail Loenko wrote:
Hi Paulex,
2006/3/14, Paulex Yang [EMAIL PROTECTED]:
Mikhail
I spent a little time on the framework, and I must say that this
framework is very easy to use. Impressive!
But I still have some thoughts on it:
1. Sometime assertEquals() is not enough for the deserialized objects,
i.e., if the predefined constants is serialized first by JRE instance A
and deserialized later on JRE instance B, it should has same object
identity with the existing constants in B, for example, the Locale.CHINA
should be unique in any JRE instance. So it will be perfect if some
helper method like assertSame() is provided.
It is also worth mentioning that some other time assertEquals() is too
strict, because some serializable class may not override j.l.Object's
equals(), so that the assertEquals() is equivalent to assertSame(), and
it may not necessary.
There is assertDeserialized() method in the framework
(SerializationTest.java)
do you mean something like that?
Yes, something like that, but invoke assertSame() instead of
assertEquals(), or switch case by some configuration.
Actually framework calls assertDeserialized() who in its turn by default
calls assertEquals().
For each specific test an author may override assertDeserialized() by
something like you call assertSame(). Please have a look at an example:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
2. I have some concerns on the abstract-class mode of SerializationTest,
i.e., if some test want to leverage it, it must subclass this abstract
class at first. What to do if it needs to inherited other abstract test
cases, say, PerformanceTest? So personally I prefer the less
intrusive way like utility class. Another option is make the test case
implements an interface with getData(), say ISerializationTest, and pass
an instance of this interface to the utility class(similar with command
pattern).
SerializationTest.java has bodies of two test methods:
testSelf()
testGolden()
These methods are inherited and called by JUnit, so test developer do not
have
to care about them.
Sure, that's the advantages of abstract class mode, but the utility
class is more *flexible*, i.e. less intrusive to the concrete test
classes.
Maybe there is another way to achieve both convenience and flexibility,
by separate test case for serialization to a single file, say ,
for:
public class AClass implements Serializable{...}
we have:
AClassTest, for common test cases,
and
AClassSerializationTest extends SerializationTest, for serialization test.
That is what we have now in security module:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
and
modules/security/test/common/unit/java/security/CodeSignerTest.java
Thanks,
Mikhail
btw, I noticed there is also a serialization test utility class in the
Harmony-57 contribution. The class is located in
Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
It is a helper class which only providing some handy utility methods.
But seems it lacks of adaptability to generate GoldenFile by reading
configuration and not well documented.
What I suggest is to merge the two classes in some way, so that the
whole class library test suites can leverage the benefits of unified
serialization test framework/utility/anything.
I need to study H-57 SerializationTester, likely it makes sense taking
best ideas from both
Thanks,
Mikhail.
thoughts?
Mikhail Loenko wrote:
2006/3/9, George Harley [EMAIL PROTECTED]:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs inside.
Actually
almost all serializable security-related classes are tested with this
framework.
Does it make sense to move the framework to a common place?
Thanks,
Mikhail
--
Paulex Yang
China Software Development Lab
IBM
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Hi, Mikhail, Mikhail Loenko wrote: Hi George! I need to study H-57 SerializationTester, likely it makes sense taking best ideas from both I was trying to find out how the framework works and how a test based on that framework looks like. I've taken the first class refering to SerializationTester, it was CharacterCodingExceptionTest it has two serialization related test methods: testSerialization() testSerializationCompatibility() They both call SerializationTester methods but I did not find that they check that the objects are the same. Did I miss anything? The CharacterCodingException don't necessary to be assertSame() for serialization test, because it has no predefined constants:). I think the classes commonly needs to override readResolve() method to implement predefined constants serialization properly, so that it is easy to find all the candidates from the JavaDoc page of serilization form. But, of course, readResolve() is not a suffient condition:(. Thanks, Mikhail -- Paulex Yang China Software Development Lab IBM
Re: How to deal with this kind of serialization compatibility issue?
Mikhail
Mikhail Loenko wrote:
Hi Paulex,
2006/3/15, Paulex Yang [EMAIL PROTECTED]:
Hi, Mikhail,
Mikhail Loenko wrote:
Hi Paulex,
2006/3/14, Paulex Yang [EMAIL PROTECTED]:
Mikhail
I spent a little time on the framework, and I must say that this
framework is very easy to use. Impressive!
But I still have some thoughts on it:
1. Sometime assertEquals() is not enough for the deserialized objects,
i.e., if the predefined constants is serialized first by JRE instance A
and deserialized later on JRE instance B, it should has same object
identity with the existing constants in B, for example, the Locale.CHINA
should be unique in any JRE instance. So it will be perfect if some
helper method like assertSame() is provided.
It is also worth mentioning that some other time assertEquals() is too
strict, because some serializable class may not override j.l.Object's
equals(), so that the assertEquals() is equivalent to assertSame(), and
it may not necessary.
There is assertDeserialized() method in the framework (SerializationTest.java)
do you mean something like that?
Yes, something like that, but invoke assertSame() instead of
assertEquals(), or switch case by some configuration.
Actually framework calls assertDeserialized() who in its turn by default
calls assertEquals().
For each specific test an author may override assertDeserialized() by
something like you call assertSame(). Please have a look at an example:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
OK, I'm fine with this solution.
2. I have some concerns on the abstract-class mode of SerializationTest,
i.e., if some test want to leverage it, it must subclass this abstract
class at first. What to do if it needs to inherited other abstract test
cases, say, PerformanceTest? So personally I prefer the less
intrusive way like utility class. Another option is make the test case
implements an interface with getData(), say ISerializationTest, and pass
an instance of this interface to the utility class(similar with command
pattern).
SerializationTest.java has bodies of two test methods:
testSelf()
testGolden()
These methods are inherited and called by JUnit, so test developer do not have
to care about them.
Sure, that's the advantages of abstract class mode, but the utility
class is more *flexible*, i.e. less intrusive to the concrete test
classes.
Maybe there is another way to achieve both convenience and flexibility,
by separate test case for serialization to a single file, say ,
for:
public class AClass implements Serializable{...}
we have:
AClassTest, for common test cases,
and
AClassSerializationTest extends SerializationTest, for serialization test.
That is what we have now in security module:
modules/security/test/common/unit/java/security/serialization/CodeSignerTest.java
and
modules/security/test/common/unit/java/security/CodeSignerTest.java
Thanks,
Mikhail
That's great.
btw, I noticed there is also a serialization test utility class in the
Harmony-57 contribution. The class is located in
Harmon_Tests/src.helper/tests/util with name SerializationTester.java.
It is a helper class which only providing some handy utility methods.
But seems it lacks of adaptability to generate GoldenFile by reading
configuration and not well documented.
What I suggest is to merge the two classes in some way, so that the
whole class library test suites can leverage the benefits of unified
serialization test framework/utility/anything.
I need to study H-57 SerializationTester, likely it makes sense taking
best ideas from both
Thanks,
Mikhail.
thoughts?
Mikhail Loenko wrote:
2006/3/9, George Harley [EMAIL PROTECTED]:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs inside. Actually
almost all serializable security-related classes are tested with this framework.
Does it make sense to move the framework to a common place?
Thanks,
Mikhail
--
Paulex Yang
China Software Development Lab
IBM
--
Paulex Yang
China Software Development Lab
IBM
--
Paulex Yang
China Software Development Lab
IBM
Re: How to deal with this kind of serialization compatibility issue?
Using serialization framework from security module,
the test would look like as follows:
public class CharacterCodingExceptionTest extends SerializationTest {
protected Object[] getData() {
return new Object[] { new CharacterCodingExceptionTest ()};
}
protected void assertDeserialized(Object oref, Object otest) {
CharacterCodingExceptionTest ref = (CharacterCodingExceptionTest ) oref;
CharacterCodingExceptionTest test =
(CharacterCodingExceptionTest ) otest;
assertNull(test.getMessage());
}
}
Thanks,
Mikhail
2006/3/15, Paulex Yang [EMAIL PROTECTED]:
Hi, Mikhail,
Mikhail Loenko wrote:
Hi George!
I need to study H-57 SerializationTester, likely it makes sense taking
best ideas from both
I was trying to find out how the framework works and how a test
based on that framework looks like.
I've taken the first class refering to SerializationTester, it was
CharacterCodingExceptionTest
it has two serialization related test methods:
testSerialization()
testSerializationCompatibility()
They both call SerializationTester methods but I did not find that they
check
that the objects are the same. Did I miss anything?
The CharacterCodingException don't necessary to be assertSame() for
serialization test, because it has no predefined constants:).
I think the classes commonly needs to override readResolve() method to
implement predefined constants serialization properly, so that it is
easy to find all the candidates from the JavaDoc page of serilization
form. But, of course, readResolve() is not a suffient condition:(.
Thanks,
Mikhail
--
Paulex Yang
China Software Development Lab
IBM
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
On Mon, Mar 13, 2006 at 06:50:44PM -0500, Geir Magnusson Jr wrote: Dalibor Topic wrote: On a Harmony-unrelated side note, if you are interested in seeing your port in the Kaffe.org CVS tree, and your contract allows for it, feel free to send me the patch. :) On a harmony-related note, are you interested in looking at Weldon's glue layer to see if Kaffe can also run Hello World using Harmony Classlib? Sure. I must have missed it going in, I'll give it a go on the weekend and report back. cheers, dalibor topic geir
Re: Location of test data files
Hi Stepan,
Good idea. I will raise it today. It will only cover the proposed layout
of these test resources in a given module and not discuss how the
serialization tests are carried out since that discussion is still ongoing.
Best regards,
George
Stepan Mishura wrote:
Hi George,
I'd like to fix outcome of this discussion. I think a JIRA issue should
filed to track tests reorg. As far as it'll be next massive reorg. and can
not be applied right now (there are other massive updates pending in JIRA).
And JIRA won't let us to forget about our decision.
Thanks,
Stepan
On 3/14/06, George Harley wrote:
Stepan Mishura wrote:
On 3/13/06, George Harley wrote:
Richard Liang wrote:
George Harley wrote:
Hi Mikhail (again),
Just a couple of brief observations about the SerializationTest.java
code as it stands in SVN today :
1) The reference/golden .dat files for Serializable classes in a
given module could be added under the module's src/test/resources
directory (in sub-folders corresponding to their package names). In
an Ant build these would be copied under the test bin using a tweaked
version of the copy-test-resources target (see the proposed changes
to make/build-java.xml contained in the HARMONY-57). At runtime this
would make the .dat files available from the classpath.
Hello George,
It's good to put all test data files for one module into one folder,
such as src/test/resources. However, there may be other options,
personally I'd like to put the test data file into the same directory
of the test case which uses the data file. This may make the
maintenance work easy. :-)
Anyway, I think we shall follow the same style.
Hi Richard,
Just to avoid any ambiguity here, what I proposed was to place the
reference serialization files *under* a given module's
src/test/resources folder in sub-folders that matched the package name
of the test class - and not just have them all in one folder.
For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
located in the folder
MODULE_ROOT/src/test/resources/serialization/tests/api/java/util
Another alternative would be to use a tree structure that mirrored the
package name of the Serializable type under test.
e.g.
MODULE_ROOT/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
To make it more clear because we talked only about data files for
testing
serialization but I'm aware of all resource files. So we have the
following
proposal:
MODULE_ROOT/src/test/resources
img/ == image files
net/ == net resource files
other/ == disembodied files, for example, policy files
serialization/ == data files for serialization
And during the build all resource files will be copied to:
build/resources
directory. Right?
Thanks,
Stepan
Hi Stepan,
Yes, that sounds great - with the very minor suggestion that at build
time these test resource files go to their corresponding sub-directories
under the test bin (e.g. bin/test) which is separate from the bin folder
(e.g. bin/main) that the stuff getting tested is compiled to.
Best regards,
George
I think that separating out all test artefacts from actual source code
is cleaner and IMHO makes the maintenance easier :-)
Using either Ant or IDE of choice it is pretty straightforward to get
these resources placed on the classpath when the tests are run.
Best regards,
George
2) The need for the TEST_SRC_DIR system property goes away if
method getDataFile() were updated to use java.net.URI.
e.g,
protected File getDataFile(int index) {
String name = / + this.getClass().getName().replace('.', '/') +
.
+ index + .dat;
return new
File(URI.create(this.getClass().getResource(name).toString()));
It seems to me that the src/test/resources directory would be an
ideal place to keep a module's reference .dat files.
Best regards,
George
George Harley wrote:
Mikhail Loenko wrote:
2006/3/9, George Harley [EMAIL PROTECTED]:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is
currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs
inside. Actually
almost all serializable security-related classes are tested with
this framework.
Does it make sense to move the framework to a common place?
Hi Mikhail !
I've spent a little bit of time running this (with a couple of my
own
little concrete subclasses of SerializationTest) and I really like
it.
It was pretty straightforward
Re: [jira] Resolved: (HARMONY-161) Improper override method in java/util/zip/GZIPOutputStream.close()
Paulex, As we recently discussed, there is nothing in the spec that prevents us from (re-)implementing the method in the subclass, even though it is not specified to have any additional behavior to the inherited version. So while the point of the issue may be wrong, I've applied the patch to remove the close() method as I see it is not required. Regards, Tim Tim Ellison (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-161?page=all ] Tim Ellison resolved HARMONY-161: - Resolution: Fixed Paulex, Applied patch to ARCHIVE module java.util.zip.GZIPOutputStream at repo revision 386064. Please check that it was applied as you expected. Improper override method in java/util/zip/GZIPOutputStream.close() -- Key: HARMONY-161 URL: http://issues.apache.org/jira/browse/HARMONY-161 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: java.util.zip.GZIPOutputStream.patch java/util/zip/DeflaterOutputStream.close() is overriden by java/util/zip/GZIPOutputStream in Harmony while it isn't in spec. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Location of test data files
Why not describe it in a doc, and submit it for the website?
Regards,
Tim
George Harley wrote:
Hi Stepan,
Good idea. I will raise it today. It will only cover the proposed layout
of these test resources in a given module and not discuss how the
serialization tests are carried out since that discussion is still ongoing.
Best regards,
George
Stepan Mishura wrote:
Hi George,
I'd like to fix outcome of this discussion. I think a JIRA issue should
filed to track tests reorg. As far as it'll be next massive reorg. and
can
not be applied right now (there are other massive updates pending in
JIRA).
And JIRA won't let us to forget about our decision.
Thanks,
Stepan
On 3/14/06, George Harley wrote:
Stepan Mishura wrote:
On 3/13/06, George Harley wrote:
Richard Liang wrote:
George Harley wrote:
Hi Mikhail (again),
Just a couple of brief observations about the SerializationTest.java
code as it stands in SVN today :
1) The reference/golden .dat files for Serializable classes in a
given module could be added under the module's src/test/resources
directory (in sub-folders corresponding to their package names). In
an Ant build these would be copied under the test bin using a
tweaked
version of the copy-test-resources target (see the proposed
changes
to make/build-java.xml contained in the HARMONY-57). At runtime this
would make the .dat files available from the classpath.
Hello George,
It's good to put all test data files for one module into one folder,
such as src/test/resources. However, there may be other options,
personally I'd like to put the test data file into the same directory
of the test case which uses the data file. This may make the
maintenance work easy. :-)
Anyway, I think we shall follow the same style.
Hi Richard,
Just to avoid any ambiguity here, what I proposed was to place the
reference serialization files *under* a given module's
src/test/resources folder in sub-folders that matched the package name
of the test class - and not just have them all in one folder.
For instance, the LUNI module could have a SimpleTimeZoneTest.dat file
located in the folder
MODULE_ROOT/src/test/resources/serialization/tests/api/java/util
Another alternative would be to use a tree structure that mirrored the
package name of the Serializable type under test.
e.g.
MODULE_ROOT/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
To make it more clear because we talked only about data files for
testing
serialization but I'm aware of all resource files. So we have the
following
proposal:
MODULE_ROOT/src/test/resources
img/ == image files
net/ == net resource files
other/ == disembodied files, for example, policy files
serialization/ == data files for serialization
And during the build all resource files will be copied to:
build/resources
directory. Right?
Thanks,
Stepan
Hi Stepan,
Yes, that sounds great - with the very minor suggestion that at build
time these test resource files go to their corresponding sub-directories
under the test bin (e.g. bin/test) which is separate from the bin folder
(e.g. bin/main) that the stuff getting tested is compiled to.
Best regards,
George
I think that separating out all test artefacts from actual source code
is cleaner and IMHO makes the maintenance easier :-)
Using either Ant or IDE of choice it is pretty straightforward to
get
these resources placed on the classpath when the tests are run.
Best regards,
George
2) The need for the TEST_SRC_DIR system property goes away if
method getDataFile() were updated to use java.net.URI.
e.g,
protected File getDataFile(int index) {
String name = / + this.getClass().getName().replace('.', '/') +
.
+ index + .dat;
return new
File(URI.create(this.getClass().getResource(name).toString()));
It seems to me that the src/test/resources directory would be an
ideal place to keep a module's reference .dat files.
Best regards,
George
George Harley wrote:
Mikhail Loenko wrote:
2006/3/9, George Harley [EMAIL PROTECTED]:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is
currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs
inside. Actually
almost all serializable security-related classes are tested with
this framework.
Does it make sense to move the framework to a common place?
Hi Mikhail !
I've spent a little bit
Re: [tools] Eclipse JRE support
Just for you Thorbjørn Regards, Tim --- ?xml version=1.0 encoding=UTF-8? bookmarks site name=Apache Harmony update site url=http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site; web=false selected=true local=false/ /bookmarks -- Thorbjørn Ravn Andersen wrote: Tim Ellison wrote: That URL is a bit of a mouthful though, perhaps we need a redirect from http://incubator.apache.org/harmony/updates ? Personally I'd rather have a XML file to import in the Update dialogue since it gives the correct values for both fields. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [jira] Resolved: (HARMONY-88) Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security
FYI: I noticed a few minor things that we should probably fix in this contribution, but they don't break the build and it makes sense to commit the contribution as we received it then fix it up in 'business as usual' development. Regards, Tim Tim Ellison (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-88?page=all ] Tim Ellison resolved HARMONY-88: Resolution: Fixed Thanks George Mark, I've committed the contribution at repo revision 386087. Please check that it was applied as you expected. Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security -- Key: HARMONY-88 URL: http://issues.apache.org/jira/browse/HARMONY-88 Project: Harmony Type: New Feature Components: Contributions Environment: Win32 and Linux Reporter: George Harley Assignee: Tim Ellison Attachments: 01.harmony.88.integration.sh, 01.harmony.88.integration.sh, 02.harmony.88.integration.diff, 02.harmony.88.integration.diff, Harmony-Contribution.zip Zip file containing implementation and unit test code for the following Harmony components : * jndi * logging * prefs * sql In addition there is unit test code only for the following Harmony components : * beans * crypto * math * regex * security The contents of this zip have been laid out with the current classlib directory structure of the Apache Harmony SVN repository in mind. A version of enhanced/classlib/trunk/make/build-java.xml is included containing new Ant targets to compile the new implementation plus tests code, and then run the tests. Native code, plus makefiles are included to build a shared library that is required to support the prefs implementation on the win.IA32 platform. Not all of the unit test classes are capable of being compiled when the Ant target compile-tests in EXTRACT_DIR/Harmony/make/build-java.xml is run. This is because the current contents of the Harmony trunk do not satisfy all of the dependencies of some classes. This issue affects the unit test code for the following set of components ... * beans (needs beans implementation in trunk) * crypto (needs crypto implementation in trunk) * logging (needs beans implementation in trunk) * jndi (needs applet implementation in trunk) * sql (needs rmi implementation in trunk) As a temporary measure, the lines of Ant script in EXTRACT_DIR/Harmony/make/build-java.xml that compile the above test code have been commented out with explanations. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib]bug-to-bug compatibility: HashMap
Will Sun's implementation ever find ReusableKey if the value has been
changed?
It would not surprise me if this simple case Sun doesn't find the entry,
because they do something like hashing the hash that ReusableKey
returns, or only allocating a prime number of buckets, e.g. you ask for
a size of 16 and get 17, because 16 is not prime.
This doesn't actually seems like crazy behaviour, since it is probably
rather common to have programmers that are not very good at creating
well distributed hashing algorithms, and so having something built in to
help is probably pretty good design.
--Will
Paulex Yang wrote:
Pls. try the test case on HashMap below.
On RI, it print out:
null
null
On Harmony, it print out
null
value1
it is definitely bad practice to reuse a object as hash key by modify
its hashcode, but I DID see some similar cases before, after all, you
cannot force but only can *suggest* developers what to do.
So, what should we do? Try to replicate RI's behavior?
public class HashMapTest {
public static void main(String[] args) {
ReusableKey k = new ReusableKey();
HashMap map = new HashMap();
k.setKey(1);
map.put(k, value1);
k.setKey(18);
//both RI and Harmony get null here
System.out.println(map.get(k));
k.setKey(17);
//RI get null
//Harmony get value1
//the number of 17 is *magic* because the default length of HashMap
is 16.
System.out.println(map.get(k));
}
}
class ReusableKey{
private int key = 0;
public void setKey(int key){
this.key = key;
}
public int hashCode(){
return key;
}
public boolean equals(Object o){
if(o == this){
return true;
}
if(!(o instanceof ReusableKey)){
return false;
}
return key == ((ReusableKey)o).key;
}
}
Re: svn commit: r386058 [1/49] ...
49 commit messages for a single commit! The continuous wash-in of Really Big(tm) chunks of code scares me a little (even if its real cool) -- usually I make it policy to read every single line of code contributed to a project for which I'm on the PMC but there's no chance in hell I'm going to spend an entire weekend reading unit tests. Just keeping up amounts to something close to a fulltime job. The usual oversight model that at least some parts of the ASF are used to seems near-impossible to apply here. Will all people able to read every line of code as it comes in please raise their hands? I'm thinking about how to make this stuff scale. Any ideas? The natural tendency is to want to partition, but that way we lose the many eyes advantages Anyway, just a random thought... - Leo
Re: svn commit: r386058 [1/49] ...
Isn't this the initial commit for somwthing we just voted in? (me in car so can't see right now) -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Wed Mar 15 11:34:35 2006 To: harmony-dev@incubator.apache.org Subject:Re: svn commit: r386058 [1/49] ... 49 commit messages for a single commit! The continuous wash-in of Really Big(tm) chunks of code scares me a little (even if its real cool) -- usually I make it policy to read every single line of code contributed to a project for which I'm on the PMC but there's no chance in hell I'm going to spend an entire weekend reading unit tests. Just keeping up amounts to something close to a fulltime job. The usual oversight model that at least some parts of the ASF are used to seems near-impossible to apply here. Will all people able to read every line of code as it comes in please raise their hands? I'm thinking about how to make this stuff scale. Any ideas? The natural tendency is to want to partition, but that way we lose the many eyes advantages Anyway, just a random thought... - Leo
Re: svn commit: r386058 [1/49] ...
Yes, the log message is only shown in the first commit message in the set. That particular commit is the HARMONY-57 bulk contribution that was voted on by the -dev list. The other big commit I did today is the HARMONY-88 bulk contribution that was also accepted by the -dev list. I'm not *that* productive! Regards, Tim Magnusson, Geir wrote: Isn't this the initial commit for somwthing we just voted in? (me in car so can't see right now) -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Wed Mar 15 11:34:35 2006 To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r386058 [1/49] ... 49 commit messages for a single commit! The continuous wash-in of Really Big(tm) chunks of code scares me a little (even if its real cool) -- usually I make it policy to read every single line of code contributed to a project for which I'm on the PMC but there's no chance in hell I'm going to spend an entire weekend reading unit tests. Just keeping up amounts to something close to a fulltime job. The usual oversight model that at least some parts of the ASF are used to seems near-impossible to apply here. Will all people able to read every line of code as it comes in please raise their hands? I'm thinking about how to make this stuff scale. Any ideas? The natural tendency is to want to partition, but that way we lose the many eyes advantages Anyway, just a random thought... - Leo -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: svn commit: r386058 [1/49] ...
I assume that you noted the jura entry in the commit log. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wed Mar 15 11:44:19 2006 To: harmony-dev@incubator.apache.org Subject:Re: svn commit: r386058 [1/49] ... Yes, the log message is only shown in the first commit message in the set. That particular commit is the HARMONY-57 bulk contribution that was voted on by the -dev list. The other big commit I did today is the HARMONY-88 bulk contribution that was also accepted by the -dev list. I'm not *that* productive! Regards, Tim Magnusson, Geir wrote: Isn't this the initial commit for somwthing we just voted in? (me in car so can't see right now) -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Wed Mar 15 11:34:35 2006 To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r386058 [1/49] ... 49 commit messages for a single commit! The continuous wash-in of Really Big(tm) chunks of code scares me a little (even if its real cool) -- usually I make it policy to read every single line of code contributed to a project for which I'm on the PMC but there's no chance in hell I'm going to spend an entire weekend reading unit tests. Just keeping up amounts to something close to a fulltime job. The usual oversight model that at least some parts of the ASF are used to seems near-impossible to apply here. Will all people able to read every line of code as it comes in please raise their hands? I'm thinking about how to make this stuff scale. Any ideas? The natural tendency is to want to partition, but that way we lose the many eyes advantages Anyway, just a random thought... - Leo -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: svn commit: r386058 [1/49] ...
I did my usual trick, which is to mention the JIRA tag and the issue summary; in this case it was: In svn commit: r386087 [1/45] -... snip Log: Commit contribution HARMONY-88 (Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security) snip and in svn commit: r386058 [1/49] -... snip Log: Apply HARMONY-57 (Contribution of unit test code for a number of components) snip I did them as a single commit, so I assume it is the SVN mail notifier that splits the single r386058 message into 49 pieces due to length. Regards, Tim Magnusson, Geir wrote: I assume that you noted the jura entry in the commit log. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wed Mar 15 11:44:19 2006 To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r386058 [1/49] ... Yes, the log message is only shown in the first commit message in the set. That particular commit is the HARMONY-57 bulk contribution that was voted on by the -dev list. The other big commit I did today is the HARMONY-88 bulk contribution that was also accepted by the -dev list. I'm not *that* productive! Regards, Tim Magnusson, Geir wrote: Isn't this the initial commit for somwthing we just voted in? (me in car so can't see right now) -Original Message- From:Leo Simons [mailto:[EMAIL PROTECTED] Sent:Wed Mar 15 11:34:35 2006 To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r386058 [1/49] ... 49 commit messages for a single commit! The continuous wash-in of Really Big(tm) chunks of code scares me a little (even if its real cool) -- usually I make it policy to read every single line of code contributed to a project for which I'm on the PMC but there's no chance in hell I'm going to spend an entire weekend reading unit tests. Just keeping up amounts to something close to a fulltime job. The usual oversight model that at least some parts of the ASF are used to seems near-impossible to apply here. Will all people able to read every line of code as it comes in please raise their hands? I'm thinking about how to make this stuff scale. Any ideas? The natural tendency is to want to partition, but that way we lose the many eyes advantages Anyway, just a random thought... - Leo -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: svn commit: r386058 [1/49] ...
That's what I fgured. Me still in car. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wed Mar 15 11:53:57 2006 To: harmony-dev@incubator.apache.org Subject:Re: svn commit: r386058 [1/49] ... I did my usual trick, which is to mention the JIRA tag and the issue summary; in this case it was: In svn commit: r386087 [1/45] -... snip Log: Commit contribution HARMONY-88 (Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security) snip and in svn commit: r386058 [1/49] -... snip Log: Apply HARMONY-57 (Contribution of unit test code for a number of components) snip I did them as a single commit, so I assume it is the SVN mail notifier that splits the single r386058 message into 49 pieces due to length. Regards, Tim Magnusson, Geir wrote: I assume that you noted the jura entry in the commit log. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wed Mar 15 11:44:19 2006 To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r386058 [1/49] ... Yes, the log message is only shown in the first commit message in the set. That particular commit is the HARMONY-57 bulk contribution that was voted on by the -dev list. The other big commit I did today is the HARMONY-88 bulk contribution that was also accepted by the -dev list. I'm not *that* productive! Regards, Tim Magnusson, Geir wrote: Isn't this the initial commit for somwthing we just voted in? (me in car so can't see right now) -Original Message- From:Leo Simons [mailto:[EMAIL PROTECTED] Sent:Wed Mar 15 11:34:35 2006 To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r386058 [1/49] ... 49 commit messages for a single commit! The continuous wash-in of Really Big(tm) chunks of code scares me a little (even if its real cool) -- usually I make it policy to read every single line of code contributed to a project for which I'm on the PMC but there's no chance in hell I'm going to spend an entire weekend reading unit tests. Just keeping up amounts to something close to a fulltime job. The usual oversight model that at least some parts of the ASF are used to seems near-impossible to apply here. Will all people able to read every line of code as it comes in please raise their hands? I'm thinking about how to make this stuff scale. Any ideas? The natural tendency is to want to partition, but that way we lose the many eyes advantages Anyway, just a random thought... - Leo -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Closing of HARMONY-88
Mark wrote: Of course, it shouldn't be closed yet since quite a few of the contributed test cases still need to be integrated. Well I figured I'd mark it closed it since the code is now in SVN, even if it is not fully integrated yet. I figured we could work on the final aspects of integration in day-to-day development, taking patches etc. But I don't particularly care, so if you really want it reopened I'll happily do it. Regards, Tim Mark Hindess (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-88?page=comments#action_12370565 ] Mark Hindess commented on HARMONY-88: - This looks good. Of course, it shouldn't be closed yet since quite a few of the contributed test cases still need to be integrated. I'm just about to take a look at the beans tests and uncommenting logging so that those can go in as soon as someone integrates the HARMONY-39 contribution. That will just leave the security/crypto tests which will probably have to wait until those modules are restructured. Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security -- Key: HARMONY-88 URL: http://issues.apache.org/jira/browse/HARMONY-88 Project: Harmony Type: New Feature Components: Contributions Environment: Win32 and Linux Reporter: George Harley Assignee: Tim Ellison Attachments: 01.harmony.88.integration.sh, 01.harmony.88.integration.sh, 02.harmony.88.integration.diff, 02.harmony.88.integration.diff, Harmony-Contribution.zip Zip file containing implementation and unit test code for the following Harmony components : * jndi * logging * prefs * sql In addition there is unit test code only for the following Harmony components : * beans * crypto * math * regex * security The contents of this zip have been laid out with the current classlib directory structure of the Apache Harmony SVN repository in mind. A version of enhanced/classlib/trunk/make/build-java.xml is included containing new Ant targets to compile the new implementation plus tests code, and then run the tests. Native code, plus makefiles are included to build a shared library that is required to support the prefs implementation on the win.IA32 platform. Not all of the unit test classes are capable of being compiled when the Ant target compile-tests in EXTRACT_DIR/Harmony/make/build-java.xml is run. This is because the current contents of the Harmony trunk do not satisfy all of the dependencies of some classes. This issue affects the unit test code for the following set of components ... * beans (needs beans implementation in trunk) * crypto (needs crypto implementation in trunk) * logging (needs beans implementation in trunk) * jndi (needs applet implementation in trunk) * sql (needs rmi implementation in trunk) As a temporary measure, the lines of Ant script in EXTRACT_DIR/Harmony/make/build-java.xml that compile the above test code have been commented out with explanations. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Results of big commits
As well as the new classes, we have over 2700 tests that's nearly ten times the number we were running a week ago. And there are a few more that need some work. So if anyone is looking for something to do, take a look at the excluded tests in the modules/*/make/common/build.xml files. I've been doing some application testing on the latest trunk plus the integration of HARMONY-39 in my workspace. It's pretty cool. Tomcat 5.5 (which uses the eclipse compiler rather than requiring a jdk) now starts up ok. (I do get an error when it shuts down but I'm sure we'll get to that.) I tried axis but it looks like we'll need stubs for a few more classes before that will work - e.g. java.awt.datatransfer.Transferable and java/rmi/RemoteException. It's great to see some really substantial applications running on the Harmony classes. Regards, Mark. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK.
Re: Closing of HARMONY-88
No problem, I've reopened it. Let's hope that HARMONY-39 gets committed soon then we can finish the remainder. Regards, Tim Mark Hindess wrote: Not all the code is in svn. So I'd say leave it open to remind us that there's still more work to do. -Mark. On 3/15/06, Tim Ellison [EMAIL PROTECTED] wrote: Mark wrote: Of course, it shouldn't be closed yet since quite a few of the contributed test cases still need to be integrated. Well I figured I'd mark it closed it since the code is now in SVN, even if it is not fully integrated yet. I figured we could work on the final aspects of integration in day-to-day development, taking patches etc. But I don't particularly care, so if you really want it reopened I'll happily do it. Regards, Tim Mark Hindess (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-88?page=comments#action_12370565 ] Mark Hindess commented on HARMONY-88: - This looks good. Of course, it shouldn't be closed yet since quite a few of the contributed test cases still need to be integrated. I'm just about to take a look at the beans tests and uncommenting logging so that those can go in as soon as someone integrates the HARMONY-39 contribution. That will just leave the security/crypto tests which will probably have to wait until those modules are restructured. Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security -- Key: HARMONY-88 URL: http://issues.apache.org/jira/browse/HARMONY-88 Project: Harmony Type: New Feature Components: Contributions Environment: Win32 and Linux Reporter: George Harley Assignee: Tim Ellison Attachments: 01.harmony.88.integration.sh, 01.harmony.88.integration.sh, 02.harmony.88.integration.diff, 02.harmony.88.integration.diff, Harmony-Contribution.zip Zip file containing implementation and unit test code for the following Harmony components : * jndi * logging * prefs * sql In addition there is unit test code only for the following Harmony components : * beans * crypto * math * regex * security The contents of this zip have been laid out with the current classlib directory structure of the Apache Harmony SVN repository in mind. A version of enhanced/classlib/trunk/make/build-java.xml is included containing new Ant targets to compile the new implementation plus tests code, and then run the tests. Native code, plus makefiles are included to build a shared library that is required to support the prefs implementation on the win.IA32 platform. Not all of the unit test classes are capable of being compiled when the Ant target compile-tests in EXTRACT_DIR/Harmony/make/build-java.xml is run. This is because the current contents of the Harmony trunk do not satisfy all of the dependencies of some classes. This issue affects the unit test code for the following set of components ... * beans (needs beans implementation in trunk) * crypto (needs crypto implementation in trunk) * logging (needs beans implementation in trunk) * jndi (needs applet implementation in trunk) * sql (needs rmi implementation in trunk) As a temporary measure, the lines of Ant script in EXTRACT_DIR/Harmony/make/build-java.xml that compile the above test code have been commented out with explanations. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: svn commit: r386171 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Mikhail,
I took a few shortcuts getting these integration done. I'm planning
to factor out the acquire depends jars step in to a separate ant file.
My current plan is to create a new make/depends.xml file that would
be responsible for fetching the files and have the make/build.xml use
that to check for the presence of the files and only run the get tasks
file if any files are missing. (Ditto for make/build-test.xml which
currently duplicates this download process.)
This way, if you have the required jars in the correct location then
it should be possible to avoid the HTTP If-Modified queries that are
causing your problems.
Once I've fixed these problems that I created then I intend to look at
HARMONY-196 to see if that contribution can be added to the
make/depends.xml step.
Regards,
Mark.
On 3/16/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Tim, Mark
revisions 386087, 386171 of that file break my build:
prepare-depends:
[get] Getting: http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar
[get] To: C:\harmony\depends\jars\xalan-j_2.6.0\xalan.jar
[get] Error getting
http://www.ibiblio.org/maven/xalan/jars/xalan-2.6.0.jar to C:\
depends\jars\xalan-j_2.6.0\xalan.jar
BUILD FAILED
C:\harmony\make\build.xml:36: The following error occurred while
executing this line:
C:\harmony\make\build-java.xml:352: java.net.NoRouteToHostException:
Operation timed out
The problem seems to be with proxy setting
Thanks,
Mikhail Loenko
Intel Middleware Products Division
2006/3/16, Mark Hindess [EMAIL PROTECTED]:
Thanks Tim. I spotted that I'd missed that one too.
-Mark.
On 3/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tellison
Date: Wed Mar 15 13:37:44 2006
New Revision: 386171
URL: http://svn.apache.org/viewcvs?rev=386171view=rev
Log:
Ensure the XML JARs go directly into the boot dir
Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Modified: incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml?rev=386171r1=386170r2=386171view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
(original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Wed Mar
15 13:37:44 2006
@@ -282,7 +282,7 @@
!-- Copy across the dependency jars --
copy todir=${target.output}/jre/lib/boot overwrite=yes
- verbose=yes
+ verbose=yes flatten=yes
fileset dir=${depends.jars}
patternset includes=*.jar /
patternset includes=xerces_2.6.2/*.jar /
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
Subclipse Diff: Are there any way to ignore whitespace when creating patch using Subclipse in Eclipse
Dears, If you select Spaces only as Eclipse tab policy and you format the Harmony source code in Eclipse, when you creating patch for the source code, Subclipse may regard the source code as total different with the source in SVN. Then other developers cannot know what you have changed to the source code. So are there any way to avoid this confusion? Thanks a lot. -- Richard Liang China Software Development Lab, IBM
