Re: classlib test suite status emails?
Stepan, I have another build running (but without notifications going to the list) that runs: 1) build (with reference jdk) 2) build with what we created with 1) 3) test 4) create classlists and compare with class load data for applications (tomcat, geronimo, continuum, etc.) 5) generate JAPI results I'd like to fail this build at step 3, but I can't see an easy way to get 'ant -f make/build.xml test' to run all tests and then fail if any of the module test sub-targets had test failures. I could parse the output I suppose, but I'd rather get ant to propagate the junit tasks failure property back up to the top level. I've tried a couple of things and none seem to work. Any suggestions welcome. Regards, Mark. On 4/11/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > Hi, > > I've checked out at morning last updates, built the code base and run the > tests …and there are 24 tests failures! > > There are 9 tests failures in > org.apache.harmony.tests.java.nio.channels.DatagramChannelTest – I saw these > failures before from time to time. It seems that tests depend on some race > conditions because they may pass if I rerun them. Paulex, are these tests > passing for you? > > And there are new 15 test failures. So now if I'll make a code update or a > bug fix how I can be 100% sure that I don't do any regression? > > Currently if a commit breaks the Harmony classlib build a notification with > subject: "[continuum] BUILD FAILURE: Classlib/linux.ia32" will be send to > harmony-commits mailing list. Is it possible to have the same for tests? I > mean that after completing automatic build the existing classlib tests suite > should be run. If there are failing tests then a report notification with > corresponding subject will be send. > > Thanks, > Stepan Mishura > Intel Middleware Products Division -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
On 4/11/06, Mark Hindess wrote: > > Based on the goal of "being least confusing to users", I'm in favour > of matching the behaviour rather than the spec when there is any doubt > - users will expect something that runs on reference jre to run on > harmony and fail in the same way(s). And what if RI behaviour "is confusing to users" like in HARMONY-315? I think in this case we should follow the spec. > Based on the same goal, I also think matching 5.0 behaviour is the > correct thing to do. If Harmony is going to be a 5.0 implementation > our users will naturally expect things to behave the same way as a 5.0 > reference implementation. > > JIRA issues should have a clear resolution/category to record these > decisions - and any discussion on the mailing list should be > summarised in the JIRA so that we can refer people to the decision. > And so that we can revisit them when, as Geir says, we have achieved > world domination. > > Incidentally, it would be good to have some input on HARMONY-266 and > HARMONY-315. (I think Stepan and I are the only ones discussing them > and we have opposite views. ;-) See: Yes, it would be good to hear other opinions. Thanks, Stepan. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] > > and: > > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL > PROTECTED] > > Regards, > Mark. > > On 4/11/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > It's not too late to think about it once again and probably revisit > > the decision. > > > > As I understand goal #1 is to meet needs of as many potential users as > we can > > and decision to be spec incompatible in favor of new hot RI version > might be not > > the best one. > > > > Thanks, > > Mikhail > > > > 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > > I think that people will steadily move up in versions, and maybe most > > > importantly, we *are* trying to build Java SE 5, not J2SE 1.4... > > > > > > geir > > > > > > > > > Mikhail Loenko wrote: > > > > BTW, when we were deciding that we follow RI rather then the spec, > we > > > > cared about breaking existing implementations. But if RI changed its > behavior > > > > from being compatible to the spec in 1.4 to being incompatible in > 1.5 then do > > > > we believe that existing applications more likely stick to the > latest > > > > (1.5) version? > > > > > > > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? > > > > > > > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266) > > > > java.security.Signature.getInstance(String,Provider) should match > 5.0 > > > > reference implementations behaviour" mail thread. > > > > > > > > Thanks, > > > > Mikhail > > > > > > > > > > > > 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > > >> > > > >> Paulex Yang wrote: > > > >>> Mark > > > >>> > > > >>> You just point out a serious issue ;-) . The RI is just a concept, > in > > > >>> fact we have many RIs, Sun's JDK, BEA's JDK, even different > versions, > > > >>> Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I > expects), and > > > >>> on different platforms(win32, linux32, still even more in > future)...In > > > >>> fact sometimes they have different behavior themselves, it is very > > > >>> reasonable that 1.5.06 fix some bugs of 1.5.0, so that some > different > > > >>> exceptions thrown(more reasonable IAE instead of NPE, for > example), or > > > >>> more seriously, different results returned... Samples are > available upon > > > >>> request:). > > > >> Actually, there only is one RI for any given spec, and in this > case, I > > > >> guess we judge it to be the latest version of a spec that comes > from > > > >> Sun? (The question isn't if it comes from Sun - as the spec lead, > they > > > >> supply the RI - but rather what version...) > > > >> > > > >> geir > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Stepan Mishura Intel Middleware Products Division
Re: [jira] Created: (HARMONY-315) javax.crypto.Cipher.getInstance doesn't match RI exception behaviour.
Mark, IMHO in this case we shouldn't follow RI because Harmony
implementation corresponds to the spec. and it is consistent. I'm not OK
with introducing confusing behavior to our users. Why only "" string was
selected as invalid? Why not to check " " string also (RI rejects such
string with NoSuchProviderException)?
Thanks,
Stepan.
On 4/10/06, Mark Hindess wrote:
>
> Hmm... I agree that the behaviour is inconsistent. But I think
> matching the RI behaviour is unlikely to inconvenience our users. So,
> I'd still say we should match the behaviour of Sun's 5.0
> implementation (which means we'll also match IBM's and BEA's).
>
> Regards,
> Mark.
>
> On 4/10/06, Stepan Mishura < [EMAIL PROTECTED]> wrote:
> > On 4/10/06, Mark Hindess wrote:
> > >
> > > On 4/10/06, Stepan Mishura wrote:
> > > > Hi Mark,
> > > >
> > > > Basing on the bug description I assume that RI checks provider
> parameter
> > > > first.
> > >
> > > Yes.
> > >
> > > > In all your examples this parameter is invalid.
> > >
> > > Yes. (It was one of the test cases generated by my Perl script - that
>
> > > I've nearly finished tidying up for contribution.)
> > >
> > > > The spec. for method javax.crypto.Cipher.getInstance(String
> > > transformation,
> > > > String provider)
> > > > says:
> > > > "Throws:
> > > > NoSuchAlgorithmException - if transformation is null, empty, in
> an
> > > > invalid format, or not available from the specified provider.
> > > > NoSuchProviderException - if the specified provider has not been
> > > > configured.
> > > > NoSuchPaddingException - if transformation contains a padding
> scheme
> > > > that is not available.
> > > > IllegalArgumentException - if the provider is null."
> > > >
> > > > So IllegalArgumentException can be thrown only if the provider
> parameter
> > > is
> > > > null. But IMHO in case of empty string NoSuchProviderException
> should be
> > > > thrown.
> > > >
> > > > What do you think?
> > >
> > > So we agree about fixing the two cases where provider is (String)null.
> > > We just need to decide what to do about the other two where provider
> > > is (String)"" ?
> >
> >
> > Yes.
> >
> > I think we should match the RI behaviour. That means that even in the
> > > two cases where provider is the empty string we should still throw an
> > > IllegalArgumentException.
> > >
> > > I think the wording of the spec for the getInstance method that takes
> > > a String provider is just vague because it was copied from the method
> > > that takes a Provider object. I think the RI behaviour reflects the
> > > intention of the spec even if the spec is unclear.
> >
> >
> > The problem is that java.security.Security allows such provider name,
> for
> > example, the following code works on RI:
> >
> > === SmallProvider.java =
> > import java.security.Provider;
> > public class SmallProvider extends Provider {
> >
> > public SmallProvider() {
> > super("", // name
> > 1.0, // version
> > "SmallProvider" // info
> > );
> > }
> > }
> > === test.java ===
> > import java.security.Security;
> > public class test {
> > public static void main(String[] args){
> > Security.addProvider(new SmallProvider());
> > System.out.println(Security.getProvider("").getInfo());
> > }
> > }
> >
> > If we will follow RI then it will be possible to access Cipher object
> via:
> > Cipher.getInstance(, Security.getProvider(""));
> >
> > But impossible to do the same via: Cipher.getInstance( transformation>,
> > "");
> >
> > Thanks,
> > Stepan.
> >
> > Regards,
> > > Mark.
> > >
> > > > Thanks,
> > > > Stepan
> > > >
> > > > >From: Mark Hindess (JIRA)
> > > > >Sent: Friday, April 07, 2006 1:31 AM
> > > > >To: [EMAIL PROTECTED]
> > > > >Subject: [jira] Created: (HARMONY-315)
> javax.crypto.Cipher.getInstance
> > > > >doesn't match RI exception behaviour.
> > > > >
> > > > >javax.crypto.Cipher.getInstance doesn't match RI exception
> behaviour.
> > > >
> >-
> > > > >
> > > > > Key: HARMONY-315
> > > > > URL: http://issues.apache.org/jira/browse/HARMONY-315
> > > > > Project: Harmony
> > > > >Type: Bug
> > > > >
> > > > > Components: Classlib
> > > > >Reporter: Mark Hindess
> > > > >Priority: Trivial
> > > > >
> > > > >
> > > > >javax.crypto.getInstance methods doesn't match reference
> behaviour. It
> > > > >throws NoSuchProvideExceptions when it should be throwing
> > > > >IllegalArgumentExceptions. See log below for details.
> > > > >
> > > > >RI is Sun Microsystems Inc. 1.5.0_06
> > > > >Test is harmony classlib
> > > > >
> > > > >javax.crypto.Cipher.getInstance("",""):
> > > > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > > > Test throws java.security.NoSuchProviderException: Provider is
> not
> > > > >available
> > > > >
> > > > >javax.crypto.Cipher.get
Re: matching reference implementation exception behaviour
Based on the goal of "being least confusing to users", I'm in favour of matching the behaviour rather than the spec when there is any doubt - users will expect something that runs on reference jre to run on harmony and fail in the same way(s). Based on the same goal, I also think matching 5.0 behaviour is the correct thing to do. If Harmony is going to be a 5.0 implementation our users will naturally expect things to behave the same way as a 5.0 reference implementation. JIRA issues should have a clear resolution/category to record these decisions - and any discussion on the mailing list should be summarised in the JIRA so that we can refer people to the decision. And so that we can revisit them when, as Geir says, we have achieved world domination. Incidentally, it would be good to have some input on HARMONY-266 and HARMONY-315. (I think Stepan and I are the only ones discussing them and we have opposite views. ;-) See: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] and: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Regards, Mark. On 4/11/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > It's not too late to think about it once again and probably revisit > the decision. > > As I understand goal #1 is to meet needs of as many potential users as we can > and decision to be spec incompatible in favor of new hot RI version might be > not > the best one. > > Thanks, > Mikhail > > 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > I think that people will steadily move up in versions, and maybe most > > importantly, we *are* trying to build Java SE 5, not J2SE 1.4... > > > > geir > > > > > > Mikhail Loenko wrote: > > > BTW, when we were deciding that we follow RI rather then the spec, we > > > cared about breaking existing implementations. But if RI changed its > > > behavior > > > from being compatible to the spec in 1.4 to being incompatible in 1.5 > > > then do > > > we believe that existing applications more likely stick to the latest > > > (1.5) version? > > > > > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? > > > > > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266) > > > java.security.Signature.getInstance(String,Provider) should match 5.0 > > > reference implementations behaviour" mail thread. > > > > > > Thanks, > > > Mikhail > > > > > > > > > 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > >> > > >> Paulex Yang wrote: > > >>> Mark > > >>> > > >>> You just point out a serious issue ;-) . The RI is just a concept, in > > >>> fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, > > >>> Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and > > >>> on different platforms(win32, linux32, still even more in future)...In > > >>> fact sometimes they have different behavior themselves, it is very > > >>> reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different > > >>> exceptions thrown(more reasonable IAE instead of NPE, for example), or > > >>> more seriously, different results returned... Samples are available upon > > >>> request:). > > >> Actually, there only is one RI for any given spec, and in this case, I > > >> guess we judge it to be the latest version of a spec that comes from > > >> Sun? (The question isn't if it comes from Sun - as the spec lead, they > > >> supply the RI - but rather what version...) > > >> > > >> geir -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reporting failure
This url was send before ... resending
See: http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit_p.html
Paragraph: *Utilize JUnit's assert/fail methods and exception handling for
clean test code*
Thanks,
Stepan.
On 4/11/06, Mikhail Loenko wrote:
>
> I'm evaluating failures caused by intagration of H-88 tests and found out
> that that style which is used in some tests is not very convinient for me.
>
> I'd like to hear others' opinion.
>
> So for example here is a failure
> test: tests.api.java.security.AlgorithmParameterGeneratorTest
> test case: test_initLjava_security_spec_AlgorithmParameterSpec
>
> InvalidAlgorithmParameterException getting spec
>
> junit.framework.AssertionFailedError:
> InvalidAlgorithmParameterException getting spec at
>
> tests.api.java.security.AlgorithmParameterGeneratorTest.test_initLjava_security_spec_AlgorithmParameterSpec
> (AlgorithmParameterGeneratorTest.java:207)
> at
> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>
> This is how the test currently looks like:
>
> public void test_initLjava_security_spec_AlgorithmParameterSpec() {
>
>try {
>DSAParameterSpec spec = new DSAParameterSpec(
>BigInteger.ONE, BigInteger.ONE, BigInteger.ONE);
>AlgorithmParameterGenerator gen = AlgorithmParameterGenerator
>.getInstance("DSA");
>gen.init(spec);
>} catch (NoSuchAlgorithmException e) {
>fail("getInstance did not find algorithm DSA");
>} catch (InvalidAlgorithmParameterException e) {
>fail("InvalidAlgorithmParameterException getting spec");
>}
> }
>
> This is how I would rewrite the test:
>
> public void test_initLjava_security_spec_AlgorithmParameterSpec()
> throws Exception {
>...
>// checks that no exception is thrown
>DSAParameterSpec spec = new DSAParameterSpec(BigInteger.ONE,
>BigInteger.ONE, BigInteger.ONE);
>AlgorithmParameterGenerator gen = AlgorithmParameterGenerator
>.getInstance("DSA");
>gen.init(spec);
> }
>
> And here is new output:
> No supported AlgorithmParameterSpec for DSA parameter generation.
>
> java.security.InvalidAlgorithmParameterException: No supported
> AlgorithmParameterSpec for DSA parameter generation. at
>
> org.bouncycastle.jce.provider.JDKAlgorithmParameterGenerator$DSA.engineInit
> (Unknown
> Source) at java.security.AlgorithmParameterGenerator.init(
> AlgorithmParameterGenerator.java:164)
> at
> tests.api.java.security.AlgorithmParameterGeneratorTest.test_initLjava_security_spec_AlgorithmParameterSpec
> (AlgorithmParameterGeneratorTest.java:203)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>
>
> I can see where the failure occurs and its reason (missing
> functionality rather then
> invalid parameter spec)
>
> Comments?
>
> Thanks,
> Mikhail
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Stepan Mishura
Intel Middleware Products Division
reporting failure
I'm evaluating failures caused by intagration of H-88 tests and found out
that that style which is used in some tests is not very convinient for me.
I'd like to hear others' opinion.
So for example here is a failure
test: tests.api.java.security.AlgorithmParameterGeneratorTest
test case: test_initLjava_security_spec_AlgorithmParameterSpec
InvalidAlgorithmParameterException getting spec
junit.framework.AssertionFailedError:
InvalidAlgorithmParameterException getting spec at
tests.api.java.security.AlgorithmParameterGeneratorTest.test_initLjava_security_spec_AlgorithmParameterSpec(AlgorithmParameterGeneratorTest.java:207)
at
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
This is how the test currently looks like:
public void test_initLjava_security_spec_AlgorithmParameterSpec() {
try {
DSAParameterSpec spec = new DSAParameterSpec(
BigInteger.ONE, BigInteger.ONE, BigInteger.ONE);
AlgorithmParameterGenerator gen = AlgorithmParameterGenerator
.getInstance("DSA");
gen.init(spec);
} catch (NoSuchAlgorithmException e) {
fail("getInstance did not find algorithm DSA");
} catch (InvalidAlgorithmParameterException e) {
fail("InvalidAlgorithmParameterException getting spec");
}
}
This is how I would rewrite the test:
public void test_initLjava_security_spec_AlgorithmParameterSpec()
throws Exception {
...
// checks that no exception is thrown
DSAParameterSpec spec = new DSAParameterSpec(BigInteger.ONE,
BigInteger.ONE, BigInteger.ONE);
AlgorithmParameterGenerator gen = AlgorithmParameterGenerator
.getInstance("DSA");
gen.init(spec);
}
And here is new output:
No supported AlgorithmParameterSpec for DSA parameter generation.
java.security.InvalidAlgorithmParameterException: No supported
AlgorithmParameterSpec for DSA parameter generation. at
org.bouncycastle.jce.provider.JDKAlgorithmParameterGenerator$DSA.engineInit(Unknown
Source) at
java.security.AlgorithmParameterGenerator.init(AlgorithmParameterGenerator.java:164)
at
tests.api.java.security.AlgorithmParameterGeneratorTest.test_initLjava_security_spec_AlgorithmParameterSpec(AlgorithmParameterGeneratorTest.java:203)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
I can see where the failure occurs and its reason (missing
functionality rather then
invalid parameter spec)
Comments?
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
On 4/11/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Mark Hindess wrote: > > Mikhail, Thanks for the pointers. > > > > I dug back in the mail archives. Geir wrote: > > > >> I think of it still as "live material" in our tree, but I don't > >> feel too strongly about this. If we keep it there, we should set a > >> policy to expire it out of there at some point. > > > > I'd suggest that the two files that you mention which are "never used" > > probably don't qualify as "live material". ;-) > > Agreed. > > > > > So, now my question is when is it going to be expired? i'd suggest > > that anything moved to archive should have an expiry date set in a > > file or svn property when it is moved so it is clear when it will be > > removed. > > > > Personally, I still think having paths archive/modules and > > modules/archive is confusing. 99% of our users will never use the > > extra >1.5M overhead of "svn checkout" that 'archive' creates. The 1% > > who might want it can easily find it in svn. > > The only reason we stuck security in an archive/modules was because we > wanted an easy way to be copying things that we found useful to the live > version - mainly javadoc and such. We were afraid that if we deleted > it, it would be a pain to do that. That's a good point. I'd forgotten that it was a little easier to create HARMONY-277 with archive where it was. Still, it'd be just as easy with archive out of the main tree too. > My real fear is that we'd collectively forget. Maybe I'm just projecting :) No comment. ;-) > So how about this - why don't we put a text file somewhere (in SVN!) in > which we "log" major things that we delete, and put the svn rev # of > where it was live. Or we could just move archive out of the classlib/trunk? > That way we don't forget what we've tossed, and also make it easy to get > something back, w/o having to play "wack-a-mole" with the version numbers... > > Also, if it's small stuff, I assume that there's no reason to log unless > someone squawks...? If we moved the files out of classlib/trunk then we'd have a log of all the moves for free with "svn log https://svn.apache.org/.../archive";. I should point out that would help to make what is being moved explicit in the log message... the log message from the security move says: moving to archive so we can harvest the javadoc easily at some point in near future which might be a rather common for an archive tree. Regards, Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long,long testcase name...
2006/4/11, Paulex Yang <[EMAIL PROTECTED]>: > Geir Magnusson Jr wrote: > > testRequestPasswordAuthentication1() > > > > I mean, why do we want to embed all that crap in the testcase name? > > Who cares? The only person that will care is someone fixing when a > > testcase breaks, and they'll read the code... > > > IMHO, the information is also useful when someone want to do some work > like upgrade, he may need to know if there is any test cases for the > requestPasswordAuthention(blabla...). Why not using a coverage tool? At least it is more reliable. Thanks, Mikhail But I agree that the current > naming convention almost lost its value because it is so difficult for > human reading. Maybe this information can be provided in other ways, > like annotation. > > geir > > > > > > LvJimmy，Jing wrote: > >> Hi all: > >> > >> Following our testcase naming convention, I've find a name as: > >> (hope it > >> won't break your screen :)) > >> public void > >> test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType() > >> > >> which is the testcase for > >> java.net.Authenticator.requestPasswordAuthentication( > >> String rHost, InetAddress rAddr, int rPort, String > >> rProtocol, > >> String rPrompt, String rScheme, URL rURL, > >> Authenticator.RequestorType reqType); > >> and the class has another two method named > >> requestPasswordAuthentication, > >> and only this method take URL and RequestorType as its parameters. > >> The name is somehow too long to see and read, and I guess we can > >> find a > >> shorter one for it, > >> e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and > >> RequestorType can identify the exactly > >> method to test. Or a adjusted naming convention shall be take. Any > >> opinions? > >> > >> -- > >> > >> Best Regards! > >> > >> Jimmy, Jing Lv > >> China Software Development Lab, IBM > >> > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Paulex Yang > China Software Development Lab > IBM > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
classlib test suite status emails?
Hi, I've checked out at morning last updates, built the code base and run the tests …and there are 24 tests failures! There are 9 tests failures in org.apache.harmony.tests.java.nio.channels.DatagramChannelTest – I saw these failures before from time to time. It seems that tests depend on some race conditions because they may pass if I rerun them. Paulex, are these tests passing for you? And there are new 15 test failures. So now if I'll make a code update or a bug fix how I can be 100% sure that I don't do any regression? Currently if a commit breaks the Harmony classlib build a notification with subject: "[continuum] BUILD FAILURE: Classlib/linux.ia32" will be send to harmony-commits mailing list. Is it possible to have the same for tests? I mean that after completing automatic build the existing classlib tests suite should be run. If there are failing tests then a report notification with corresponding subject will be send. Thanks, Stepan Mishura Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][vm] Error running trunk builds and IBM VME v2
I've been trying to run the latest code in the trunk with the IBM VME v2, but I'm getting an error. I'm able to compile the entire classlib and native libraries on Windows just fine and then paste the IBM VME distribution over the 'deploy' folder. Every time I try to run a Java class I get an error about the String class missing. Here's the exact error message I'm getting: JVMJ9VM019E Fatal error: Unable to find and initialize required class java/lang/String JVMJ9VM020I Searched in C:\Documents and Settings\Nathan\Desktop\Harmony\trunk\deploy\jre\bin\default\luni-kernel.jar JVMJ9VM020I Searched in C:\Documents and Settings\Nathan\Desktop\Harmony\trunk\deploy\jre\bin\default\security-kernel .jar JVMJ9VM023I This may indicate that JAVA_HOME is incorrect, or that class libraries are not installed Since the String class moved to luni, which is in the 'jre/lib/boot' folder, the VM won't find it in the luni-kernel or security-kernel JARs. Is there just something that I'm missing in setting up the classlib with the IBM VME? Any thoughts? Thanks, -Nathan
Re: Long,long testcase name...
Geir Magnusson Jr wrote: testRequestPasswordAuthentication1() I mean, why do we want to embed all that crap in the testcase name? Who cares? The only person that will care is someone fixing when a testcase breaks, and they'll read the code... IMHO, the information is also useful when someone want to do some work like upgrade, he may need to know if there is any test cases for the requestPasswordAuthention(blabla...). But I agree that the current naming convention almost lost its value because it is so difficult for human reading. Maybe this information can be provided in other ways, like annotation. geir LvJimmy，Jing wrote: Hi all: Following our testcase naming convention, I've find a name as: (hope it won't break your screen :)) public void test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType() which is the testcase for java.net.Authenticator.requestPasswordAuthentication( String rHost, InetAddress rAddr, int rPort, String rProtocol, String rPrompt, String rScheme, URL rURL, Authenticator.RequestorType reqType); and the class has another two method named requestPasswordAuthentication, and only this method take URL and RequestorType as its parameters. The name is somehow too long to see and read, and I guess we can find a shorter one for it, e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and RequestorType can identify the exactly method to test. Or a adjusted naming convention shall be take. Any opinions? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long,long testcase name...
2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > testRequestPasswordAuthentication1() > > I mean, why do we want to embed all that crap in the testcase name? Who > cares? The only person that will care is someone fixing when a testcase > breaks, and they'll read the code... To make our code easy and clear to read, a good naming convention is necessary as I think, that's why I dare say testRequestPasswordAuthentication1() is not so good for people to tell which method is tested here. The current naming convention is not bad but take too mang characters. Your opinion?:) geir > > > LvJimmy，Jing wrote: > > Hi all: > > > > Following our testcase naming convention, I've find a name as: (hope > it > > won't break your screen :)) > > public void > > > test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType() > > which is the testcase for > > java.net.Authenticator.requestPasswordAuthentication( > > String rHost, InetAddress rAddr, int rPort, String > rProtocol, > > String rPrompt, String rScheme, URL rURL, > > Authenticator.RequestorType reqType); > > and the class has another two method named > requestPasswordAuthentication, > > and only this method take URL and RequestorType as its parameters. > > The name is somehow too long to see and read, and I guess we can > find a > > shorter one for it, > > e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and > > RequestorType can identify the exactly > > method to test. Or a adjusted naming convention shall be take. Any > opinions? > > > > -- > > > > Best Regards! > > > > Jimmy, Jing Lv > > China Software Development Lab, IBM > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
RE: [jira] Resolved: (HARMONY-289) [classlib][luni-kernel] Update StackTraceElement for Java 5
I tried to add a comment to verify this bug, but I received an odd error. Is there an issue with JIRA? An existing index lock was found. An index lock file was found unexpectedly. This occurs either because JIRA was not cleanly shutdown or because there is another instance of this JIRA installation currently running. Please ensure that no other instance of this JIRA installation is running and then remove the following lock file(s) and restart JIRA: /x1/opt/tomcat-5.5/tomcat-jira/temp/lucene-3bdc6a510f5445825cba29b83a5bb859- commit.lock Once restarted you will need to reindex your data to ensure that indexes are up to date. From: George Harley (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, April 10, 2006 3:45 PM To: [EMAIL PROTECTED] Subject: [jira] Resolved: (HARMONY-289) [classlib][luni-kernel] Update StackTraceElement for Java 5 Issue (View Online) Key: HARMONY-289 Type: Improvement Status: Resolved Priority: Minor Resolution: Fixed Assignee: George Harley Reporter: Nathan Beyer Operations View all View comments View change history [classlib][luni-kernel] Update StackTraceElement for Java 5 Updated: 10/Apr/06 09:43 PM Created: 01/Apr/06 11:21 PM The following issue has been resolved as FIXED. Author: George Harley Date: 10/Apr/06 09:43 PM Comment: Hi Nathan, Changes applied in revision 393055. Thanks for this patch, please could you check that it has been applied as expected. Best regards, George Project: Harmony Components: Classlib Attachments: StackTraceElement_java_5_patch.txt Description As per the Java 5 spec [1] the StackTraceElement class now has a public constructor. Additionally, I've cleaned up the javadoc a bit and converted the 'toString' method to use StringBuilder instead of StringBuffer. [1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StackTraceElement.html This message was automatically generated by Atlassian JIRA Enterprise Edition, Version: 3.5.3-ASF-#135 - Bug/feature request If you think it was sent incorrectly contact one of this server's administrators. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long,long testcase name...
2006/4/11, Paulex Yang <[EMAIL PROTECTED]>: > > > LvJimmy，Jing wrote: > > Hi all: > > > > Following our testcase naming convention, I've find a name as: (hope > it > > won't break your screen :)) > > public void > > > test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType() > > > Well > I don't mind if you missed one string or sobecause I cannot read > it > > which is the testcase for > > java.net.Authenticator.requestPasswordAuthentication( > > String rHost, InetAddress rAddr, int rPort, String > rProtocol, > > String rPrompt, String rScheme, URL rURL, > > Authenticator.RequestorType reqType); > > and the class has another two method named > requestPasswordAuthentication, > > and only this method take URL and RequestorType as its parameters. > > The name is somehow too long to see and read, and I guess we can > find a > > shorter one for it, > > > In fact I also don't know why it is so necessary to include package name > in the test method name. The class name only should be enough in > 99%(even more I guess) cases. I think so. And in this case, even the method name withour package name seems a bit too long. > e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and > > RequestorType can identify the exactly > > method to test. Or a adjusted naming convention shall be take. Any > opinions? > > > > > I'm not sure if this is a good idea, how about if a new method > requestPasswordAuthentication(URL, Authenticator) is introduced in Java > 6? (yes, yes, I know, it's just an assumption.) I see. However, we shall find a way out... > -- > > > > Best Regards! > > > > Jimmy, Jing Lv > > China Software Development Lab, IBM > > > > > > > -- > Paulex Yang > China Software Development Lab > IBM > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: matching reference implementation exception behaviour
It's not too late to think about it once again and probably revisit the decision. As I understand goal #1 is to meet needs of as many potential users as we can and decision to be spec incompatible in favor of new hot RI version might be not the best one. Thanks, Mikhail 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > I think that people will steadily move up in versions, and maybe most > importantly, we *are* trying to build Java SE 5, not J2SE 1.4... > > geir > > > Mikhail Loenko wrote: > > BTW, when we were deciding that we follow RI rather then the spec, we > > cared about breaking existing implementations. But if RI changed its > > behavior > > from being compatible to the spec in 1.4 to being incompatible in 1.5 then > > do > > we believe that existing applications more likely stick to the latest > > (1.5) version? > > > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? > > > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266) > > java.security.Signature.getInstance(String,Provider) should match 5.0 > > reference implementations behaviour" mail thread. > > > > Thanks, > > Mikhail > > > > > > 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > >> > >> Paulex Yang wrote: > >>> Mark > >>> > >>> You just point out a serious issue ;-) . The RI is just a concept, in > >>> fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, > >>> Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and > >>> on different platforms(win32, linux32, still even more in future)...In > >>> fact sometimes they have different behavior themselves, it is very > >>> reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different > >>> exceptions thrown(more reasonable IAE instead of NPE, for example), or > >>> more seriously, different results returned... Samples are available upon > >>> request:). > >> Actually, there only is one RI for any given spec, and in this case, I > >> guess we judge it to be the latest version of a spec that comes from > >> Sun? (The question isn't if it comes from Sun - as the spec lead, they > >> supply the RI - but rather what version...) > >> > >> geir > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long,long testcase name...
testRequestPasswordAuthentication1() I mean, why do we want to embed all that crap in the testcase name? Who cares? The only person that will care is someone fixing when a testcase breaks, and they'll read the code... geir LvJimmy，Jing wrote: Hi all: Following our testcase naming convention, I've find a name as: (hope it won't break your screen :)) public void test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType() which is the testcase for java.net.Authenticator.requestPasswordAuthentication( String rHost, InetAddress rAddr, int rPort, String rProtocol, String rPrompt, String rScheme, URL rURL, Authenticator.RequestorType reqType); and the class has another two method named requestPasswordAuthentication, and only this method take URL and RequestorType as its parameters. The name is somehow too long to see and read, and I guess we can find a shorter one for it, e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and RequestorType can identify the exactly method to test. Or a adjusted naming convention shall be take. Any opinions? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
LvJimmy，Jing wrote: > Hi： > > I think we never dicide that we should follow RI rather than the spec. > The spec is the first principle we should follow. However if the spec does > not tell us the detail of an action, then it's the time to follow RI. > That is true that RI changes from time to time in every release. :) The issue is that we definitely want to have programs that run on Harmony to behave like programs that run on the RI. Why? Because at first, no one will believe we're right. When people ask about a problem, they won't accept the answer that "well, that's how the spec says..." if they can get Sun, IBM and BEA's implementations to do something different. Of course, once we achieve world dominance, we can revisit this :) geir > > 2006/4/11, Mikhail Loenko <[EMAIL PROTECTED]>: >> BTW, when we were deciding that we follow RI rather then the spec, we >> cared about breaking existing implementations. But if RI changed its >> behavior >> from being compatible to the spec in 1.4 to being incompatible in 1.5 then >> do >> we believe that existing applications more likely stick to the latest >> (1.5) version? >> >> Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? >> >> Example JIRA-266 and "Re: [jira] Created: (HARMONY-266) >> java.security.Signature.getInstance(String,Provider) should match 5.0 >> reference implementations behaviour" mail thread. >> >> Thanks, >> Mikhail >> >> > > Best Regards! > > Jimmy, Jing Lv > China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
I think that people will steadily move up in versions, and maybe most importantly, we *are* trying to build Java SE 5, not J2SE 1.4... geir Mikhail Loenko wrote: BTW, when we were deciding that we follow RI rather then the spec, we cared about breaking existing implementations. But if RI changed its behavior from being compatible to the spec in 1.4 to being incompatible in 1.5 then do we believe that existing applications more likely stick to the latest (1.5) version? Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? Example JIRA-266 and "Re: [jira] Created: (HARMONY-266) java.security.Signature.getInstance(String,Provider) should match 5.0 reference implementations behaviour" mail thread. Thanks, Mikhail 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: Paulex Yang wrote: Mark You just point out a serious issue ;-) . The RI is just a concept, in fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and on different platforms(win32, linux32, still even more in future)...In fact sometimes they have different behavior themselves, it is very reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different exceptions thrown(more reasonable IAE instead of NPE, for example), or more seriously, different results returned... Samples are available upon request:). Actually, there only is one RI for any given spec, and in this case, I guess we judge it to be the latest version of a spec that comes from Sun? (The question isn't if it comes from Sun - as the spec lead, they supply the RI - but rather what version...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long,long testcase name...
LvJimmy，Jing wrote: Hi all: Following our testcase naming convention, I've find a name as: (hope it won't break your screen :)) public void test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType() Well I don't mind if you missed one string or sobecause I cannot read it which is the testcase for java.net.Authenticator.requestPasswordAuthentication( String rHost, InetAddress rAddr, int rPort, String rProtocol, String rPrompt, String rScheme, URL rURL, Authenticator.RequestorType reqType); and the class has another two method named requestPasswordAuthentication, and only this method take URL and RequestorType as its parameters. The name is somehow too long to see and read, and I guess we can find a shorter one for it, In fact I also don't know why it is so necessary to include package name in the test method name. The class name only should be enough in 99%(even more I guess) cases. e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and RequestorType can identify the exactly method to test. Or a adjusted naming convention shall be take. Any opinions? I'm not sure if this is a good idea, how about if a new method requestPasswordAuthentication(URL, Authenticator) is introduced in Java 6? (yes, yes, I know, it's just an assumption.) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
2006/4/11, Paulex Yang <[EMAIL PROTECTED]>: > > Geir Magnusson Jr wrote: > > > > > > Paulex Yang wrote: > >> Mark > >> > >> You just point out a serious issue ;-) . The RI is just a concept, in > >> fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, > >> Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), > >> and on different platforms(win32, linux32, still even more in > >> future)...In fact sometimes they have different behavior themselves, > >> it is very reasonable that 1.5.06 fix some bugs of 1.5.0, so that > >> some different exceptions thrown(more reasonable IAE instead of NPE, > >> for example), or more seriously, different results returned... > >> Samples are available upon request:). > > > > Actually, there only is one RI for any given spec, and in this case, I > > guess we judge it to be the latest version of a spec that comes from > > Sun? (The question isn't if it comes from Sun - as the spec lead, they > > supply the RI - but rather what version...) > Yes, I agree with you, there should be only one RI. And I suggest to > stick with Sun's 1.5.0 with latest revision (i.e. 1.5.0_06 by now). Agree:) > > > geir > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Paulex Yang > China Software Development Lab > IBM > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Long,long testcase name...
Hi all: Following our testcase naming convention, I've find a name as: (hope it won't break your screen :)) public void test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType() which is the testcase for java.net.Authenticator.requestPasswordAuthentication( String rHost, InetAddress rAddr, int rPort, String rProtocol, String rPrompt, String rScheme, URL rURL, Authenticator.RequestorType reqType); and the class has another two method named requestPasswordAuthentication, and only this method take URL and RequestorType as its parameters. The name is somehow too long to see and read, and I guess we can find a shorter one for it, e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and RequestorType can identify the exactly method to test. Or a adjusted naming convention shall be take. Any opinions? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: matching reference implementation exception behaviour
Geir Magnusson Jr wrote: Paulex Yang wrote: Mark You just point out a serious issue ;-) . The RI is just a concept, in fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and on different platforms(win32, linux32, still even more in future)...In fact sometimes they have different behavior themselves, it is very reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different exceptions thrown(more reasonable IAE instead of NPE, for example), or more seriously, different results returned... Samples are available upon request:). Actually, there only is one RI for any given spec, and in this case, I guess we judge it to be the latest version of a spec that comes from Sun? (The question isn't if it comes from Sun - as the spec lead, they supply the RI - but rather what version...) Yes, I agree with you, there should be only one RI. And I suggest to stick with Sun's 1.5.0 with latest revision (i.e. 1.5.0_06 by now). geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
Hi： I think we never dicide that we should follow RI rather than the spec. The spec is the first principle we should follow. However if the spec does not tell us the detail of an action, then it's the time to follow RI. That is true that RI changes from time to time in every release. :) 2006/4/11, Mikhail Loenko <[EMAIL PROTECTED]>: > > BTW, when we were deciding that we follow RI rather then the spec, we > cared about breaking existing implementations. But if RI changed its > behavior > from being compatible to the spec in 1.4 to being incompatible in 1.5 then > do > we believe that existing applications more likely stick to the latest > (1.5) version? > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266) > java.security.Signature.getInstance(String,Provider) should match 5.0 > reference implementations behaviour" mail thread. > > Thanks, > Mikhail > > Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: matching reference implementation exception behaviour
BTW, when we were deciding that we follow RI rather then the spec, we cared about breaking existing implementations. But if RI changed its behavior from being compatible to the spec in 1.4 to being incompatible in 1.5 then do we believe that existing applications more likely stick to the latest (1.5) version? Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? Example JIRA-266 and "Re: [jira] Created: (HARMONY-266) java.security.Signature.getInstance(String,Provider) should match 5.0 reference implementations behaviour" mail thread. Thanks, Mikhail 2006/4/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > > Paulex Yang wrote: > > Mark > > > > You just point out a serious issue ;-) . The RI is just a concept, in > > fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, > > Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and > > on different platforms(win32, linux32, still even more in future)...In > > fact sometimes they have different behavior themselves, it is very > > reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different > > exceptions thrown(more reasonable IAE instead of NPE, for example), or > > more seriously, different results returned... Samples are available upon > > request:). > > Actually, there only is one RI for any given spec, and in this case, I > guess we judge it to be the latest version of a spec that comes from > Sun? (The question isn't if it comes from Sun - as the spec lead, they > supply the RI - but rather what version...) > > geir > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Der Plan
I would rather see a harmony-wiki mailing list for those interested in that area. There is already too much coming in the harmony-commits list. Dan Lydick > [Original Message] > From: Geir Magnusson Jr <[EMAIL PROTECTED]> > To: > Date: 4/10/06 7:24:25 PM > Subject: Re: [classlib] Der Plan > > > > Nathan Beyer wrote: > > I've found the Wiki to be much more useful since I subscribed to the change > > notifications. I get an email for all updates to the Wiki in a nice > > pseudo-diff format. Perhaps the 'commits' mailing list could be added to > > this notification mechanism. > > I don't understand what you are asking for... > > geir > ... snip ... - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug for bug compatibility (was Re: [jira] Closed: (HARMONY-311) java.io.FileInputStream.skip(long n) returns incorrect value)
George Harley wrote:
Hi,
Would it be possible to have a resolution option of "Matching RI Bug"
(or similar) when closing a JIRA issue with the resolution that we are
matching an apparent RI bug ? Hopefully, it should make it easier to
find all such issues in the future.
Well one bug in JIRA's design is that resolutions are global. So we
could add it, but then every other project at Apache gets that on the
resolution pick-list.
The other problem I see is that it's orthogonal information, of sorts...
I mean, what if someone was reporting a bug, and we decide to call it
'matching'? or if you make a change to align w/ the RI, that's
'matching' too, but the diff is that one is "won't fix" and one is "fixed".
How about re-visiting the JIRA category idea - we change the current
"Non-bug differences from RI" category to also include "Matching Bugs"
(which is "difference from spec" among other things..."
So maybe "differences from RI or spec" category? or "RI and spec diffs
and bugs"?
geir
Best regards,
George
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-311?page=all ]
George Harley closed HARMONY-311:
-
Resolution: Won't Fix
This is a case of Harmony matching the behaviour of an apparent RI bug.
java.io.FileInputStream.skip(long n) returns incorrect value
Key: HARMONY-311
URL: http://issues.apache.org/jira/browse/HARMONY-311
Project: Harmony
Type: Bug
Components: Classlib
Reporter: nikolay
Assignee: George Harley
Attachments: patch.txt
According to J2SE 1.4.2, 1.5.0 specifications for
java.io.FileInputStream.skip(long n)
the method should return the actual number of bytes skipped.
The test listed below shows that the method returns incorrect value
if parameter > number of bytes in file.
import java.io.FileInputStream; import java.io.IOException; import
java.io.File; public class Test{ public static void main(String[]
args) { FileInputStream toRet = null; try {
File file = new File("FileInStream.tmp");
file.createNewFile(); toRet = new FileInputStream(file);
System.out.println("skipped = " + toRet.skip(100));
} catch (IOException e) { e.printStackTrace();
} }} Output RI: java.exe -showversion Test java
version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32,
Native Threads, GC strategy: parallel)
skipped = 0
Output harmony:
java -showversion Test java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its
licensors, as applicable.
skipped = 100
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Mark Hindess wrote: Mikhail, Thanks for the pointers. I dug back in the mail archives. Geir wrote: I think of it still as "live material" in our tree, but I don't feel too strongly about this. If we keep it there, we should set a policy to expire it out of there at some point. I'd suggest that the two files that you mention which are "never used" probably don't qualify as "live material". ;-) Agreed. So, now my question is when is it going to be expired? i'd suggest that anything moved to archive should have an expiry date set in a file or svn property when it is moved so it is clear when it will be removed. Personally, I still think having paths archive/modules and modules/archive is confusing. 99% of our users will never use the extra >1.5M overhead of "svn checkout" that 'archive' creates. The 1% who might want it can easily find it in svn. The only reason we stuck security in an archive/modules was because we wanted an easy way to be copying things that we found useful to the live version - mainly javadoc and such. We were afraid that if we deleted it, it would be a pain to do that. My real fear is that we'd collectively forget. Maybe I'm just projecting :) So how about this - why don't we put a text file somewhere (in SVN!) in which we "log" major things that we delete, and put the svn rev # of where it was live. That way we don't forget what we've tossed, and also make it easy to get something back, w/o having to play "wack-a-mole" with the version numbers... Also, if it's small stuff, I assume that there's no reason to log unless someone squawks...? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
Paulex Yang wrote: Mark You just point out a serious issue ;-) . The RI is just a concept, in fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and on different platforms(win32, linux32, still even more in future)...In fact sometimes they have different behavior themselves, it is very reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different exceptions thrown(more reasonable IAE instead of NPE, for example), or more seriously, different results returned... Samples are available upon request:). Actually, there only is one RI for any given spec, and in this case, I guess we judge it to be the latest version of a spec that comes from Sun? (The question isn't if it comes from Sun - as the spec lead, they supply the RI - but rather what version...) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] ant platform property definitions
not all - just the ones from IBM, or IBM employees?
Even if not...
Is there any harm in this case in expanding it out?
geir
Mark Hindess wrote:
It's has been in our ant builds for some time - in all the
modules/*/make/build.xml files for instance. Does that mean we should
continue to use it?
-Mark.
On 4/3/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Along with everything everyone else has said...
Yes, please, lets standardize. Get rid of caps as suggested and please,
lets not use "hy" and use "harmony". It isn't used in such high volume
that skipping the extra 5 characters isn't that big of a benefit, and it
makes things easy to read.
It is used in high volume in our native code.
I'm not suggesting you change it, just not perpetuate the mistake ;)
into our ant builds.
geir
Regards,
Tim
Mark Hindess wrote:
Currently a number of the classlib ant files "normalize" operating
system and architecture names. Unfortunately they don't
really normalize them in the same way. ;-)
For instance, native-src/build.xml sets target.platform to
"linux.IA32" and modules/security/make/build.xml sets "platform.name"
to "lnx".
I think we should decide on a common normalized form and have a single
common ant file to import that defines them. I'd already started to
create one (as I was about to add platform defines in yet another ant
file) but then I realised there wasn't any consensus about what the
normalized form should be.
I think having a mapping (from os.arch to hy.arch and os.name and
hy.os) is useful because it reduces the coupling between Harmony and
ant, and because it enables use to perform sensible normalizations.
But, I don't think we should make the mapping unnecessarily
complicated. I think we should keep the normal form as close as
possible to the standard ant defines of os.name and os.arch.
So, ${hy.os} would be ${os.name} - with values like 'Linux',
'Solaris', etc. - except for Windows where we would normalize to
"Windows". Similarly, ${hy.arch} would be ${os.arch} - with values
like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for
exceptions to the ${hy.arch} at the moment, but we should create it
and use it consistently.
I hate "hy" with a real passion. Can we please use "harmony"? That's
the project name. IBM decided to use 'hy' as a prefix because it was
easier to type (reasonable, I guess...) but I think that it's not so bad
to use the full "harmony"
This would lead to "hy.platform" being defined as:
Linux.x86
Windows.x86
We could add exceptions - for instance, to make 'Linux' lower case -
but then we'd only need to add exceptions later for 'Solaris', 'Aix',
etc. I think we'd be better to avoid this and only have exceptions
where:
* the name contains characters that can't be used in file names, or
* there is a clear reason to normalize - e.g. "Windows XP", etc.
So, what do people think? Is there a compelling reason to maintain
the differences we have today - e.g. Linux in lowercase, 'ipf' rather
than 'ia64' - or can we just stick with the ant defines?
We also have many definitions of properties like "is.win",
"is.windows", and "if.win". I'd prefer to stick to forms starting
with 'is.' since I think they read better when used, e.g.
...
and the item following the 'is.' prefix should be the all lowercase
(in line with typical conventions for ant properties) but otherwise
match the ${hy.os} and ${hy.arch} defines above.
Assuming we reach a consensus, I think directories should be renamed
to match the agreed definitions. We might as well change 'win.IA32'
to 'Windows/x86' - or whatever we decide on - while we are doing this.
I'll be happy to do the work to create the common ant file and to
submit a JIRA with any layout changes (I think there will be some
regardless of what decision is reach because of current differences).
Regards,
Mark.
--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Der Plan
Nathan Beyer wrote: I've found the Wiki to be much more useful since I subscribed to the change notifications. I get an email for all updates to the Wiki in a nice pseudo-diff format. Perhaps the 'commits' mailing list could be added to this notification mechanism. I don't understand what you are asking for... geir -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 9:37 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Der Plan One more thing - keeping a record on a wiki is good, but I'd like to see people talking about what they are doing on the mail list, and then noting it on the Wiki Tim Ellison wrote: Looking at our wiki pages[1], people have written a description of the _current_ state of play for a number of class library modules. However, with our new committers eager to get going, a growing number of contributors, and people lurking and wondering where they can help, may I suggest that we try and form a plan for what we want to do over the next, say, six weeks; over and above the usual bug fixing tasks. Like all good plans we'll probably get it wrong in a number of ways ;-) but the idea is that we all agree upon a few themes and goals to ensure we are all working together on subgoals of the project. At regular intervals we should come together with a coherent working system, rather than always having something broken! I expect that some of the themes/goals will be relevant across the whole classlib, and others will be module-specific. I've created a wiki page [2] with a suggestion of how it may look -- but the content comes from everyone so it's not complete. Thoughts? Tim [1] http://wiki.apache.org/harmony/ClassLibrary [2] http://wiki.apache.org/harmony/ClassLibraryPlan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Switching to a 5.0 compiler
Tim Ellison wrote: Magnusson, Geir wrote: Why? We have Sun and Eclipse with a wrapper-thingy, right? Not yet we don't -- if people are comfortable with the idea then let me have a play to see what is required and get back to the list. Ok - since the current version of eclipse works the way we want, we can use that for now anyway? I'm much happier working with the eclipse compiler, but am just worried about not being able to switch in the event that something outside of our control changes... geir In the meantime we /could/ switch today to use Sun's compiler exclusively, as a temporary measure before the temporary Sun & Eclipse compilation measure before full 1.5 support :-0 Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Switching to a 5.0 compiler
Etienne Gagnon wrote: Tim Ellison wrote: my point is that we could hack the Eclipse batch compiler to make it do something it is not meant to do (source=1.5 target=1.4). If we get burnt then we'll have nobody to complain to ;-) ... As it stands we have no option to use the Eclipse batch compiler (without tweaking it and therefore I assume bringing a modified JAR into our SVN for people to use etc. -- yuk!) Wouldn't the following be sufficient: 1- Put the (probably very small) patch in our repository. 2- Update make/depends.xml to fetch eclipse sources. 3- Update the build procedures to apply the patch and build/rebuild eclipse when necessary. If we can avoid having to get the full code and rebuild, that might be nicer. I figured that we could simply write our own code that calls the eclipse internals, but since I don't actually know what needs to change, I'll shut up now... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vmi] JNI spec interpretation?
Tim Ellison wrote: The IBM VME comes with a check utility that complains about bad practices detected in JNI code: Usage: -Xcheck:jni:[option[,option[,...]]] allcheck application and system classes verbosetrace certain JNI functions and activities trace trace all JNI functions nobounds don't perform bounds checking on strings and arrays nonfatal don't exit when errors are detected nowarn don't display warnings noadvice don't display advice novalist don't check for va_list reuse pedantic perform more thorough, but slower checks help print this screen Don't run it on the Harmony class libraries unless you have a strong stomach ;-) This is very cool. I wonder if after some time when we get this under control, we should add to the standard test bed... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.reflect
Hey, Dalibor... When will Kaffe also work with the Harmony classlib? :) geir Dalibor Topic wrote: On Tue, Apr 04, 2006 at 12:46:29AM -0400, Etienne Gagnon wrote: Tim Ellison wrote: Gary Clark wrote: 3) Do any of the current VMs support the 1.5 features? Off the top of my head I don't recall if anything changed within the VM to support them. I'll let Etienne, Archie, Dalibor, et al describe their status wrt Java 1.5 support. The IBM VM can switch to 1.5 support trivially but we are limiting it to 1.4 until there is reasonable coverage in the open source VMs. We'll have 1.5 support out of the box for the next Kaffe release. Guilhem has checked in the code, so I just need to find some time to make the build system work with a generified glibj.zip, and see if we are missing some changes from the GNU Classpath 1.5 VM interface. We need it for ant on the gump, since it's stuck trying to build code for a 1.5 VM without having some of the classes & enums. There is a bug report for it on the ant bugzilla, but it gets boring to have to patch ant to work around the VM version detection code. It is simpler to just give it what it wants, a 1.5-ish VM. ;) In other words, Gump is great for discovering that sort of issues. cheers, dalibor topic One of my former students succeeded to run SableVM with the generic branch of GNU Classpath over the holidays, by only implementing one or two additional native methods in SableVM (the code should be in his sandbox somewhere). As far as I know, the type erasure stuff was chosen by Sun as to minimize the impact of generics on the virtual machine. So, I don't expect the switch to 1.5 to be something big. But, first, it would be nice to get SableVM to work with current Harmony... So, I'm working on that for the time being. Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] running the tests
That's actually a really funny idea in this age of 'value-add' bundling... "language compiler. Now, with IDE!" I think it's even more remarkable that we don't even blink when discussing 120MB downloads geir Tim Ellison wrote: It is! complete with 120Mb of IDE add-on free! (I know -- I'm only joking) Tim Geir Magnusson Jr wrote: Can we badger the eclipse people to make it avail as a download ? Tim Ellison wrote: That looks like the JUnit Ant task is missing -- you still need to put JUnit into ant/lib etc. to use and I'd encourage people to put the Eclipse compiler adapter in there too so we can use that. Regards, Tim Mikhail Loenko wrote: Not only the document. Now build fails without e.g. junit in classpath: BUILD FAILED H:\make\build-test.xml:58: The following error occurred while executing this line: H:\modules\luni\make\build.xml:123: The following error occurred while executing this line: H:\modules\luni\make\common\build.xml:77: Could not create task or type of type: junit. Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
man... take a few days off...
sheehs... - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rmi] getting 1.4 bytecode
Oliver Deakin wrote: Daniel Gandara wrote: Hi,As discussed with Oliver, I built the rmi code with the -target jsr14 option and I got a 1.4 bytecode for the package.I run our test suit against the package and it seems to work ok. That's great news! This is a sum up of the experience: 1) -target jsr14 option only worked with Sun's compiler, Icould not make it work on Eclipse... Tim described in [1] that the Eclipse batch compiler unfortunately does not support this kind of 1.5 to 1.4 compilation. There has been further discussion in that thread as to which solution is best for us - Sun compiler using -target jsr14, and/or Eclipse compiler at 1.5 level and then use a tool called Retroweaver to alter the bytecodes to work on 1.4. yes I read the thread, I believe the goal is to find the way to automate the use of Retroweaver within Eclipse... anyway I see no big deal using the compiler with options to get 1.4 bytecode since this should be done for a short time while harmony gets 1.5 2) I had to make changes to the code, basically I had tochange enums and change/remove java.util.concurrentclasses we use (ConcurrentHashMap andThreadPoolExecutor) I got some enum examples working by just adding a basic Enumeration class to the java.lang package in luni, but I only trialled fairly simple cases. What kind of alterations did you need to make? It will be interesting to know some of the limits of this compiler option. From my POV the limits of using this compiler option is basically to classes or methods which do not exist on 1.4, and cases like enums which are also new on 5.0. One problem we did found is getting errors at runtime, since the code compiles ok, but at run time there is a call to a method that is not on 1.4, then you and had to go back and change to give 1.4 compatibility. Here is a complete list of the changes made to the code: a) Changing enum with classes, there was just one enum, and was changed by classes with static attributes (we had enum HttpHeaders and we changed it for class HttpHeaders holding a HashSet) b) Call to method Timer(String, boolean) was replaced by Timer(boolean) c) Call to method Timer.purge() was commented d) Call to method System.currentTimeMillis() was replaced by new Long(System.currentTimeMillis()) e) ThreadPoolExectutor was removed, so we always launch new threads f) ConcurrentHashMap was replaced by a HashTable g) Call to method Thread.getId() was replaced by Thread.hashcode() note: there is obviously a performance penalty due to 2). The question I have now is if I should send this modified code to be used in Harmony during this transitional phase or not. What do you think? I think it's probably a good thing to get the code out there so we can start to use it, even if this means making some temporary modifications. I agree with you, I believe I willl upload the 1.4 jar to the JIRA HARMONY-211 issue so the java.rmi package can go through the process of acceptance and be used. Regards, Daniel Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] I'll be waitting for comments, Daniel - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs
Weldon Washburn wrote: I have zero problems if you put specific directories contained in JIRA harmony-318 below harmony/enhanced/gnuclasspathadapter. The specific directories are: - kernel - luni - nio OK, I can do it as soon as someone tells me it's OK to commit. Is Geir out of town or something?? I have more mods that I would like to make to this code. How do I do this once it is svn? We'll have to get you SVN commit access. Geir should be able to tell you what's required. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs
Archie, I have zero problems if you put specific directories contained in JIRA harmony-318 below harmony/enhanced/gnuclasspathadapter. The specific directories are: - kernel - luni - nio I have more mods that I would like to make to this code. How do I do this once it is svn? Thanks Weldon On 4/9/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/gnuclasspathadapter/ > > Any place in SVN is fine with me. Let's just get it checked in somewhere > so it can get worked on... so, who'll commit it? > > -Archie > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version Conflict with bcel?
On 4/10/06 Stepan Mishura wrote:
On 4/9/06, Soeren Strassfeld wrote:
>
> Hi Stepan,
>
> first, I did a simple xsl Transformation:
>
> TransformerFactory f = TransformerFactory.newInstance();
> Transformer t = f.newTransformer(new StreamSource(new
> FileInputStream("foo.xsl")));
> t.transform(new StreamSource(new FileInputStream("foo.xml")),new
> StreamResult(System.out));
>
> (foo.xml and foo.xsl are really simple, actually taken from the Xalan
> Examples)
>
> This works fine on both, Sun jdk1.5 and Harmony.
> When running with -verbose, I noticed that harmony uses
> org.apache.xalan.processor.TransformerFactoryImpl
> while Sun uses
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl
> as default javax.xml.transform.TransformerFactory
>
> Actually all Apache classes within the Sun JDK seem
> to be repackaged to com.sun.org.apache..internal.*
>
> After that test, I forced harmony to use the compiling
> TransformerFactory with
> System.setProperty("javax.xml.transform.TransformerFactory",
> "org.apache.xalan.xsltc.trax.TransformerFactoryImpl");
>
> (Does not work on sun jdk1.5 because of the repackaging)
>
> Now the bcel classes are loaded as shown in the harmony -verbose
> output. XSL Transformation still works fine on harmony.
>
> When I now run the test with
> -Xbootclasspath/p:bcel-5.2rc1.jar
> I get a
> java.lang.NullPointerException
> at
> org.apache.bcel.util.InstructionFinder.search(InstructionFinder.java:226)
> at
> org.apache.bcel.util.InstructionFinder.search(InstructionFinder.java:250)
> at
> org.apache.xalan.xsltc.compiler.Mode.peepHoleOptimization(Mode.java:1442)
> at
> org.apache.xalan.xsltc.compiler.Mode.compileApplyTemplates(Mode.java:1056)
> at
> org.apache.xalan.xsltc.compiler.Stylesheet.compileModes(Stylesheet.java
> :580)
> at
> org.apache.xalan.xsltc.compiler.Stylesheet.translate(Stylesheet.java:695)
> at org.apache.xalan.xsltc.compiler.XSLTC.compile(XSLTC.java:335)
> at org.apache.xalan.xsltc.compiler.XSLTC.compile(XSLTC.java:410)
> at
> org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTemplates(
> TransformerFactoryImpl.java:720)
> at
> org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTransformer(
> TransformerFactoryImpl.java:548)
> at Main.main(Main.java:14)
>
> The harmony-bcel InstructionFinder class uses jakarta.regexp, while
> the 5.2rc1 InstructionFinder uses java.util.regexp, which could be
> the Reason for the NullPointerException.
Right. The current implementation of java.util.regexp package contains
stubs. I think the problem will be resolved when stub implementation will be
replaced with implementation from HARMONY-39 contribution.
Hi,
you´re right, it might work with harmony-39, but the result is more or
less random, as all xalan
tests ran against another bcel version (The pattern is actually passed
from xalan to bcel, so
jakarta.regexp and java.util.regexp would have to be compatible in their
pattern syntax).
And imagine, bcel decides to change it´s api, you would get a
NoSuchMethodError with or without
regexp package.
Anyway, let´s don´t stay with this specific example, I guess similar
cases could be created with other
external libraries:
The more I think about it, I think that harmony (like sun) should change
packages for all external classes,
so only API classes + org.apache.harmony classes are on the bootclasspath.
There are Applications, which depend on exactly Version x.y.z of Library
whatever (think of all those
jdk1.3 Apps, which ship their own Version of xalan/xerces), and you
can´t force
them to upgrade/downgrade to run on harmony, because harmony uses
another Version internally.
Thanks,
Soeren
Thanks,
Stepan.
Anyway, I think the interesting part of this test is, that sun repackages
> external packages to com.sun. packages to avoid Version conflicts.
> Although I don�t like this Idea, as this is some kind of "fork" to me,
> I don�t see any better solution for this kind of Problem!?
>
> Thanks,
> Soeren
>
>
> Stepan Mishura schrieb:
> > On 4/8/06, Soeren Strassfeld wrote:
> >
> >> Hi List,
> >>
> >> the latest Harmony snapshot ships a version of xalan.jar, which seems
> to
> >> contains
> >> an old version of Jakarta bcel.
> >> When I try to run my bcel based App, I get a NoSuchMethodError:
> >>
> >>
>
org/apache/bcel/Repository.lookupClass(Ljava/lang/Class;)Lorg/apache/bcel/classfile/JavaClass;
> >>
> >> I checked Repository.class within xalan.jar, and it doesen�t have this
> >> Method
> >> (I use bcel5.2rc1, but this Method is already present in 5.1).
> >>
> >> How can I tell Harmony to use my Version (-classpath bcel5.2rc1 does
> not
> >> work)
> >> of bcel?
> >>
> >
> >
> > Try option: -Xbootclasspath/p:
> >
> > Thanks,
> > Stepan.
> >
> > Regards,
> >
> >> Soeren
> >>
> >> --
> >>
> >> Soeren Strassfeld (nc-straszso at netcologne dot de)
> >>
> >>
> >>
> >> -
> >>
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
Mikhail, Thanks for the pointers. I dug back in the mail archives. Geir wrote: > I think of it still as "live material" in our tree, but I don't > feel too strongly about this. If we keep it there, we should set a > policy to expire it out of there at some point. I'd suggest that the two files that you mention which are "never used" probably don't qualify as "live material". ;-) So, now my question is when is it going to be expired? i'd suggest that anything moved to archive should have an expiry date set in a file or svn property when it is moved so it is clear when it will be removed. Personally, I still think having paths archive/modules and modules/archive is confusing. 99% of our users will never use the extra >1.5M overhead of "svn checkout" that 'archive' creates. The 1% who might want it can easily find it in svn. Regards, Mark. On 4/10/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > We have a precedent of archiving a duplicating functionality - IBM > security module > was moved to archive/modules/security > > It was discussed in threads > [classlib] security2 -> security > and > [classlib] security moved > > Thanks, > Mikhail > > 2006/4/10, Mark Hindess <[EMAIL PROTECTED]>: > > What is the archive tree for? Why not just remove them and let svn > > take care of "archiving" them? (This also means users don't have to > > check out unnecessary files.) > > > > -Mark. > > > > On 4/10/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > luni ASN1 De/Encoder is never used. > > > > > > luni Base64 decoder is faster vs. corresponding security class, but it has > > > a bug for which I do not see a quick fix: it does not support /n and > > > /r characters > > > in encoded form. Adding of that support would slow down luni > > > implementation. > > > > > > luni DefaultPolicy is currently never used. > > > > > > So I suggest moving luni classes to archive/modules. > > > > > > Comments? > > > > > > Thanks, > > > Mikhail > > > > > > > > > 2006/4/6, Mikhail Loenko <[EMAIL PROTECTED]>: > > > > We have pairs of implementations for the following functionality > > > > (modules luni and security): > > > > > > > > ASN1 De/Encoding > > > > Base64 De/Encoding > > > > DefaultPolicy > > > > > > > > I'm going to compare and choose one them but I'd appreciate if someone > > > > else would compare them too. > > > > > > > > Thanks, > > > > Mikhail > > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Mark Hindess <[EMAIL PROTECTED]> > > IBM Java Technology Centre, UK. > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-315) javax.crypto.Cipher.getInstance doesn't match RI exception behaviour.
Hmm... I agree that the behaviour is inconsistent. But I think
matching the RI behaviour is unlikely to inconvenience our users. So,
I'd still say we should match the behaviour of Sun's 5.0
implementation (which means we'll also match IBM's and BEA's).
Regards,
Mark.
On 4/10/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> On 4/10/06, Mark Hindess wrote:
> >
> > On 4/10/06, Stepan Mishura wrote:
> > > Hi Mark,
> > >
> > > Basing on the bug description I assume that RI checks provider parameter
> > > first.
> >
> > Yes.
> >
> > > In all your examples this parameter is invalid.
> >
> > Yes. (It was one of the test cases generated by my Perl script - that
> > I've nearly finished tidying up for contribution.)
> >
> > > The spec. for method javax.crypto.Cipher.getInstance(String
> > transformation,
> > > String provider)
> > > says:
> > > "Throws:
> > > NoSuchAlgorithmException - if transformation is null, empty, in an
> > > invalid format, or not available from the specified provider.
> > > NoSuchProviderException - if the specified provider has not been
> > > configured.
> > > NoSuchPaddingException - if transformation contains a padding scheme
> > > that is not available.
> > > IllegalArgumentException - if the provider is null."
> > >
> > > So IllegalArgumentException can be thrown only if the provider parameter
> > is
> > > null. But IMHO in case of empty string NoSuchProviderException should be
> > > thrown.
> > >
> > > What do you think?
> >
> > So we agree about fixing the two cases where provider is (String)null.
> > We just need to decide what to do about the other two where provider
> > is (String)"" ?
>
>
> Yes.
>
> I think we should match the RI behaviour. That means that even in the
> > two cases where provider is the empty string we should still throw an
> > IllegalArgumentException.
> >
> > I think the wording of the spec for the getInstance method that takes
> > a String provider is just vague because it was copied from the method
> > that takes a Provider object. I think the RI behaviour reflects the
> > intention of the spec even if the spec is unclear.
>
>
> The problem is that java.security.Security allows such provider name, for
> example, the following code works on RI:
>
> === SmallProvider.java =
> import java.security.Provider;
> public class SmallProvider extends Provider {
>
> public SmallProvider() {
> super("", // name
> 1.0, // version
> "SmallProvider" // info
> );
> }
> }
> === test.java ===
> import java.security.Security;
> public class test {
> public static void main(String[] args){
> Security.addProvider(new SmallProvider());
> System.out.println(Security.getProvider("").getInfo());
> }
> }
>
> If we will follow RI then it will be possible to access Cipher object via:
> Cipher.getInstance(, Security.getProvider(""));
>
> But impossible to do the same via: Cipher.getInstance(,
> "");
>
> Thanks,
> Stepan.
>
> Regards,
> > Mark.
> >
> > > Thanks,
> > > Stepan
> > >
> > > >From: Mark Hindess (JIRA)
> > > >Sent: Friday, April 07, 2006 1:31 AM
> > > >To: [EMAIL PROTECTED]
> > > >Subject: [jira] Created: (HARMONY-315) javax.crypto.Cipher.getInstance
> > > >doesn't match RI exception behaviour.
> > > >
> > > >javax.crypto.Cipher.getInstance doesn't match RI exception behaviour.
> > > >-
> > > >
> > > > Key: HARMONY-315
> > > > URL: http://issues.apache.org/jira/browse/HARMONY-315
> > > > Project: Harmony
> > > >Type: Bug
> > > >
> > > > Components: Classlib
> > > >Reporter: Mark Hindess
> > > >Priority: Trivial
> > > >
> > > >
> > > >javax.crypto.getInstance methods doesn't match reference behaviour. It
> > > >throws NoSuchProvideExceptions when it should be throwing
> > > >IllegalArgumentExceptions. See log below for details.
> > > >
> > > >RI is Sun Microsystems Inc. 1.5.0_06
> > > >Test is harmony classlib
> > > >
> > > >javax.crypto.Cipher.getInstance("",""):
> > > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > > Test throws java.security.NoSuchProviderException: Provider is not
> > > >available
> > > >
> > > >javax.crypto.Cipher.getInstance("",(java.lang.String)null):
> > > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > > Test throws java.security.NoSuchProviderException: Provider null is
> > not
> > > >available
> > > >
> > > >javax.crypto.Cipher.getInstance((java.lang.String)null,""):
> > > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > > Test throws java.security.NoSuchProviderException: Provider is not
> > > >available
> > > >
> > > >javax.crypto.Cipher.getInstance((java.lang.String)null,(
> > java.lang.String)nu
> > > >ll):
> > > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > > Test throws java.security.NoSuchP
Re: [jira] Assigned: (HARMONY-221) regex need moving from modules/regex-beans-math to modules/regex
On Wed, 25 Jan 2006 12:26:18 GMT, Tim Ellison wrote: > > Geir, I assume you don't mind me stealing JIRA issues from you ;-) then, on Thu, 26 Jan 2006 10:49:28 GMT, Geir Magnusson Jr wrote: > > Swipe away. It should be marked as "started" if actual work is > being done. I would have taken this to mean that any committer could "swipe" a JIRA that wasn't marked with the status "In Progress" or with an obvious comment indicating some reason for delay? Of course, asking is probably the polite thing to do but I was just curious what the accepted practice was. Regards, -Mark. On 4/10/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > Geir, > > Would you mind reassigning it to me? > > Thanks, > Stepan. > > >From: Geir Magnusson Jr (JIRA) [mailto:[EMAIL PROTECTED] > > >Sent: Tuesday, March 28, 2006 4:25 PM > > >To: [EMAIL PROTECTED] > > >Subject: [jira] Assigned: (HARMONY-221) regex need moving from > > >modules/regex-beans-math to modules/regex > > > > > > [ http://issues.apache.org/jira/browse/HARMONY-221?page=all ] > > > > > >Geir Magnusson Jr reassigned HARMONY-221: > > >- > > > > > >Assign To: Geir Magnusson Jr > > > > > >> regex need moving from modules/regex-beans-math to modules/regex > > >> > > >> > > >> Key: HARMONY-221 > > >> URL: http://issues.apache.org/jira/browse/HARMONY-221 > > >> Project: Harmony > > >> Type: Improvement > > >> Components: Classlib > > >> Reporter: Mark Hindess > > >> Assignee: Geir Magnusson Jr > > >> Priority: Minor > > >> Attachments: 01.regex.moves.sh, 02.regex.moves.sh, 03.regex.moves.diff > > >> > > >> Integrating regex part of HARMONY-39 contribution. > > > > > >-- > > >This message is automatically generated by JIRA. > > >- > > >If you think it was sent incorrectly contact one of the administrators: > > > http://issues.apache.org/jira/secure/Administrators.jspa > > >- > > >For more information on JIRA, see: > > > http://www.atlassian.com/software/jira > > > -- > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Thanks, > Stepan Mishura > Intel Middleware Products Division > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug for bug compatibility (was Re: [jira] Closed: (HARMONY-311) java.io.FileInputStream.skip(long n) returns incorrect value)
Hi,
Would it be possible to have a resolution option of "Matching RI Bug"
(or similar) when closing a JIRA issue with the resolution that we are
matching an apparent RI bug ? Hopefully, it should make it easier to
find all such issues in the future.
Best regards,
George
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-311?page=all ]
George Harley closed HARMONY-311:
-
Resolution: Won't Fix
This is a case of Harmony matching the behaviour of an apparent RI bug.
java.io.FileInputStream.skip(long n) returns incorrect value
Key: HARMONY-311
URL: http://issues.apache.org/jira/browse/HARMONY-311
Project: Harmony
Type: Bug
Components: Classlib
Reporter: nikolay
Assignee: George Harley
Attachments: patch.txt
According to J2SE 1.4.2, 1.5.0 specifications for
java.io.FileInputStream.skip(long n)
the method should return the actual number of bytes skipped.
The test listed below shows that the method returns incorrect value if parameter
> number of bytes in file.
import java.io.FileInputStream;
import java.io.IOException;
import java.io.File;
public class Test{
public static void main(String[] args) {
FileInputStream toRet = null;
try {
File file = new File("FileInStream.tmp");
file.createNewFile();
toRet = new FileInputStream(file);
System.out.println("skipped = " + toRet.skip(100));
} catch (IOException e) {
e.printStackTrace();
}
}
}
Output RI:
java.exe -showversion Test
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32,
Native Threads, GC strategy: parallel)
skipped = 0
Output harmony:
java -showversion Test
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
skipped = 100
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
We have a precedent of archiving a duplicating functionality - IBM security module was moved to archive/modules/security It was discussed in threads [classlib] security2 -> security and [classlib] security moved Thanks, Mikhail 2006/4/10, Mark Hindess <[EMAIL PROTECTED]>: > What is the archive tree for? Why not just remove them and let svn > take care of "archiving" them? (This also means users don't have to > check out unnecessary files.) > > -Mark. > > On 4/10/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > luni ASN1 De/Encoder is never used. > > > > luni Base64 decoder is faster vs. corresponding security class, but it has > > a bug for which I do not see a quick fix: it does not support /n and > > /r characters > > in encoded form. Adding of that support would slow down luni implementation. > > > > luni DefaultPolicy is currently never used. > > > > So I suggest moving luni classes to archive/modules. > > > > Comments? > > > > Thanks, > > Mikhail > > > > > > 2006/4/6, Mikhail Loenko <[EMAIL PROTECTED]>: > > > We have pairs of implementations for the following functionality > > > (modules luni and security): > > > > > > ASN1 De/Encoding > > > Base64 De/Encoding > > > DefaultPolicy > > > > > > I'm going to compare and choose one them but I'd appreciate if someone > > > else would compare them too. > > > > > > Thanks, > > > Mikhail > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
What is the archive tree for? Why not just remove them and let svn take care of "archiving" them? (This also means users don't have to check out unnecessary files.) -Mark. On 4/10/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > luni ASN1 De/Encoder is never used. > > luni Base64 decoder is faster vs. corresponding security class, but it has > a bug for which I do not see a quick fix: it does not support /n and > /r characters > in encoded form. Adding of that support would slow down luni implementation. > > luni DefaultPolicy is currently never used. > > So I suggest moving luni classes to archive/modules. > > Comments? > > Thanks, > Mikhail > > > 2006/4/6, Mikhail Loenko <[EMAIL PROTECTED]>: > > We have pairs of implementations for the following functionality > > (modules luni and security): > > > > ASN1 De/Encoding > > Base64 De/Encoding > > DefaultPolicy > > > > I'm going to compare and choose one them but I'd appreciate if someone > > else would compare them too. > > > > Thanks, > > Mikhail > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
luni ASN1 De/Encoder is never used. luni Base64 decoder is faster vs. corresponding security class, but it has a bug for which I do not see a quick fix: it does not support /n and /r characters in encoded form. Adding of that support would slow down luni implementation. luni DefaultPolicy is currently never used. So I suggest moving luni classes to archive/modules. Comments? Thanks, Mikhail 2006/4/6, Mikhail Loenko <[EMAIL PROTECTED]>: > We have pairs of implementations for the following functionality > (modules luni and security): > > ASN1 De/Encoding > Base64 De/Encoding > DefaultPolicy > > I'm going to compare and choose one them but I'd appreciate if someone > else would compare them too. > > Thanks, > Mikhail > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
Hi George: That sounds great!:) You meaning, in this way, we shall divide one testcase, e.g., FileChannelTest, into two parts, one contain tests that pass on windows and the other with Linux? And the list of "should fix" contains some testcases that require special environment or need a fix? And in Harmony's plan, more platform is to be supported. In this case, maybe some other attribute can be added to the exclude list. This is a good idea! So shall we name the test files as "***TestLinux32/win32.java" and add it to exclude list? 2006/4/10, George Harley <[EMAIL PROTECTED]>: > > LvJimmy，Jing wrote: > > Hi All: > > > > Another thing requires our attention is that RI itself, I meaning > > Sun,IBM, BEA or so, does not perform the same in different platforms. > That > > is reasonable as the Operation-Systems do not work in the same way. For > an > > example, these differences appear very frequently on network functions. > As a > > result, it seems very difficult for us to write testcases on them. > > Currently, as Harmony only supports windows and Linux, one possible > but > > bad solution is that get system properity "OS" in our unit testcase, use > > different parameters in testcases by telling whether it is Linux or > windows. > > Another solution we comment out these testcases, or add them into > "exclude > > testcase list" when apply our patch, as we do recently. Both solutions > are > > not so proper. > > > > Hi Jimmy, > > The (infamous) exclusion list brings with it the ability to exclude > named test case methods if they are being run on a specific name > platform [1]. That would remove both the need to comment out methods in > the test case class (and with it the dependency on the developer > remembering to go back and uncomment the method in the future) as well > as the need for peppering the test code with operating system detection > code and multiple different code paths. Result : cleaner test code and > one list containing all of the test methods that may or may not get run > depending on platform etc. > > Best regards, > George > > [1] = > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL > PROTECTED] > > > > Perhaps we shall find other ways to run different test cases > according > > to different OS, like Harmony build system do. Who has any opinions? > > > > Best Regards! > > > > Jimmy, Jing Lv > > China Software Development Lab, IBM > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
JIRA down again ?
Hi, Currently returning the "503 Service Temporarily Unavailable" page. Does anyone have an estimate for when things will be restored ? Best regards, George - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
LvJimmy，Jing wrote: Hi All: Another thing requires our attention is that RI itself, I meaning Sun,IBM, BEA or so, does not perform the same in different platforms. That is reasonable as the Operation-Systems do not work in the same way. For an example, these differences appear very frequently on network functions. As a result, it seems very difficult for us to write testcases on them. Currently, as Harmony only supports windows and Linux, one possible but bad solution is that get system properity "OS" in our unit testcase, use different parameters in testcases by telling whether it is Linux or windows. Another solution we comment out these testcases, or add them into "exclude testcase list" when apply our patch, as we do recently. Both solutions are not so proper. Hi Jimmy, The (infamous) exclusion list brings with it the ability to exclude named test case methods if they are being run on a specific name platform [1]. That would remove both the need to comment out methods in the test case class (and with it the dependency on the developer remembering to go back and uncomment the method in the future) as well as the need for peppering the test code with operating system detection code and multiple different code paths. Result : cleaner test code and one list containing all of the test methods that may or may not get run depending on platform etc. Best regards, George [1] = http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] Perhaps we shall find other ways to run different test cases according to different OS, like Harmony build system do. Who has any opinions? Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Harmony Launcher Plug-in Available For Eclipse
Hi George: That's right. Thank you! :) 2006/4/10, George Harley <[EMAIL PROTECTED]>: > > LvJimmy，Jing wrote: > > Hi George: > > > > Thanks very much for your work, I've struggled for eclipse > > Harmony-JRE-configuration for hours this morning until find a solution > from > > your mail :) > > For alternative, a direct copy of this file " > > org.apache.harmony.eclipse.jdt.launching_1.0.1.jar" to eclipse plug-in > > directory works properly as well :) > > > > Best regards, > > Jimmy,Jing lv > > > > Hi, > > This is true but then you don't get the benefits of the Eclipse update > mechanism which provides capabilities to auto-check for updates to > installed features, disable/restore features etc. Let Eclipse do the > work for you. > > Best regards, > George Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: New Harmony Launcher Plug-in Available For Eclipse
LvJimmy，Jing wrote: Hi George: Thanks very much for your work, I've struggled for eclipse Harmony-JRE-configuration for hours this morning until find a solution from your mail :) For alternative, a direct copy of this file " org.apache.harmony.eclipse.jdt.launching_1.0.1.jar" to eclipse plug-in directory works properly as well :) Best regards, Jimmy,Jing lv Hi, This is true but then you don't get the benefits of the Eclipse update mechanism which provides capabilities to auto-check for updates to installed features, disable/restore features etc. Let Eclipse do the work for you. Best regards, George 2006/4/7, George Harley <[EMAIL PROTECTED]>: [EMAIL PROTECTED] wrote: Hi Etienne, That is as expected, I think, as the URL is intended for the Eclipse update manager not web browsers. So, I do not need it if I do not work with Eclipse, do I ? Hi Hadrien, That's right ; the plug-in is an extension to Eclipse that enables developers to conveniently define a Harmony JRE to the IDE and run applications on it from within their IDE workspace. Best regards, George Best regards, George Etienne Gagnon wrote: The link gives me: An Exception Has Occurred Python Traceback Traceback (most recent call last): File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main request.run_viewcvs() ... George Harley wrote: split. Please point your Eclipse update manager at the following site and install version 1.0.1 ... http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: matching reference implementation exception behaviour
Hi All: Another thing requires our attention is that RI itself, I meaning Sun,IBM, BEA or so, does not perform the same in different platforms. That is reasonable as the Operation-Systems do not work in the same way. For an example, these differences appear very frequently on network functions. As a result, it seems very difficult for us to write testcases on them. Currently, as Harmony only supports windows and Linux, one possible but bad solution is that get system properity "OS" in our unit testcase, use different parameters in testcases by telling whether it is Linux or windows. Another solution we comment out these testcases, or add them into "exclude testcase list" when apply our patch, as we do recently. Both solutions are not so proper. Perhaps we shall find other ways to run different test cases according to different OS, like Harmony build system do. Who has any opinions? Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [rmi] getting 1.4 bytecode
Daniel Gandara wrote: Hi,As discussed with Oliver, I built the rmi code with the -target jsr14 option and I got a 1.4 bytecode for the package.I run our test suit against the package and it seems to work ok. That's great news! This is a sum up of the experience: 1) -target jsr14 option only worked with Sun's compiler, Icould not make it work on Eclipse... Tim described in [1] that the Eclipse batch compiler unfortunately does not support this kind of 1.5 to 1.4 compilation. There has been further discussion in that thread as to which solution is best for us - Sun compiler using -target jsr14, and/or Eclipse compiler at 1.5 level and then use a tool called Retroweaver to alter the bytecodes to work on 1.4. 2) I had to make changes to the code, basically I had tochange enums and change/remove java.util.concurrentclasses we use (ConcurrentHashMap andThreadPoolExecutor) I got some enum examples working by just adding a basic Enumeration class to the java.lang package in luni, but I only trialled fairly simple cases. What kind of alterations did you need to make? It will be interesting to know some of the limits of this compiler option. note: there is obviously a performance penalty due to 2). The question I have now is if I should send this modified code to be used in Harmony during this transitional phase or not. What do you think? I think it's probably a good thing to get the code out there so we can start to use it, even if this means making some temporary modifications. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] I'll be waitting for comments, Daniel - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-315) javax.crypto.Cipher.getInstance doesn't match RI exception behaviour.
On 4/10/06, Mark Hindess wrote:
>
> On 4/10/06, Stepan Mishura wrote:
> > Hi Mark,
> >
> > Basing on the bug description I assume that RI checks provider parameter
> > first.
>
> Yes.
>
> > In all your examples this parameter is invalid.
>
> Yes. (It was one of the test cases generated by my Perl script - that
> I've nearly finished tidying up for contribution.)
>
> > The spec. for method javax.crypto.Cipher.getInstance(String
> transformation,
> > String provider)
> > says:
> > "Throws:
> > NoSuchAlgorithmException - if transformation is null, empty, in an
> > invalid format, or not available from the specified provider.
> > NoSuchProviderException - if the specified provider has not been
> > configured.
> > NoSuchPaddingException - if transformation contains a padding scheme
> > that is not available.
> > IllegalArgumentException - if the provider is null."
> >
> > So IllegalArgumentException can be thrown only if the provider parameter
> is
> > null. But IMHO in case of empty string NoSuchProviderException should be
> > thrown.
> >
> > What do you think?
>
> So we agree about fixing the two cases where provider is (String)null.
> We just need to decide what to do about the other two where provider
> is (String)"" ?
Yes.
I think we should match the RI behaviour. That means that even in the
> two cases where provider is the empty string we should still throw an
> IllegalArgumentException.
>
> I think the wording of the spec for the getInstance method that takes
> a String provider is just vague because it was copied from the method
> that takes a Provider object. I think the RI behaviour reflects the
> intention of the spec even if the spec is unclear.
The problem is that java.security.Security allows such provider name, for
example, the following code works on RI:
=== SmallProvider.java =
import java.security.Provider;
public class SmallProvider extends Provider {
public SmallProvider() {
super("", // name
1.0, // version
"SmallProvider" // info
);
}
}
=== test.java ===
import java.security.Security;
public class test {
public static void main(String[] args){
Security.addProvider(new SmallProvider());
System.out.println(Security.getProvider("").getInfo());
}
}
If we will follow RI then it will be possible to access Cipher object via:
Cipher.getInstance(, Security.getProvider(""));
But impossible to do the same via: Cipher.getInstance(,
"");
Thanks,
Stepan.
Regards,
> Mark.
>
> > Thanks,
> > Stepan
> >
> > >From: Mark Hindess (JIRA)
> > >Sent: Friday, April 07, 2006 1:31 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: [jira] Created: (HARMONY-315) javax.crypto.Cipher.getInstance
> > >doesn't match RI exception behaviour.
> > >
> > >javax.crypto.Cipher.getInstance doesn't match RI exception behaviour.
> > >-
> > >
> > > Key: HARMONY-315
> > > URL: http://issues.apache.org/jira/browse/HARMONY-315
> > > Project: Harmony
> > >Type: Bug
> > >
> > > Components: Classlib
> > >Reporter: Mark Hindess
> > >Priority: Trivial
> > >
> > >
> > >javax.crypto.getInstance methods doesn't match reference behaviour. It
> > >throws NoSuchProvideExceptions when it should be throwing
> > >IllegalArgumentExceptions. See log below for details.
> > >
> > >RI is Sun Microsystems Inc. 1.5.0_06
> > >Test is harmony classlib
> > >
> > >javax.crypto.Cipher.getInstance("",""):
> > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > Test throws java.security.NoSuchProviderException: Provider is not
> > >available
> > >
> > >javax.crypto.Cipher.getInstance("",(java.lang.String)null):
> > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > Test throws java.security.NoSuchProviderException: Provider null is
> not
> > >available
> > >
> > >javax.crypto.Cipher.getInstance((java.lang.String)null,""):
> > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > Test throws java.security.NoSuchProviderException: Provider is not
> > >available
> > >
> > >javax.crypto.Cipher.getInstance((java.lang.String)null,(
> java.lang.String)nu
> > >ll):
> > > RI throws java.lang.IllegalArgumentException: Missing provider
> > > Test throws java.security.NoSuchProviderException: Provider null is
> not
> > >available
> > >
> > >
> > >--
> > >This message is automatically generated by JIRA.
> > >-
> > >If you think it was sent incorrectly contact one of the administrators:
> > > http://issues.apache.org/jira/secure/Administrators.jspa
> > >-
> > >For more information on JIRA, see:
> > > http://www.atlassian.com/software/jira
> >
> >
> > --
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additi
Re: [jira] Assigned: (HARMONY-221) regex need moving from modules/regex-beans-math to modules/regex
Geir, Would you mind reassigning it to me? Thanks, Stepan. >From: Geir Magnusson Jr (JIRA) [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 28, 2006 4:25 PM >To: [EMAIL PROTECTED] >Subject: [jira] Assigned: (HARMONY-221) regex need moving from >modules/regex-beans-math to modules/regex > > [ http://issues.apache.org/jira/browse/HARMONY-221?page=all ] > >Geir Magnusson Jr reassigned HARMONY-221: >- > >Assign To: Geir Magnusson Jr > >> regex need moving from modules/regex-beans-math to modules/regex >> >> >> Key: HARMONY-221 >> URL: http://issues.apache.org/jira/browse/HARMONY-221 >> Project: Harmony >> Type: Improvement >> Components: Classlib >> Reporter: Mark Hindess >> Assignee: Geir Magnusson Jr >> Priority: Minor >> Attachments: 01.regex.moves.sh, 02.regex.moves.sh, 03.regex.moves.diff >> >> Integrating regex part of HARMONY-39 contribution. > >-- >This message is automatically generated by JIRA. >- >If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa >- >For more information on JIRA, see: > http://www.atlassian.com/software/jira -- - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Stepan Mishura Intel Middleware Products Division
Re: [msvs] signals Re: Starting my next round on BootJVM
Does any onw know if newer editions of MSVS libraries handle more than these few signals? Dan Lydick Hi Dan, here are two interesting posts: http://archives.postgresql.org/pgsql-hackers-win32/2003-10/msg00025.php http://openvpn.net/archive/openvpn-devel/2004-08/msg00012.html Enrico - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [msvs] signals Re: Starting my next round on BootJVM
bootjvm wrote: Does any onw know if newer editions of MSVS libraries handle more than these few signals? Dan Lydick Hi Dan, OS runtime signals are explained here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_signal.asp This might be interesting for you: "By default, *signal* terminates the calling program with exit code 3, regardless of the value of /sig" / Which signals do you actually need for your bootJVM? Enrico - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
