Re: [classlib] bug-to-bug compatibility: SecureRandom
Mikhail
I think current Harmony code is fine in this case. Because it is
reasonable to consider null as another exceptional case and to
differentiate it with the case of non-existing algorithm.
Mikhail Loenko wrote:
Hello,
one more issue for discussion/approval.
class: java.security.SecureRandom
method: public static SecureRandom getInstance(String algorithm)
According to spec, it throws:
NoSuchAlgorithmException - if the RNG algorithm is not available in
the caller's environment.
RI throws NullPointerException if algorithm==null (seems like they don't do
any check)
Harmony currently makes explicit check:
if (algorithm == null) {
throw new NullPointerException(Algorithm is null);
}
Thoughts?
Thanks,
Mikhail Loenko
Intel Middleware Products Division
--
Paulex Yang
China Software Development Lab
IBM
Re: Location of test data files
Hi George,
I like you idea with loading test's resource files. I don't see any
maintenance issues with putting all resource files into src/test/resources
folder, for example, if a test have several resource files then I'd like to
keep them in separate folder rather then in a test's folder. Also don't
think that there will be name collision problems: java files go to
test/java and resource files go to test/resources. Is anybody going to
put class files there?
George Harley wrote:
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()));
FYI, SerializationTest.java is not the only one case. There are few places
where TEST_SRC_DIR system property is used, for example, policy resource
files see:
modules/security/test/common/unit/javax/security/auth/PolicyTest.java
modules/security/test/common/unit/javax/security/auth/jaas_policy1.txt
modules/security/test/common/unit/javax/security/auth/jaas_policy2.txt
I think it won't be an issue to fix them if your suggestion will be
accepted.
BTW, as far as I remember we agreed to call new security module 'auth'
because of 'JAAS' trademark issues so I guess we should rename two policy
files say to auth_policyn.txt. I'm going to search all such cases and
provide a patch.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 3/11/06, 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.
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,
Stepan Mishura
Intel Middleware Products Division
Re: Location of test data files
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
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
Re: Location of test data files
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.
Yes, George. That's make sense :-)
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
I think that separating out all test artefacts from actual source code
is cleaner and IMHO makes the maintenance easier :-)
I think there is no big difference. But anyway we shall agree with one
of the three options.
1) Put test data files into a separated folder, and use the package name
of test case as its namespace.
e.g., MODULE_ROOT/src/test/resources/serialization/tests/api/java/util
2) Put test data files into a separated folder, and use the package
name of the class under test as its namespace.
e.g.
MODULE_ROOT/src/test/resources/serialization/java/util/SimpleTimeZoneTest.dat
3. Put test data files into the same location as the test case.
Shall we vote? :-)
Using either Ant or IDE of choice it is pretty straightforward to
get these resources placed on the classpath when the tests are run.
Yes. I think we all agree with this.
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
--
Richard Liang
China Software Development Lab, IBM
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Chris Gray wrote: The key change is and that implementation is not available under a recognized Open Source license - because except for copying, which we don't allow, any ideas found in open-source-licensed source code are not trade secrets and therefore able to be re-implemented by others in independent, differently-licensed implementations. I do hope this is correct, because otherwise the pool of potential VM developers is even smaller than we thought it was. Free software comes with the freedom to study it. It would be a sad world if it was otherwise. Everyone would have to pick a single open source project to ever work on in their whole life, etc. :) The change is there because we want to avoid dealing with trade secrets, NDAs, non-competition clauses, and similar legal minefields often found in proprietary source code licenses. Those things are hard to deal with in many, many ways. Compared to that, free software is a walk in the park. Disagreements on the authorship of works, like this one, should be easy to resolve amicably, and I am glad everyone is making such a good effort towards resolving it. Heaven help me (and Wonka) if Dalibor finds out that for a few weeks at the end of the last century I worked on a port of Kaffe ... I am no fan of the legal theory of a copyright without any boundaries, and Kaffe comes under a free software license allowing study all that, just like Harmony. :) 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. :) cheers, dalibor topic
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Hi Chris, A little clarification. I don't claim that you can't study another's Free/Open Source (F/OS) VM source code, or that you can't contribute to multiple VMs over time. I claim that this does not allow you to COPY one VM's source code into another one without respecting the Copyright. Mainly, I was was arguing about one specific case at hand. (Experience tells me that theoretical discussions of hypothetic cases can lead to endless flame wars). Please have a look at the files pointed to by Archie Cobbs. You will see there similarities that go well beyond the general idea you get by reading another F/OS VM's source code. So, in most cases, it shouldn't be a problem to read another implementation's code. Yet, I would warn the Harmony class library developers to be careful on how they study other class libraries such as GNU Classpath. It is OK to *occasionally* read the source code of GNU Classpath and see how they resolved *some* of the problems, yet it would be wrong if Harmony started copying (or re-writing similarly, if that's clearer to you) GNU Classpath. Let say that taking a few days after reading the source code to work on something else, before coming back to the problem and think about some independent solution/implementation, would be highly recommended so that the code you write doesn't end up being an intelligent copy of other's code. Anyway, this is simply my little personal recommendation about it. Anyway, as I am not a Copyright holder of either class libraries, so you can take my opinion with a grain of salt. ;-) Note that as long as you are the Copyright holder, you can copy your code as much as you want, unless you assigned it to somebody else, in which case you should respect the rules of your assignment contract. Have fun! Etienne Chris Gray wrote: I do hope this is correct, because otherwise the pool of potential VM developers is even smaller than we thought it was. Heaven help me (and Wonka) if Dalibor finds out that for a few weeks at the end of the last century I worked on a port of Kaffe ... -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
On Monday 13 March 2006 15:22, 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. :) I'm afraid it's lost in the mists of time, Dali - last century was a long time ago. Plus the port was originally done by Transvirtual for a company which has since gone bankrupt, so there could be some difficulties in getting the necessary clearances ... Cheers, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: jira messages redirected to commits mailing list
On Tue, Mar 07, 2006 at 03:51:31PM -0500, Geir Magnusson Jr wrote: That's great! I wonder if we have that feature turned on in the ASF installation Craig Blake wrote: One of the cooler Jira features is the mailing list integration. You can subscribe it to the mailing list, after which it will automatically scan email subjects for issue identifiers (i.e. HARMONY-) and add the email content as a comment to the referenced issue, including attachments. That might make it easier to maintain discussion on the list and have it propagated into JIRA rather than the other way around, if that's the way people want to go. http://www.atlassian.com/software/jira/docs/latest/issue_creation_email.html Jeff turned some of this kind of stuff on at some point then turned it off again. I believe it is not set up properly; there's a lot of detail in the infra@ mbox archives; I believe its all not so trivial. - Leo
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Hi everyone, I am not a laywer. I don't play one on TV, though I've played one on stage a few weeks ago. If I understand correctly, determining whether codebase A is a derivative work of codebase B is somewhat hard work. We have a codebase B in the Harmony tree and a contributor to codebase A asserting that codebase B is a derivative of codebase A, with codebase A under a non-apache-license-compatible license. We have therefore closed off all access to codebase B but have not verified this assertion. There is some history here with codebase A and B which is becoming clearer through mailing list discussion. On Sun, Mar 12, 2006 at 10:44:56PM -0500, Etienne Gagnon wrote: See below. So, if the Harmony project has no problem acknowledging the shared Copyright of SableVM authors on JCHEVM, I will get in touch with these authors to get their consent to a license change. That's excellent! I see no problem with that. We traditionally give credit where credit is due for anything we redistribute. Great! Then I'll get on with that task. Please understand, though, that it might take one or two weeks to resolve (hoping I am not too optimistic). Some copyright holders might be difficult to reach. I will do it as fast as I can. Do I understand correctly that rather than go through the motions of actually having to go through the painful route of proving or disproving this derivative work assertion, we are going to try and make codebase A a contribution under an apache-license-compatible license? I must say it sounds very tempting (I really don't want us to waste time and energy on (dis)proving something if we don't have to. Writing code is just much more fun) but I don't fully understand if this is enough due dilligence on the ASF side. Can we leave this infringement claim hanging around and just jump to fixing the problem even if it might not actually be one, since it has some nice side effects? cheers, Leo
Re: [classlib] bug-to-bug compatibility: SecureRandom
On 3/13/06, Paulex Yang [EMAIL PROTECTED] wrote: Mikhail I think current Harmony code is fine in this case. Because it is reasonable to consider null as another exceptional case and to differentiate it with the case of non-existing algorithm. +1 -- Anton Avtamonov, Intel Middleware Products Division
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
On Mon, Mar 13, 2006 at 09:04:49AM -0800, Leo Simons wrote: Hi everyone, I am not a laywer. I don't play one on TV, though I've played one on stage a few weeks ago. If I understand correctly, determining whether codebase A is a derivative work of codebase B is somewhat hard work. We have a codebase B in the Harmony tree and a contributor to codebase A asserting that codebase B is a derivative of codebase A, with codebase A under a non-apache-license-compatible license. We have therefore closed off all access to codebase B but have not verified this assertion. There is some history here with codebase A and B which is becoming clearer through mailing list discussion. On Sun, Mar 12, 2006 at 10:44:56PM -0500, Etienne Gagnon wrote: See below. So, if the Harmony project has no problem acknowledging the shared Copyright of SableVM authors on JCHEVM, I will get in touch with these authors to get their consent to a license change. That's excellent! I see no problem with that. We traditionally give credit where credit is due for anything we redistribute. Great! Then I'll get on with that task. Please understand, though, that it might take one or two weeks to resolve (hoping I am not too optimistic). Some copyright holders might be difficult to reach. I will do it as fast as I can. Do I understand correctly that rather than go through the motions of actually having to go through the painful route of proving or disproving this derivative work assertion, we are going to try and make codebase A a contribution under an apache-license-compatible license? I must say it sounds very tempting (I really don't want us to waste time and energy on (dis)proving something if we don't have to. Writing code is just much more fun) but I don't fully understand if this is enough due dilligence on the ASF side. Can we leave this infringement claim hanging around and just jump to fixing the problem even if it might not actually be one, since it has some nice side effects? As far as I parse the discussion, Etienne agrees to do the necessary work to contribute his his codevelopers' codebase to us, so I believe the simplest due dilligence solution for the ASF would be for the infringement claim to be withdrawn, so that codebase B can be unblocked now, while the paperwork on codebase A is being finished. Alternatively, we could also keep codebase B locked down until we have the paperwork for the codebase A submission, which would also be simple, but not my favourite choice. Finally, we could do the painful thing, but I am sure nobody needs that. cheers, dalibor topic cheers, Leo
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
On Fri, Mar 10, 2006 at 09:24:24AM -0800, Weldon Washburn wrote:
On 3/10/06, Archie Cobbs [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
Please take a look at bootstrap.c It would be great if we can do the
final integration in the next 2 days while this code is still fresh in
my mind.
Looks reasonable, you just commented out or changed the classes
and methods that would not load yet.
What's the plan for dealing with the Pointer class? Here are some
possibilities that preserve Classpath compatibility:
1. Implement gnu.classpath.Pointer{32,64} in classlib
2. Have jchevm autodetect whether gnu.classpath.Pointer or
java.lang.Pointer is to be used.
Either solution is OK with me, but I'd much prefer #1 because it's
cleaner code and I'd rather not start adding hacks at this point that
move us away from the current common API.
I agree that #1 is the cleanest, easiest technical approach. The
difficulty is convincing an attorney that a file in Harmony Class Lib
called blah blah GNU blah blah CLASSPATH has nothing to do with gnu
or classpath.
We don't have to -- these things have something to do with one another,
namely, we have the files there in that way so we have code that is
compatible, which is a Cool Thing(tm).
I vote for adding a few lines of code to avoid spending
hours with an attorney. How about an algorithm that first checks for
gnu.classpath.PointerXX and if its not found then looks for
xxx.yyy.zzz.Pointer class? I am not happy with putting Pointer
classes in the java.lang package. Maybe create a new package called
kernel_path. Thoughts?
Then we'd move the gnu and classpath references into the algorithm.
We're still going to need them. My friend Cliff Schmidt tells me that
the verdict is still out on whether interfaces are copyrightable at all.
My friend Mark Wielaard tells me the GNU Classpath people like working
together with other people and love to see various kinds of
interoperability.
So while I have no idea what the fine-grained legal details are, I have
a strong hunch having some references to gnu and classpath every now
and then is ok.
LSD
[tools] Eclipse JRE support
I've put the HARMONY-127 (Eclipse plug-in for Harmony JRE support) source code into SVN. Is there an appropriate Eclipse update site where we can host the built plug-in, or should I create one on the Harmony server? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Hi Dalibor, Leo, and all, Archie wrote: 3. So what do we do? My wish is to give SableVM the benefit of the doubt. If there's something in there they claim is theirs, we can take it out and replace it. I'd rather do that than argue about it. We should remember that JCVM owes SableVM a debt of gratitude and respect their wishes. Etienne wrote: So, if the Harmony project has no problem acknowledging the shared Copyright of SableVM authors on JCHEVM, I will get in touch with these authors to get their consent to a license change. Geir answered: That's excellent! I see no problem with that. We traditionally give credit where credit is due for anything we redistribute. So, just to make things Cristal clear: 1- I do claim shared copyright on JCVM/JCHEVM. I do not and will not back down from this. 2- As far as I can tell from the above, both the ASF and Archie Cobbs seem to agree to acknowledge this shared copyright. 3- The only obscure area that is left (i.e. an area where there is no explicit agreement between all involved) is: which exact parts can be claimed independent work and which cannot not. It seems easier to agree to simply state the shared copyright on JCHEVM and leave the detail of exact files and lines out. Personally, I claim co-ownership on the whole derivative of SableVM. I am sure Archie Cobbs would do the reverse. Unfortunately, it would probably be quite difficult to settle this out of court. Do you really want this to escalate that far? 4- Once this shared copyright is acknowledged, there is a license issue to solve. The ASF has not been given a permission by SableVM authors to distribute the derivative work, namely JCHEVM, under the Apache License. This is where I am amicably proposing a hopefully elegant solution: to ask SableVM authors to give such permission, so that we can all go on with our lives and continue development. Anyway, I have made SableVM Free/Opens Source so that people can copy, share and derive code from it; I see no reason not to let people do so. All I am asking for is a little respect of my copyright on software to which I have dedicated years of work. Regards, Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: jira messages redirected to commits mailing list
Mikhail Loenko wrote: Hi Leo 2006/3/10, Leo Simons [EMAIL PROTECTED]: Hi Mikhail! On Thu, Mar 09, 2006 at 10:34:46AM +0600, Mikhail Loenko wrote: Actually there are important things that are to be tracked in JIRA. Err...here's that rule again: Really Important Things MUST Go In SVN And/Or Onto The Public Mailing List Well, that does not mean that they must not go into JIRA, right? The point is that artifacts of permanence for the project go into SVN, and discussions go on the mailing list. Geir has created category Non-bug differences from RI [1] and those differences are to go there. note I'm not saying that discussions of the differences are to go there /note I did that as a way of being able to catalog and track the differences. We could put them in SVN too. I don't care - I just think we'd be well served by tracking them in one place in case a question arises... geir
Re: Location of test data files
Stepan Mishura wrote:
Hi George,
I like you idea with loading test's resource files. I don't see any
maintenance issues with putting all resource files into src/test/resources
folder, for example, if a test have several resource files then I'd like to
keep them in separate folder rather then in a test's folder. Also don't
think that there will be name collision problems: java files go to
test/java and resource files go to test/resources. Is anybody going to
put class files there?
As long as you keep a parallel package tree, it should be equivalent of
how we do it now. Not quite sure what we gain other than it's neater...
geir
George Harley wrote:
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()));
FYI, SerializationTest.java is not the only one case. There are few places
where TEST_SRC_DIR system property is used, for example, policy resource
files see:
modules/security/test/common/unit/javax/security/auth/PolicyTest.java
modules/security/test/common/unit/javax/security/auth/jaas_policy1.txt
modules/security/test/common/unit/javax/security/auth/jaas_policy2.txt
I think it won't be an issue to fix them if your suggestion will be
accepted.
BTW, as far as I remember we agreed to call new security module 'auth'
because of 'JAAS' trademark issues so I guess we should rename two policy
files say to auth_policyn.txt. I'm going to search all such cases and
provide a patch.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 3/11/06, 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.
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,
Stepan Mishura
Intel Middleware Products Division
Re: Location of test data files
George Harley wrote: Geir Magnusson Jr 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. :-) Yes - for maintenance and name collision, this makes sense. That is how security does it now. geir Sorry, I don't understand the name collision issue. Could you explain ? I guess it depends on what you are proposing, but if there isn't a parallel package structure in resources/ as we have in java/ then we may have file name collisions... geir Best regards, George
Re: Location of test data files
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. Great - that wasn't clear. This works for me. geir
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
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? geir
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Etienne Gagnon wrote: 1- I do claim shared copyright on JCVM/JCHEVM. I do not and will not back down from this. 2- As far as I can tell from the above, both the ASF and Archie Cobbs seem to agree to acknowledge this shared copyright. Um, I think I agree... so what is the practical import? In other words, if JCVM/JCHEVM can be licensed under the Apache license, then I'm satisfied. I don't plan on ever trying to take this stuff closed source or whatever.. so anyone else sharing copyright shouldn't matter (to me) right? 3- The only obscure area that is left (i.e. an area where there is no explicit agreement between all involved) is: which exact parts can be claimed independent work and which cannot not. It seems easier to agree to simply state the shared copyright on JCHEVM and leave the detail of exact files and lines out. Personally, I claim co-ownership on the whole derivative of SableVM. I am sure Archie Cobbs would do the reverse. Unfortunately, it would probably be quite difficult to settle this out of court. Do you really want this to escalate that far? I agree it would be messy to try to separate it out, even though most of JCVM is not derivative (e.g., the garbage collector, weak and phantom reference support, finalization support, bytecode interpreter, ZIP file reader, class file parser, class loader and resolution code, class file dump tool, javah tool, JAR file launcher, heap structure, Thread.interrupt support, reflection support, signal handler, etc.). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
RE: [tools] Eclipse JRE support
If there's not an appropriate or designated place for the Eclipse update site, you can always check it into SVN and just point Eclipse updater to the SVN ViewCVS URL. Another nice feature of the update sites is that you can point the feature URLs to any URL and you can redirect the plug-ins using the archive elements. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 4:39 PM To: harmony-dev Subject: [tools] Eclipse JRE support I've put the HARMONY-127 (Eclipse plug-in for Harmony JRE support) source code into SVN. Is there an appropriate Eclipse update site where we can host the built plug-in, or should I create one on the Harmony server? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Etienne Gagnon wrote: Hi Dalibor, Leo, and all, Archie wrote: 3. So what do we do? My wish is to give SableVM the benefit of the doubt. If there's something in there they claim is theirs, we can take it out and replace it. I'd rather do that than argue about it. We should remember that JCVM owes SableVM a debt of gratitude and respect their wishes. Etienne wrote: So, if the Harmony project has no problem acknowledging the shared Copyright of SableVM authors on JCHEVM, I will get in touch with these authors to get their consent to a license change. Geir answered: That's excellent! I see no problem with that. We traditionally give credit where credit is due for anything we redistribute. So, just to make things Cristal clear: 1- I do claim shared copyright on JCVM/JCHEVM. I do not and will not back down from this. In interpret this claim to be for some number of specific areas, such as threading and locking, and some others which we haven't quite nailed down yet. 2- As far as I can tell from the above, both the ASF and Archie Cobbs seem to agree to acknowledge this shared copyright. No. I hope this doesn't appear to be harsh, and I'll explain after, but I need to make this clear : The ASF does not at this time acknowledge the validity of your claim of shared copyright. We acknowledge that you have made a claim, have taken the step of immediately ceasing any distribution of the disputed code, and are making our best effort to get to the bottom of the problem with the intention of arriving at an amicable and mutually agreeable solution. When I said That's excellent! that was my run for the airport message - I meant that if you dual-licensed the code, we'd have no problem in acknowledging the authors of code we redistributed or made a derived work from. Sorry if I was confusing. 3- The only obscure area that is left (i.e. an area where there is no explicit agreement between all involved) is: which exact parts can be claimed independent work and which cannot not. It seems easier to agree to simply state the shared copyright on JCHEVM and leave the detail of exact files and lines out. Personally, I claim co-ownership on the whole derivative of SableVM. I am sure Archie Cobbs would do the reverse. Unfortunately, it would probably be quite difficult to settle this out of court. Do you really want this to escalate that far? No one wishes to escalate anything - I'm sure you don't, and I'm sure that we don't. 4- Once this shared copyright is acknowledged, there is a license issue to solve. The ASF has not been given a permission by SableVM authors to distribute the derivative work, namely JCHEVM, under the Apache License. This is where I am amicably proposing a hopefully elegant solution: to ask SableVM authors to give such permission, so that we can all go on with our lives and continue development. Anyway, I have made SableVM Free/Opens Source so that people can copy, share and derive code from it; I see no reason not to let people do so. All I am asking for is a little respect of my copyright on software to which I have dedicated years of work. And we are certainly working to do that. Suppose we do this (and this is me just throwing out solutions for discussion...) Instead of you having to go through the labor of finding all the contributors to SableVM to make such a licensing statement, why not do it for the thread and lock code? Do it under a license such as MIT so it's compatible with the LGPL (or dual LGPL + AL ) and then we will give credit to the authors and the project. If that's ok, and further, that makes you comfortable to drop #3 above, does this solve it for all? geir
Re: Location of test data files
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
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,
Stepan Mishura
Intel Middleware Products Division
Re: [jira] Updated: (HARMONY-150) java.nio.charset.Charset.decode(in) doesn't use the same cached decoder.
Should the Anonymous user really be permitted to submit attachments?
We can't really use them unless provenance is clear.
I assume this was submitted by Richard but
-Mark.
On 3/14/06, Anonymous (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-150?page=all ]
updated HARMONY-150:
-
Attachment: CharsetTest_Patch_150.txt
java.nio.charset.Charset.decode(in) doesn't use the same cached decoder.
Key: HARMONY-150
URL: http://issues.apache.org/jira/browse/HARMONY-150
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Attachments: CharsetTest_Patch_150.txt, Charset_patch_150.txt
java.nio.charset.Charset.decode(in) doesn't use the same cached decoder.
As spec says, An invocation of this method upon a charset cs returns the
same result as the expression cs.newDecoder()
.onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE) .decode(bb); except that
it is potentially more efficient because it can cache decoders between
successive invocations.
RI always uses the same cached decoder (the same reference) for the same
name charset. For details, please refer to the test case below:
test case output =
RI 5.0 passes the test case while Harmony fails.
test case===
/*
* test cached decoder
*/
public void testCachedDecoder() throws Exception{
MockCachedCharset cs1 = new
MockCachedCharset(CachedCharset,null);
MockCachedCharset cs2 = new
MockCachedCharset(CachedCharset,null);
ByteBuffer in = ByteBuffer.wrap(new byte[]{0x00});
cs1.decode(in);
in.flip();
cs2.decode(in);
in.flip();
}
/*
* Mock Charset for cached decoder test
*/
static class MockCachedCharset extends Charset{
public MockCachedCharset(String canonicalName, String[]
aliases){
super(canonicalName, aliases);
}
public boolean contains(Charset charset) {
return false;
}
public CharsetEncoder newEncoder() {
return null;
}
public CharsetDecoder newDecoder() {
return new MockCachedDecoder(this);
}
}
/*
* Mock decoder. Only one caller is permitted.
*/
static class MockCachedDecoder extends CharsetDecoder {
static MockCachedDecoder caller = null;
public MockCachedDecoder(Charset cs) {
super(cs, 1, 10);
}
/*
* Only one caller is permitted.
* If there's another caller, throw RuntimeException.
*/
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer
out) {
if(null == caller){
caller = this;
}else{
if(caller != this){
// Another instance
throw new RuntimeException();
}
}
return CoderResult.UNDERFLOW;
}
}
--
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
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
Re: [jira] Updated: (HARMONY-150) java.nio.charset.Charset.decode(in) doesn't use the same cached decoder.
On 3/14/06, Mark Hindess [EMAIL PROTECTED] wrote: Should the Anonymous user really be permitted to submit attachments? We can't really use them unless provenance is clear. I assume this was submitted by Richard but ... this type of mistake should be prevented by JIRA if possible? Sorry for the incomplete message, I accidentally hit send while reaching for my coffee. I obviously need it. ;-) -Mark. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK.
All that JAAS ( Was Re: [jira] Created: (HARMONY-198) Eliminate using word 'JAAS' from source files)
Why? Stepan Mishura (JIRA) wrote: Eliminate using word 'JAAS' from source files -- Key: HARMONY-198 URL: http://issues.apache.org/jira/browse/HARMONY-198 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Priority: Trivial We should avoid using word 'JAAS' in source files
Re: [jira] Updated: (HARMONY-150) java.nio.charset.Charset.decode(in) doesn't use the same cached decoder.
Mark Hindess wrote: On 3/14/06, Mark Hindess [EMAIL PROTECTED] wrote: Should the Anonymous user really be permitted to submit attachments? We can't really use them unless provenance is clear. I assume this was submitted by Richard but ... this type of mistake should be prevented by JIRA if possible? Sorry for the incomplete message, I accidentally hit send while reaching for my coffee. I obviously need it. ;-) -Mark. Hello Mark, I'm also confusing about this problem. It IS me who submitted the patch. Maybe a bug of JIRA system. :-) Thanks a lot. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Richard Liang China Software Development Lab, IBM
Re: All that JAAS
It was proposed to name new module 'jaas' (see [1]) but this name was declined (one of reasons was - possible trademark issues) and the module was named 'auth'. To be consistent and avoid confusion in using 'jaas' vs. 'auth' I'd eliminate word 'JAAS' from source files. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] Thanks, Stepan On 3/14/06, Geir Magnusson Jr wrote: Why? Stepan Mishura (JIRA) wrote: Eliminate using word 'JAAS' from source files -- Key: HARMONY-198 URL: http://issues.apache.org/jira/browse/HARMONY-198 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Priority: Trivial We should avoid using word 'JAAS' in source files
