Re: [doc] Compatibility guidelines
Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary "source" is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. Another minor comment regarding to the serialization compatibility: What if serialization form is not specified and the spec states that serialization form will not be compatible with future releases? Does it mean we want to copy the existing serialization form? Or we are going to define our own? Should it be reflected in the guidelines? Wishes, -- Anton Avtamonov, Intel Middleware Products Division On 4/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > nice. thanks. > > Tim Ellison wrote: > > I've tried to capture in a webpage the compatibility guidelines that we > > have agreed over the last few weeks. > > > > The page is here: > > http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html > > > > I'm sure I'll have forgotten something, so additions / corrections / > > etc. are welcome. > > > > Regards, > > Tim > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resource files for testing serialization - .dat or .ser?
On 4/25/06, Stepan Mishura wrote: > > Hi, > > Can we at least agree on extension for serialization resource files? > Defining common extension can be a first step in merging serialization > frameworks. > > Sorry, I meant merging testing frameworks to test serialization. -Stepan. Modules: beans, jndi, logging, luni, nio_char, text – contain serialization > resource files with extension 'ser'. (48 files total) > And files in modules auth, crypto, security, x-net have extension '.dat'. > (296 files total) > > So which one? > > Thanks, > Stepan Mishura > Intel Middleware Products Division > > -- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- 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] resource files for testing serialization - .dat or .ser?
Hi, Can we at least agree on extension for serialization resource files? Defining common extension can be a first step in merging serialization frameworks. Modules: beans, jndi, logging, luni, nio_char, text – contain serialization resource files with extension 'ser'. (48 files total) And files in modules auth, crypto, security, x-net have extension '.dat'. (296 files total) So which one? Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
Geir Magnusson Jr wrote: IOW : VM + host classlib + SpecialTestFramework(candidate classlib) if that makes any sense... I think the perfect SoC project could be to have Gump using Harmony. Either Leo or myself could volunteer to be the mentors. -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
relying on 'available()' (was: RE: [jira] Updated: (HARMONY-166) method read() in InputStreamReader failed to read one character)
Vladimir,
>Method available() is still used to determine endOfInput parameter.
According to >specification the
>method should be overridden by subclasses.
'should' does not mean 'must' , moreover it might be a user class who
does not care what the spec says. There could be cases when you do not
know how many bytes are available and you have to return 0.
So I think the patch should be modified to avoid 'available()'
Thanks,
Mikhail
>-Original Message-
>From: Vladimir Strigun (JIRA) [mailto:[EMAIL PROTECTED]
>Sent: Monday, April 24, 2006 5:14 PM
>To: [EMAIL PROTECTED]
>Subject: [jira] Updated: (HARMONY-166) method read() in
InputStreamReader failed to read one
>character
>
> [ http://issues.apache.org/jira/browse/HARMONY-166?page=all ]
>
>Vladimir Strigun updated HARMONY-166:
>-
>
>Attachment: InputStreamReader.java.patch
>
>Mikhail,
>
>please review my patch. Now method read() is not modified. I just
add decoding operations to
>fillBuf() method.
>Method available() is still used to determine endOfInput parameter.
According to specification the
>method should be overridden by subclasses.
>
>> method read() in InputStreamReader failed to read one character
>> ---
>>
>> Key: HARMONY-166
>> URL: http://issues.apache.org/jira/browse/HARMONY-166
>> Project: Harmony
>> Type: Bug
>
>> Components: Classlib
>> Reporter: Vladimir Strigun
>> Attachments: InputStreamReader.java.patch, InputStreamReader.patch.txt,
>InputStreamReaderTest.java
>>
>> I've started to play with harmony-57 contribution and found bug in
InputStreamReader class.
>Method read() should read a single character from input stream but it
works incorrectly for 2
>bytes-per-char charsets. Example below shows that it failed to read
one character in UTF-16
>charset. Sorry for so ugly test, it's just a part of
InputStreamReaderTest from Harmony-57
>contribution.
>> import java.io.*;
>> import junit.framework.TestCase;
>> public class InputStreamReaderTest extends TestCase {
>> public static void main(String[] args) {
>> junit.textui.TestRunner.run(InputStreamReaderTest.class);
>> }
>> public void test_ISR_read() throws Exception {
>> InputStream in;
>> InputStreamReader reader;
>> try {
>> in = new LimitedByteArrayInputStream(0);
>> reader = new InputStreamReader(in, "UTF-16BE");
>> int xx = reader.read();
>> assertTrue("Incorrect byte UTF-16BE", xx == '\u6172');
>> } catch (UnsupportedEncodingException e) {
>> // Can't test without the converter
>> System.out.println(e);
>> } catch (IOException e) {
>> e.printStackTrace();
>> fail("UTF-16BE unexpected 1: " + e);
>> }
>> try {
>> in = new LimitedByteArrayInputStream(0);
>> reader = new InputStreamReader(in, "UTF-16LE");
>> int xx = reader.read();
>> assertTrue("Incorrect byte UTF-16BE", xx == '\u7261');
>> } catch (UnsupportedEncodingException e) {
>> // Can't test without the converter
>> } catch (IOException e) {
>> fail("UTF-16BE unexpected 2: " + e);
>> }
>> try {
>> in = new LimitedByteArrayInputStream(1);
>> reader = new InputStreamReader(in, "UTF-16");
>> assertTrue("Incorrect byte UTF-16BE", reader.read() == '\u7261');
>> } catch (UnsupportedEncodingException e) {
>> // Can't test without the converter
>> } catch (IOException e) {
>> fail("UTF-16BE unexpected 3: " + e);
>> }
>> try {
>> in = new LimitedByteArrayInputStream(2);
>> reader = new InputStreamReader(in, "ISO2022JP");
>> int ch = reader.read();
>> assertTrue("Incorrect byte ISO2022JP 1: " + ch, ch == '\u4e5d');
>> ch = reader.read();
>> assertTrue("Incorrect byte ISO2022JP 2: " + ch, ch == '\u7b2c');
>> } catch (UnsupportedEncodingException e) {
>> // Can't test without the converter
>> System.out.println(e);
>> } catch (IOException e) {
>> fail("ISO2022JP unexpected: " + e);
>> }
>> }
>> static class LimitedByteArrayInputStream extends ByteArrayInputStream {
>> // A ByteArrayInputStream that only returns a single byte per read
>> byte[] bytes;
>> int count;
>> public LimitedByteArrayInputStream(int type) {
>> super(new byte[0]);
>> switch (type) {
>> case 0:
>> bytes = new byte[] { 0x61, 0x72 };
>> break;
>> case 1:
>> bytes = new byte[] { (byte) 0xff, (byte) 0xfe, 0x61, 0x72 };
>> break;
>> case 2:
>> bytes = new byte[] { '\u001b', '$', 'B', '6', 'e', 'B', 'h',
>> '\u001b', '(', 'B' };
>> break;
>> }
>> count = bytes.length;
>> }
>> public int read() {
>> if (count == 0)
>> return -1;
>> count--;
>> return bytes[bytes.length - count];
>> }
>> public int read(byte[] buffer, int offset, int length) {
>> if (count == 0)
>> return -1;
>> if (length == 0)
>> return 0;
>> buffer[offset] = bytes[bytes.length - count];
>> count--;
>> return 1;
>> }
>> public int available() {
>> return count;
>> }
>> }
>> }
>
>--
>This message is automatically generated by JIRA.
>-
>If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
> Geir Magnusson Jr wrote:
Vladimir Gorr wrote:
Mikhail,
I also thought about this scenario. However, if any TCK tests will
fail due
to this reason
we cannot certify our product. Nobody will talk about the invalidity
of TCK.
Most likely we will update our sources.
1) I hadn't thought about this before, but it seems much cleaner to
throw A (rather than B extends A) if the spec says to throw A.
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
"throws IOException" rather than "throws
ConnectionException,UnknownHostException". And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
2) and we may find some javadoc as "...then an unspecified error is
thrown." For an example, in java.util.jar.Pack200.newPacker(). We can do
nothing to meet such compatibility.
In summary, I think we shall follow doc in throwing exception; but if we
find it inconvenient indeed or even impossible, let it be. :)
2) You can challenge TCK tests and have them eliminated. We've done it
for J2EE and other specs. I believe that we're going to be in for quite
a bit of it because for all practical purposes, we'll be the first use
of the TCK on an independent implementation of Java SE.
geir
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
There is nothing about TCK here: if the spec requires to throw A
and we throw B that extends A then we follow the spec
And if there is a TCK test that verifies that we throw A and only A
then the test is invalid and we will not have to pass it
Sometimes it is an easy fix to throw A rather then B.
But there could be two RI methods - one throwing A and another one
throwing B
such that in our implementation they both refer to some third method.
In this case if we throw B in that 3rd method - then we conform the
spec,
we won't break existing apps and it might cause design weakening
if we choose to go coping how RI works.
So if the fix is easy then I'd agree to what folks say here, but in
general case
I'd not set the rule to follow RI this way.
Thanks,
Mikhail
2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>:
The answer to this question (in my opinion) depends on how TCK
processes
similar situations.
If we want to successfully perform this suite on Harmony we should be
compatible with RI.
For certain there are a lot of tests into TCK will fail due to this
reason
and we should be ready for this.
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Look at HARMONY-387.
Example:
1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
<0, while RI throws IndexOutOfBoundsException.
Specification mentions neither ArrayIndexOutOfBoundsException nor
IndexOutOfBoundsException.
Actually ArrayIndexOutOfBoundsException is a sub class of
IndexOutOfBoundsException.
So the statement "both Harmony and RI throw IndexOutOfBoundsException"
is
true.
But do we have to throw exactly those exceptions that are thrown by
RI?
Can we throw
o.a.h.VMRisenNPE that extends NullPointerException?
What if they throw kind of
sun.internal.SunFavoriteSubClassOfNullPointerException ?
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
I'd back what Santiago said: > I think the design should not suffer from such a problem, as > the parent says. Only for trivial changes I'd rename an exception. Thanks,. Mikhail 2006/4/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > > Vladimir Gorr wrote: > > Mikhail, > > > > I also thought about this scenario. However, if any TCK tests will fail due > > to this reason > > we cannot certify our product. Nobody will talk about the invalidity of TCK. > > Most likely we will update our sources. > > 1) I hadn't thought about this before, but it seems much cleaner to > throw A (rather than B extends A) if the spec says to throw A. > > 2) You can challenge TCK tests and have them eliminated. We've done it > for J2EE and other specs. I believe that we're going to be in for quite > a bit of it because for all practical purposes, we'll be the first use > of the TCK on an independent implementation of Java SE. > > geir > > > > > > Thanks, > > Vladimir. > > > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > >> There is nothing about TCK here: if the spec requires to throw A > >> and we throw B that extends A then we follow the spec > >> > >> And if there is a TCK test that verifies that we throw A and only A > >> then the test is invalid and we will not have to pass it > >> > >> Sometimes it is an easy fix to throw A rather then B. > >> > >> But there could be two RI methods - one throwing A and another one > >> throwing B > >> such that in our implementation they both refer to some third method. > >> > >> In this case if we throw B in that 3rd method - then we conform the spec, > >> we won't break existing apps and it might cause design weakening > >> if we choose to go coping how RI works. > >> > >> So if the fix is easy then I'd agree to what folks say here, but in > >> general case > >> I'd not set the rule to follow RI this way. > >> > >> Thanks, > >> Mikhail > >> > >> 2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>: > >>> The answer to this question (in my opinion) depends on how TCK processes > >>> similar situations. > >>> If we want to successfully perform this suite on Harmony we should be > >>> compatible with RI. > >>> For certain there are a lot of tests into TCK will fail due to this > >> reason > >>> and we should be ready for this. > >>> > >>> Thanks, > >>> Vladimir. > >>> > >>> On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Look at HARMONY-387. > > Example: > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > <0, while RI throws IndexOutOfBoundsException. > Specification mentions neither ArrayIndexOutOfBoundsException nor > IndexOutOfBoundsException. > > > Actually ArrayIndexOutOfBoundsException is a sub class of > IndexOutOfBoundsException. > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" > >> is > true. > > But do we have to throw exactly those exceptions that are thrown by > >> RI? > > Can we throw > o.a.h.VMRisenNPE that extends NullPointerException? > > What if they throw kind of > sun.internal.SunFavoriteSubClassOfNullPointerException ? > > Thanks, > Mikhail > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > >>> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
There have been some good suggestions, but I want to check and be sure that the project we propose has enough "original work" - IOW, there may be some requirement about new functionality. Either way, I have another suggestion for a SOC project, which would be very benficial (IMO) to our classlib effort while at the same time requiring some VM headspace... I'm talking about exploring my fantasies about a test framework that lets us do conventional "in the same package" unit-test authoring while giving us precise control over the classlibrary used to run the tests, as well as possibly other factors. Sanket, read back through if you aren't aware. There are two related basic problems is this... First, when we test the Harmony classlib, we use the harmony classlib to run JUnit to run the tests that test... the same classlib running JUnit. This should make anyone squeamish, because there is no "known good" base we are using for testing. Second, we *can't* have tests for the java.* classes as unit tests in java.* package space, because they'd need to be on the boot classpath, and therefore aren't in the same "context" as user code. So, the question is what to do. 1) Could we simply have a classloader that can be put in a special mode so it doesn't that unit tests for bootclasspath-resident packages are not on the boot classpath? 2) We can divide our tests into two types, "specification tests" (which can't be on boot classpath)for testing of the classlib's public behavior is as expected and "integration tests" which are tests which test private internal behavior. Some of these may suffer from context issues, which I think we can handle on a case by case basis. Ideally, it would be great to be able to test the classlib in a controlled way, independent of the VM and classlib needed to run it. IOW, it would be interesting to be able to test our classlib independent of the VM running it, and independent of the 'hosting' classlib running the test harness to test the candidate classlib. IOW : VM + host classlib + SpecialTestFramework(candidate classlib) if that makes any sense... Sanket Sharma wrote: Hi.. I spent some time looking for open projects.. I would prefer contributing to VM /Compiler code..but I'm open to any other suggestions... Can you guys please suggest something ??? Regards, Sanket -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 9:08 PM To: harmony-dev@incubator.apache.org Subject: Re: Summer Of Code 2006 - Lets get Harmony involved Excellent! Now we need a project. Have anything you'd like to propose? What interests you? geir Sanket Sharma wrote: Hey... I'm a final sem student doing my internship Get me in.. I wann get involved with harmony! Awaiting reply, Sanket -Original Message- From: Archie Cobbs [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 18, 2006 7:50 PM To: harmony-dev@incubator.apache.org Subject: Re: Summer Of Code 2006 - Lets get Harmony involved Geir Magnusson Jr wrote: Google again is running their "Summer Of Code" http://code.google.com/summerofcode.html program, and I think it would be great for the Harmony project to take advantage of it, assuming we can find willing students. ... Lets agree on projects here first. Great idea.. certainly one project that seems suitable is completing the gnuclasspathadapter stuff started by Weldon. -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] This email may contain confidential or privileged information for the intended recipient(s) and the views expressed in the same are not necessarily the views of Zensar Technologies Ltd. If you are not the intended recipient or have received this e-mail by error, its use is strictly prohibited, please delete the e-mail and notify the sender. Zensar Technologies Ltd. does not accept any liability for virus infected mails. - 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: Java 5 String APIs (code points, StringBuilder, etc) RE: [classlib] String is special
Or just put the test in java.lang as an implementation test. We should resolve this. Among others, we're going to have spec tests, which Tim and others rightly point out that we need to be careful with and keep out of the boot classpath to ensure that tests happen in the context of userland. However, with a good understanding of the limits, we should be also able to have the 'easy to use' same-package tests for implementation. In that vein, we could also create a helper framework that lets us write tests in java.lang (for example) and it transforms into the helper Tim suggests automatically... geir Tim Ellison wrote: I suggest you write a helper method to create a String with that constructor using reflection (setAccessible(true)). Regards, Tim Nathan Beyer wrote: Since I probably share some responsibility in the "String is special" topic being brought up, I wanted to try out the "golden ticket" bit for some further enhancements. I've made some changes to String to add the new Java 5 APIs related to code points, StringBuilder, etc. I've posted a proposed patch on this issue [1]. I'd already opened this bug. The patch contains updates to String and StringTest. There is one concern that I have about the code and the test (and all String tests we have in general). There's the possibility of a String being constructed with a non-zero offset; there's a package-private constructor String(int start, int len, char[] data). I haven't found any other way to setup this variant and I'd like to test all of the methods when the offset is greater than 0, but this requires the test case to be in the "java.lang" package. I know this has been an issue that been discussed on and off, but didn't think any concrete solution had been arrived at for doing this and I haven't seen any test cases in the java package spaces. Please let me know if there are any questions or if any more information is needed. Thanks. -Nathan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Vladimir Gorr wrote: Mikhail, I also thought about this scenario. However, if any TCK tests will fail due to this reason we cannot certify our product. Nobody will talk about the invalidity of TCK. Most likely we will update our sources. 1) I hadn't thought about this before, but it seems much cleaner to throw A (rather than B extends A) if the spec says to throw A. 2) You can challenge TCK tests and have them eliminated. We've done it for J2EE and other specs. I believe that we're going to be in for quite a bit of it because for all practical purposes, we'll be the first use of the TCK on an independent implementation of Java SE. geir Thanks, Vladimir. On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: There is nothing about TCK here: if the spec requires to throw A and we throw B that extends A then we follow the spec And if there is a TCK test that verifies that we throw A and only A then the test is invalid and we will not have to pass it Sometimes it is an easy fix to throw A rather then B. But there could be two RI methods - one throwing A and another one throwing B such that in our implementation they both refer to some third method. In this case if we throw B in that 3rd method - then we conform the spec, we won't break existing apps and it might cause design weakening if we choose to go coping how RI works. So if the fix is easy then I'd agree to what folks say here, but in general case I'd not set the rule to follow RI this way. Thanks, Mikhail 2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>: The answer to this question (in my opinion) depends on how TCK processes similar situations. If we want to successfully perform this suite on Harmony we should be compatible with RI. For certain there are a lot of tests into TCK will fail due to this reason and we should be ready for this. Thanks, Vladimir. On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Look at HARMONY-387. Example: 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len <0, while RI throws IndexOutOfBoundsException. Specification mentions neither ArrayIndexOutOfBoundsException nor IndexOutOfBoundsException. Actually ArrayIndexOutOfBoundsException is a sub class of IndexOutOfBoundsException. So the statement "both Harmony and RI throw IndexOutOfBoundsException" is true. But do we have to throw exactly those exceptions that are thrown by RI? Can we throw o.a.h.VMRisenNPE that extends NullPointerException? What if they throw kind of sun.internal.SunFavoriteSubClassOfNullPointerException ? Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Do we mix up regression and unit tests?
Mark Hindess wrote: > On 4/23/06, Dmitry M. Kononov <[EMAIL PROTECTED]> wrote: >> On 4/22/06, LvJimmy，Jing <[EMAIL PROTECTED]> wrote: >>> In my understanding, if someone want to add some regression tests to test >>> APIs, it >>> can be added directly to the API test files if any, it is not necessary to >>> open a new file. >> I see. Could you please explain what is your understanding of tests >> that are located in the luni/src/test/java/org/apache/harmony/tests/* >> directories? I would like to know what is the reason of creating >> subdirectories of the /src/test/java directory others than the >> tests directory? > > You are right to be confused. It is confusing. But it's just > historical. > > I think it is an attempt to match the package naming convention for > tests as described at: > > > http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html > > It says that tests should be in packages named: > > org.apache.harmony..tests > Which I'll note is a suggestion. I've been waiting for this subject to come back. Until we get our act together and find some way to test spec classes in a way that simulates how user code uses spec classes (like w/ a test harness) I guess we need to have API tests in here - IOW, tests that are testing the public APIs of the portion of the Java classlib implemented in 'modulename'. However, I think that should be the limit of this usage, and we should put as many internal implementation tests in the same package as the code being tested for all the advantages we hashed out before. (This gives me a great idea for a really original and important SOC project - the test harness that allows us to test the classlib in isolation, not in situ in the VM.) > The 'tests' packages are a result of integration of contributions that > for whatever reason did not use the naming convention. > > Having said that I think that *none* of the tests current have the > correct package names according the that naming convention. Those > closest are missing the '' before 'tests'. > > Should we rename our tests to match the convention? (Thus breaking > lots of JIRA patches ;-( ). For API tests? yes - when applying patches, we should be able to nip and tuck the package issues... 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: ITC's java.math package contribution
Chris Gray wrote: On Sunday 23 April 2006 02:07, Daniel Fridlender wrote: I also agree with [Vladimir] that it would be really nice to have a representative collection of realistic applications of the functionality of java.math. RSA key generation is definitely one of them. We should find more. That would also help us identifying methods that are critical for the performance in practice, thus methods that are worth optimizing further. For crypto, one could adopt the whole BouncyCastle test suite as a benchmark. Outside of crypto, I don't know of any practical uses for BigInteger (which doesn't mean that none exist). That's a good idea... anyone focused on math at least create a JIRA so we don't forget? (I can't... I'm on a plane... I'll do it when I land if no one beats me to it...) geir Chris - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [admin] Split the list (was RE: Split the list ?)
I'll add my vote to using the [topic] markers. This works well for other Apache projects like Jakarta Commons. I think they've split of some separate mailing lists, but this was based on the sheer volume for certain projects. I'd also add using the [topic] markers in subject line of JIRA issues too, but that may not be everyone's liking. -Nathan > -Original Message- > From: Etienne Gagnon [mailto:[EMAIL PROTECTED] > Sent: Monday, April 24, 2006 8:51 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [admin] Split the list (was RE: Split the list ?) > > I agree with Geir. It's a good idea to keep classlib and vm people > aware of what the others are doing. Sometimes, issues that might seem > unrelated by classlib or vm people might actually affect the other > group. I much prefer the suggested [topic] approach. > > Etienne > > Magnusson, Geir wrote: > > I've thought about it, but I think that it's a bit premature. Why? > > Because I think that once we fracture the list traffic, we lose a lot of > > the intermixing that's important. > > > > I think once we have a lot more VM traffic, it makes perfect sense. > > > > However, I think that as an intermediate step though we should all work > > very hard to tag our subject lines with a [topic] :) > > -- > Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Compatibility guidelines
nice. thanks. Tim Ellison wrote: I've tried to capture in a webpage the compatibility guidelines that we have agreed over the last few weeks. The page is here: http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html I'm sure I'll have forgotten something, so additions / corrections / etc. are welcome. Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Split the list ?
Thorbjørn Ravn Andersen wrote: Magnusson, Geir skrev den 24-04-2006 14:39: :) SSG == Solutions and Software Group P = product D = Division Guess what M stands for... :) Geir, I was wondering if you could make an informal statement regarding how IBM and Intel is backing the harmony project? Sounds like there is many man hours in code, both past and future. Well, I won't make any statements on behalf of IBM or Intel, and I'd be surprised if anyone else did. However, I believe you can judge corporate support by the contributions to the community made by those corporations, and there are many ways they can do it. Some that spring to mind are direct code donations, allowing employees to participate on company time, donations directly to the ASF, *usage* of a project, etc. Both Intel and IBM have made generous donations that do reflect much investment, and I expect that both companies will continue to support the project with further donations of code as well as support via giving empoyees freedom to participate here. That said we need to be sure to treat - as much as possible - the contributions of individuals as coming from those individuals. As much as possible, we leave our employer hats at the door, and put on our harmony hats. I think it is great because this gives a big momentum but I also think it would be nice to hear this in the open. There have been statements in the press by IBM and Intel, IIRC. -- Thorbjørn (all by myself) geir (me too) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Split the list ?
oh, you're hilarious... Tim Ellison wrote: Magnusson, Geir wrote: :) SSG == Solutions and Software Group P = product D = Division Guess what M stands for... "Magnusson's" ? Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[doc] Compatibility guidelines
I've tried to capture in a webpage the compatibility guidelines that we have agreed over the last few weeks. The page is here: http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html I'm sure I'll have forgotten something, so additions / corrections / etc. are welcome. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rmi] package comparison (was Re: Contribution of RMI framework)
Hi Vasily, I believe we should sum up and start specific threads for each topic; This is a list of topics and posting names I suggest: a) Improve Specification --> [rmi] improve spec We agreed in the "problems" the spec has. I believe here -Harmony- is the place to start a request for improvement. I started a post "[rmi] spec issues" but noone commented on it, I guess I should repost it :) b) Packages --> [rmi] In order to end up with a better package for the community, we should review each other implementation and architecture approach, after that, we can discuss on specific things. c) Performance & real apps --> [rmi] real apps We need to define a set of real apps and workload to run against the packages in order to measure performance. I see a similar discusion taking place at java.math, since they also have to compare two implementations. please comment on each, and add/remove if I'm missing something. Thanks, Daniel - Original Message - From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: Sent: Friday, April 21, 2006 12:56 PM Subject: RE: [rmi] package comparison (was Re: Contribution of RMI framework) Daniel, black-box testing (reverse engineering I would call the complete procedure) Black-box testing is NOT reverse engineering, as the latter could suggest disassembling the code or something like that, that would violate the clean-room procedures and that we certainly didn't do. What we were doing is checking carefully how our implementation works with reference implementation, and making sure the RI gets what it asks for in the protocol. is an approach, but, can you be sure you are 100% compatible? No, of course we can't, as we didn't pass the Java TCK. :) But we were testing interoperability extensively, and also tried the real applications. what about other providers? I don't know, we didn't check any other providers. But if they're compatible with RI, they would most probably be also compatible with our implementation. :) so we should now move on comparing what is comparable between the packages: its functionality. Yeah, I agree with that. I mean, you can provide compatibility with reference implementation (let's say provider A), but what about users working with provider B? or C? are you assuming all providers do the same black-boxing? and if so, all of them arrived to the same conclusion about how the wire protocol behaves? Surely, we can do nothing about this (except improving the spec, which is surely good, but a very long process). If all providers strive to be compatible with reference implementation - they probably would be compatible to each other. If they don't - they would never be compatible. Also, the reference implementation is still most widely used, so being compatible to it is most important. Standards and specifications are what interoperability is all about! Yes, of course, I fully agree with this. there is no way in which you can provide compatibility if there is no standard; And this is the thing I can't agree with. Standard greatly helps in achieving compatibility, but that can also be done without a standard. so I strongly believe that having a better quality spec is the way we can really benefit the community ... if not, you -and I and other providers too- will always be one step behind the "reference" implementation, spending lots of hours and resources finding out how things are being done inside the black box. Yes, of course, improving the spec is a great goal. But it's a long term goal, and I completely agree with you on this - in long term. But improving the spec would probably take years, and we surely need some short term solution to provide to the community now. it will be great if you contribute what you have conclude about the protocol. Hmm, we've already done that - it's already in the code. We weren't writing any documentation about the internal details of our implementation, we were only noting things in the doc where our implememtation behaved differently than the RI. Vasily -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 1:17 AM To: harmony-dev@incubator.apache.org Subject: Re: [rmi] package comparison (was Re: Contribution of RMI framework) Zakharov, Vasily M wrote Daniel, We started our development as a clean room implementation of the package following the spec; and we found it -the spec (JRMP included)- to be vague and incomplete making it impossible for us to get interoperability without doing "code inspection" or "reverse engineering", which was not allowed by the imposed clean-room restriction. I believe you faced the same situation, and it will be good to know how you tackle it without compromising your development. Of course, we also followed the clean-room restrictions, but we struggled to be compatible with reference implementation and used a lot of black-box testing to find out wha
Re: [rmi] package comparison (was Re: Contribution of RMI framework)
Vasily, black-box testing (reverse engineering I would call the complete procedure) Black-box testing is NOT reverse engineering, as the latter could suggest disassembling the code or something like that, that would violate the clean-room procedures and that we certainly didn't do. What we were doing is checking carefully how our implementation works with reference implementation, and making sure the RI gets what it asks for in the protocol. That's ok, I never meant that you were "disassembling the code" I just was curious about how you get the interoperability. Daniel - Original Message - From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: Sent: Friday, April 21, 2006 12:56 PM Subject: RE: [rmi] package comparison (was Re: Contribution of RMI framework) Daniel, black-box testing (reverse engineering I would call the complete procedure) Black-box testing is NOT reverse engineering, as the latter could suggest disassembling the code or something like that, that would violate the clean-room procedures and that we certainly didn't do. What we were doing is checking carefully how our implementation works with reference implementation, and making sure the RI gets what it asks for in the protocol. is an approach, but, can you be sure you are 100% compatible? No, of course we can't, as we didn't pass the Java TCK. :) But we were testing interoperability extensively, and also tried the real applications. what about other providers? I don't know, we didn't check any other providers. But if they're compatible with RI, they would most probably be also compatible with our implementation. :) so we should now move on comparing what is comparable between the packages: its functionality. Yeah, I agree with that. I mean, you can provide compatibility with reference implementation (let's say provider A), but what about users working with provider B? or C? are you assuming all providers do the same black-boxing? and if so, all of them arrived to the same conclusion about how the wire protocol behaves? Surely, we can do nothing about this (except improving the spec, which is surely good, but a very long process). If all providers strive to be compatible with reference implementation - they probably would be compatible to each other. If they don't - they would never be compatible. Also, the reference implementation is still most widely used, so being compatible to it is most important. Standards and specifications are what interoperability is all about! Yes, of course, I fully agree with this. there is no way in which you can provide compatibility if there is no standard; And this is the thing I can't agree with. Standard greatly helps in achieving compatibility, but that can also be done without a standard. so I strongly believe that having a better quality spec is the way we can really benefit the community ... if not, you -and I and other providers too- will always be one step behind the "reference" implementation, spending lots of hours and resources finding out how things are being done inside the black box. Yes, of course, improving the spec is a great goal. But it's a long term goal, and I completely agree with you on this - in long term. But improving the spec would probably take years, and we surely need some short term solution to provide to the community now. it will be great if you contribute what you have conclude about the protocol. Hmm, we've already done that - it's already in the code. We weren't writing any documentation about the internal details of our implementation, we were only noting things in the doc where our implememtation behaved differently than the RI. Vasily -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 1:17 AM To: harmony-dev@incubator.apache.org Subject: Re: [rmi] package comparison (was Re: Contribution of RMI framework) Zakharov, Vasily M wrote Daniel, We started our development as a clean room implementation of the package following the spec; and we found it -the spec (JRMP included)- to be vague and incomplete making it impossible for us to get interoperability without doing "code inspection" or "reverse engineering", which was not allowed by the imposed clean-room restriction. I believe you faced the same situation, and it will be good to know how you tackle it without compromising your development. Of course, we also followed the clean-room restrictions, but we struggled to be compatible with reference implementation and used a lot of black-box testing to find out what goes on in the reference implementation data exchange. black-box testing (reverse engineering I would call the complete procedure) is an approach, but, can you be sure you are 100% compatible? what about other providers? Having said that, I believe comparision between packages should be done based on functionality and NOT on interoperability since it is -at least- underspecified and it can be a
Re: Split the list ?
Magnusson, Geir wrote: > :) > > SSG == Solutions and Software Group > > P = product > D = Division > > Guess what M stands for... "Magnusson's" ? Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Split the list ?
On 4/24/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote: > > Magnusson, Geir skrev den 24-04-2006 14:39: > > :) > > > > SSG == Solutions and Software Group > > > > P = product > > D = Division > > > > Guess what M stands for... > > > > > :) > > Geir, I was wondering if you could make an informal statement regarding > how IBM and Intel is backing the harmony project? Sounds like there is > many man hours in code, both past and future. > > I think it is great because this gives a big momentum but I also think > it would be nice to hear this in the open. While Intel's middleware division is commited to Harmony, Intel's top brass is pushing Wintel everywhere. And Microsoft is known for its anti-java stance. In fact, the whole point of .net and C# was to take mindshare away from java, which with its cross-platform warranty, makes windows irrelevant. So, here we have a small section of Intel funding something that the Evil Empire of Redmondia hates with a passion. I'd say it wouldn't be nice to make a big fuss out of Intel's involvement. In fact, it could even backfire. But then WTF do I know, I'm a journalist geek. ;-) FC
Re: [admin] Split the list (was RE: Split the list ?)
I agree with Geir. It's a good idea to keep classlib and vm people aware of what the others are doing. Sometimes, issues that might seem unrelated by classlib or vm people might actually affect the other group. I much prefer the suggested [topic] approach. Etienne Magnusson, Geir wrote: > I've thought about it, but I think that it's a bit premature. Why? > Because I think that once we fracture the list traffic, we lose a lot of > the intermixing that's important. > > I think once we have a lot more VM traffic, it makes perfect sense. > > However, I think that as an intermediate step though we should all work > very hard to tag our subject lines with a [topic] :) -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: Split the list ?
Magnusson, Geir skrev den 24-04-2006 14:39: :) SSG == Solutions and Software Group P = product D = Division Guess what M stands for... :) Geir, I was wondering if you could make an informal statement regarding how IBM and Intel is backing the harmony project? Sounds like there is many man hours in code, both past and future. I think it is great because this gives a big momentum but I also think it would be nice to hear this in the open. -- Thorbjørn (all by myself) smime.p7s Description: S/MIME Cryptographic Signature
[admin] Split the list (was RE: Split the list ?)
I've thought about it, but I think that it's a bit premature. Why? Because I think that once we fracture the list traffic, we lose a lot of the intermixing that's important. I think once we have a lot more VM traffic, it makes perfect sense. However, I think that as an intermediate step though we should all work very hard to tag our subject lines with a [topic] :) geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 > -Original Message- > From: Robin Garner [mailto:[EMAIL PROTECTED] > Sent: Monday, April 24, 2006 6:17 AM > To: harmony-dev@incubator.apache.org > Subject: Split the list ? > > Has anyone else considered the possibility of splitting the > harmony-dev > list ? As a memory manager/VM hacker, I'm interested to keep up with > the high level happenings in the harmony world, but not > necessarily with > the low-level details of bugs in the class library (and so forth). > > What do people thing about creating, say, a harmony-classlib > list, and > leaving the main harmony-dev list for less in-depth discussions ? > > cheers, > Robin > > - > 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: Split the list ?
:) SSG == Solutions and Software Group P = product D = Division Guess what M stands for... -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 > -Original Message- > From: Fernando Cassia [mailto:[EMAIL PROTECTED] > Sent: Monday, April 24, 2006 6:55 AM > To: harmony-dev@incubator.apache.org > Subject: Re: Split the list ? > > On 4/24/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > > > > > > Thanks, > > Vladimir Gorr > > Intel Middleware Products Division. > > > On a totally unrelated matter, I'm amazed and the number of people > apparently working at Intel's "middleware division". > It seems there is much more intel middleware than what I've > ever imagined!. > ;-) > > How many of you are there, Vladimir, if you don't mind me > asking? (AndI mean > people working at Intel's middleware division, not Vladimirs > in general ;-). > > FC > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/24/06, Santiago Gala <[EMAIL PROTECTED]> wrote: > > El lun, 24-04-2006 a las 14:48 +0700, Vladimir Gorr escribió: > > Mikhail, > > > > I also thought about this scenario. However, if any TCK tests will fail > due > > to this reason we cannot certify our product. Nobody will talk about the > invalidity of TCK. > > Most likely we will update our sources. > > > > Not really. The TCK processes have provisions for such "TCK bug > reports". I think the design should not suffer from such a problem, as > the parent says. Only for trivial changes I'd rename an exception. Or > temporarily, while the TCK gets amended. Ok, I see. It's fine there is such possibility to correct the TCK suite. Thanks, Vladimir. Regards > Santiago > > > Thanks, > > Vladimir. > > > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > There is nothing about TCK here: if the spec requires to throw A > > > and we throw B that extends A then we follow the spec > > > > > > And if there is a TCK test that verifies that we throw A and only A > > > then the test is invalid and we will not have to pass it > > > > > > Sometimes it is an easy fix to throw A rather then B. > > > > > > But there could be two RI methods - one throwing A and another one > > > throwing B > > > such that in our implementation they both refer to some third method. > > > > > > In this case if we throw B in that 3rd method - then we conform the > spec, > > > we won't break existing apps and it might cause design weakening > > > if we choose to go coping how RI works. > > > > > > So if the fix is easy then I'd agree to what folks say here, but in > > > general case > > > I'd not set the rule to follow RI this way. > > > > > > Thanks, > > > Mikhail > > > > > > 2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>: > > > > The answer to this question (in my opinion) depends on how TCK > processes > > > > similar situations. > > > > If we want to successfully perform this suite on Harmony we should > be > > > > compatible with RI. > > > > For certain there are a lot of tests into TCK will fail due to this > > > reason > > > > and we should be ready for this. > > > > > > > > Thanks, > > > > Vladimir. > > > > > > > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Look at HARMONY-387. > > > > > > > > > > Example: > > > > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int > len): > > > > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and > len > > > > > <0, while RI throws IndexOutOfBoundsException. > > > > > Specification mentions neither ArrayIndexOutOfBoundsException nor > > > > > IndexOutOfBoundsException. > > > > > > > > > > > > > > > Actually ArrayIndexOutOfBoundsException is a sub class of > > > > > IndexOutOfBoundsException. > > > > > > > > > > So the statement "both Harmony and RI throw > IndexOutOfBoundsException" > > > is > > > > > true. > > > > > > > > > > But do we have to throw exactly those exceptions that are thrown > by > > > RI? > > > > > > > > > > > > > > > Can we throw > > > > > o.a.h.VMRisenNPE that extends NullPointerException? > > > > > > > > > > What if they throw kind of > > > > > sun.internal.SunFavoriteSubClassOfNullPointerException ? > > > > > > > > > > Thanks, > > > > > Mikhail > > > > > > > > > > > - > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > VP and Chair, Apache Portals (http://portals.apache.org) > Apache Software Foundation > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQBETKxdZAeG2a2/nhoRAnOPAKCBJ2B0Tqtw8XW/bIw786dFrOkdIwCeKZv/ > Tm864my+0rgxf484HkKifWI= > =3z/i > -END PGP SIGNATURE- > > >
Re: Split the list ?
Good question :-). Actually I can say I'm aware about four Vladimirs working at Intel Middleware Product Division. There also are a little of Sergeys, Romans ... :-). I suppose you will like the following signature (others, I'm sorry for spam): Thanks, Vladimir. On 4/24/06, Fernando Cassia <[EMAIL PROTECTED]> wrote: > On 4/24/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > > > > > > Thanks, > > Vladimir Gorr > > Intel Middleware Products Division. > > > On a totally unrelated matter, I'm amazed and the number of people > apparently working at Intel's "middleware division". > It seems there is much more intel middleware than what I've ever > imagined!. > ;-) > > How many of you are there, Vladimir, if you don't mind me asking? (AndI > mean > people working at Intel's middleware division, not Vladimirs in general > ;-). > > FC > >
Re: Split the list ?
On 4/24/06, Vladimir Gorr <[EMAIL PROTECTED]> wrote: > > > Thanks, > Vladimir Gorr > Intel Middleware Products Division. On a totally unrelated matter, I'm amazed and the number of people apparently working at Intel's "middleware division". It seems there is much more intel middleware than what I've ever imagined!. ;-) How many of you are there, Vladimir, if you don't mind me asking? (AndI mean people working at Intel's middleware division, not Vladimirs in general ;-). FC
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
El lun, 24-04-2006 a las 14:48 +0700, Vladimir Gorr escribió: > Mikhail, > > I also thought about this scenario. However, if any TCK tests will fail due > to this reason we cannot certify our product. Nobody will talk about the > invalidity of TCK. > Most likely we will update our sources. > Not really. The TCK processes have provisions for such "TCK bug reports". I think the design should not suffer from such a problem, as the parent says. Only for trivial changes I'd rename an exception. Or temporarily, while the TCK gets amended. Regards Santiago > Thanks, > Vladimir. > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > There is nothing about TCK here: if the spec requires to throw A > > and we throw B that extends A then we follow the spec > > > > And if there is a TCK test that verifies that we throw A and only A > > then the test is invalid and we will not have to pass it > > > > Sometimes it is an easy fix to throw A rather then B. > > > > But there could be two RI methods - one throwing A and another one > > throwing B > > such that in our implementation they both refer to some third method. > > > > In this case if we throw B in that 3rd method - then we conform the spec, > > we won't break existing apps and it might cause design weakening > > if we choose to go coping how RI works. > > > > So if the fix is easy then I'd agree to what folks say here, but in > > general case > > I'd not set the rule to follow RI this way. > > > > Thanks, > > Mikhail > > > > 2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>: > > > The answer to this question (in my opinion) depends on how TCK processes > > > similar situations. > > > If we want to successfully perform this suite on Harmony we should be > > > compatible with RI. > > > For certain there are a lot of tests into TCK will fail due to this > > reason > > > and we should be ready for this. > > > > > > Thanks, > > > Vladimir. > > > > > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > > > Look at HARMONY-387. > > > > > > > > Example: > > > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > > > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > > > > <0, while RI throws IndexOutOfBoundsException. > > > > Specification mentions neither ArrayIndexOutOfBoundsException nor > > > > IndexOutOfBoundsException. > > > > > > > > > > > > Actually ArrayIndexOutOfBoundsException is a sub class of > > > > IndexOutOfBoundsException. > > > > > > > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" > > is > > > > true. > > > > > > > > But do we have to throw exactly those exceptions that are thrown by > > RI? > > > > > > > > > > > > Can we throw > > > > o.a.h.VMRisenNPE that extends NullPointerException? > > > > > > > > What if they throw kind of > > > > sun.internal.SunFavoriteSubClassOfNullPointerException ? > > > > > > > > Thanks, > > > > Mikhail > > > > > > > > - > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Split the list ?
Hi Robin, AFAIK Gmail allows to create the filters that can serve you for this purpose. You can use one or other filter depending on your needs or mood. IMHO it's not a good idea to have more Harmony e-mail lists (guts & panorama). Thanks, Vladimir Gorr Intel Middleware Products Division. On 4/24/06, Robin Garner <[EMAIL PROTECTED]> wrote: > > Has anyone else considered the possibility of splitting the harmony-dev > list ? As a memory manager/VM hacker, I'm interested to keep up with > the high level happenings in the harmony world, but not necessarily with > the low-level details of bugs in the class library (and so forth). > > What do people thing about creating, say, a harmony-classlib list, and > leaving the main harmony-dev list for less in-depth discussions ? > > cheers, > Robin > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Split the list ?
Seems to me like you're proposing a harmony-dev-guts and harmony-dev-panorama. ;-) Cheers, FC On 4/24/06, Robin Garner <[EMAIL PROTECTED]> wrote: > > Has anyone else considered the possibility of splitting the harmony-dev > list ? As a memory manager/VM hacker, I'm interested to keep up with > the high level happenings in the harmony world, but not necessarily with > the low-level details of bugs in the class library (and so forth). > > What do people thing about creating, say, a harmony-classlib list, and > leaving the main harmony-dev list for less in-depth discussions ? > > cheers, > Robin > >
Split the list ?
Has anyone else considered the possibility of splitting the harmony-dev list ? As a memory manager/VM hacker, I'm interested to keep up with the high level happenings in the harmony world, but not necessarily with the low-level details of bugs in the class library (and so forth). What do people thing about creating, say, a harmony-classlib list, and leaving the main harmony-dev list for less in-depth discussions ? cheers, Robin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r396013 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java test/java/tests/api/java/net/Inet6Add
Sorry, I should have caught that during review, I'll help Andrew fix it.
Thanks for point it out.
Tim
Andrew Zhang wrote:
> Anton Avtamonov wrote:
>> On 4/24/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
>>> Stepan Mishura wrote:
Hi,
I thought that we agreed on utilizing JUnit's exception handling
(see [1]).
So the next code from added unit test doesn't follow this
convention. Also
why it checks the same code twice?
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
>>> Sorry, it's a mistake. It's assumed use "-1" in the second case.
>>> I'll upload a patch right away.
>>
>> And as we discussed try/catch is not required here, right?
>
> Yes. We should add throws declaration on the method.
>>
>> --
>> Anton Avtamonov,
>> Intel Middleware Products Division
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Do we mix up regression and unit tests?
That's right, we took in a number of contributions and merged the tests in as quickly as we could, so we now have most of the tests being run regularly. We should go through and rename the packages to a consistent convention (and it might as well be now as later). Regards, Tim Mark Hindess wrote: > On 4/23/06, Dmitry M. Kononov <[EMAIL PROTECTED]> wrote: >> On 4/22/06, LvJimmy，Jing <[EMAIL PROTECTED]> wrote: >>> In my understanding, if someone want to add some regression tests to test >>> APIs, it >>> can be added directly to the API test files if any, it is not necessary to >>> open a new file. >> I see. Could you please explain what is your understanding of tests >> that are located in the luni/src/test/java/org/apache/harmony/tests/* >> directories? I would like to know what is the reason of creating >> subdirectories of the /src/test/java directory others than the >> tests directory? > > You are right to be confused. It is confusing. But it's just > historical. > > I think it is an attempt to match the package naming convention for > tests as described at: > > > http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html > > It says that tests should be in packages named: > > org.apache.harmony..tests > > The 'tests' packages are a result of integration of contributions that > for whatever reason did not use the naming convention. > > Having said that I think that *none* of the tests current have the > correct package names according the that naming convention. Those > closest are missing the '' before 'tests'. > > Should we rename our tests to match the convention? (Thus breaking > lots of JIRA patches ;-( ). > > 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] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r396013 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java test/java/tests/api/java/net/Inet6Add
Andrew Zhang wrote:
Stepan Mishura wrote:
Hi,
I thought that we agreed on utilizing JUnit's exception handling (see
[1]).
So the next code from added unit test doesn't follow this convention.
Also
why it checks the same code twice?
Hello, Stepan. I'm about to upload a patch for Harmony-398, which is
also for Inet6Address class.
I'll fix this problem in the patch.
Is that OK? Any comments?
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
Sorry, it's a mistake. It's assumed use "-1" in the second case.
I'll upload a patch right away.
Thanks,
Stepan.
[1] http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit_p.html
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 22, 2006 4:52 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r396013 - in
/incubator/harmony/enhanced/classlib/trunk/modules/luni/src:
main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java
test/java/tests/api/java/net/Inet6AddressTest.java
Author: tellison
Date: Fri Apr 21 14:52:02 2006
New Revision: 396013
URL: http://svn.apache.org/viewcvs?rev=396013&view=rev
Log:
Apply patch HARMONY-360 (Java 5 Enhancement: One new method
getByAddress(String, byte[], int) in class java.net.Inet6Address)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/
api/java/net/Inet6AddressTest.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/mod
ules/luni/src/main/java/java/net/Inet6Address.java?rev=396013&r1=396012&r2=
396013&view=diff
===
===
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java Fri Apr 21 14:52:02 2006
@@ -1,4 +1,4 @@
-/* Copyright 2003, 2005 The Apache Software Foundation or its
licensors,
as applicable
+/* Copyright 2003, 2006 The Apache Software Foundation or its
licensors,
as applicable
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -58,7 +58,7 @@
* @param address
*network address
* @param name
- *Name assocaited with the address
+ *Name associated with the address
* @param scope_id
*The scope id for link or site local addresses
*/
@@ -71,6 +71,31 @@
}
}
+ /**
+ * Constructs an IPv6 address according to the given
host,
+ * addr and scope_id.
+ *
+ * @param host
+ *hostname associated with the address
+ * @param addr
+ *network address
+ * @param scope_id
+ *the scope id for link or site local addresses
+ * @return an Inet6Address instance
+ * @throws UnknownHostException
+ * if the address is null or of invalid length
+ */
+ public static Inet6Address getByAddress(String host, byte[] addr,
+ int scope_id) throws UnknownHostException {
+ if (null == addr || 16 != addr.length) {
+ throw new UnknownHostException("Illegal ipv6 address");
+ }
+ if(scope_id < 0){
+ scope_id = 0;
+ }
+ return new Inet6Address(addr, host, scope_id);
+ }
+
/**
* Constructs an InetAddress, representing the address
and
* hostName and scope_id
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/mod
ules/luni/src/main/java/java/net/InetAddress.java?rev=396013&r1=396012&r2=3
96013&view=diff
===
===
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java Fri Apr 21 14:52:02 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors,
as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its
licensors,
as applicable
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -813,7 +813,7 @@
throws UnknownHostException {
// just call the method by the same name passing in a default
scope id
// of 0
- return ge
Re: svn commit: r396013 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java test/java/tests/api/java/net/Inet6Add
Anton Avtamonov wrote:
On 4/24/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
Stepan Mishura wrote:
Hi,
I thought that we agreed on utilizing JUnit's exception handling (see [1]).
So the next code from added unit test doesn't follow this convention. Also
why it checks the same code twice?
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
Sorry, it's a mistake. It's assumed use "-1" in the second case.
I'll upload a patch right away.
And as we discussed try/catch is not required here, right?
Yes. We should add throws declaration on the method.
--
Anton Avtamonov,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r396013 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java test/java/tests/api/java/net/Inet6Add
On 4/24/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> Stepan Mishura wrote:
> > Hi,
> >
> > I thought that we agreed on utilizing JUnit's exception handling (see [1]).
> > So the next code from added unit test doesn't follow this convention. Also
> > why it checks the same code twice?
> >
> > try {
> > Inet6Address.getByAddress("123", addr2, 3);
> > } catch (UnknownHostException e) {
> > fail("no exception should be thrown");
> > }
> > try {
> > Inet6Address.getByAddress("123", addr2, 3);
> > } catch (UnknownHostException e) {
> > fail("no exception should be thrown");
> > }
>
> Sorry, it's a mistake. It's assumed use "-1" in the second case.
> I'll upload a patch right away.
And as we discussed try/catch is not required here, right?
--
Anton Avtamonov,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r396013 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java test/java/tests/api/java/net/Inet6Add
Stepan Mishura wrote:
Hi,
I thought that we agreed on utilizing JUnit's exception handling (see [1]).
So the next code from added unit test doesn't follow this convention. Also
why it checks the same code twice?
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
Sorry, it's a mistake. It's assumed use "-1" in the second case.
I'll upload a patch right away.
Thanks,
Stepan.
[1] http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit_p.html
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 22, 2006 4:52 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r396013 - in
/incubator/harmony/enhanced/classlib/trunk/modules/luni/src:
main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java
test/java/tests/api/java/net/Inet6AddressTest.java
Author: tellison
Date: Fri Apr 21 14:52:02 2006
New Revision: 396013
URL: http://svn.apache.org/viewcvs?rev=396013&view=rev
Log:
Apply patch HARMONY-360 (Java 5 Enhancement: One new method
getByAddress(String, byte[], int) in class java.net.Inet6Address)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/
api/java/net/Inet6AddressTest.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/mod
ules/luni/src/main/java/java/net/Inet6Address.java?rev=396013&r1=396012&r2=
396013&view=diff
===
===
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/Inet6Address.java Fri Apr 21 14:52:02 2006
@@ -1,4 +1,4 @@
-/* Copyright 2003, 2005 The Apache Software Foundation or its licensors,
as applicable
+/* Copyright 2003, 2006 The Apache Software Foundation or its licensors,
as applicable
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -58,7 +58,7 @@
* @param address
*network address
* @param name
- *Name assocaited with the address
+ *Name associated with the address
* @param scope_id
*The scope id for link or site local addresses
*/
@@ -71,6 +71,31 @@
}
}
+ /**
+ * Constructs an IPv6 address according to the given
host,
+ * addr and scope_id.
+ *
+ * @param host
+ *hostname associated with the address
+ * @param addr
+ *network address
+ * @param scope_id
+ *the scope id for link or site local addresses
+ * @return an Inet6Address instance
+ * @throws UnknownHostException
+ * if the address is null or of invalid length
+ */
+ public static Inet6Address getByAddress(String host, byte[] addr,
+ int scope_id) throws UnknownHostException {
+ if (null == addr || 16 != addr.length) {
+ throw new UnknownHostException("Illegal ipv6 address");
+ }
+ if(scope_id < 0){
+ scope_id = 0;
+ }
+ return new Inet6Address(addr, host, scope_id);
+ }
+
/**
* Constructs an InetAddress, representing the address
and
* hostName and scope_id
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/mod
ules/luni/src/main/java/java/net/InetAddress.java?rev=396013&r1=396012&r2=3
96013&view=diff
===
===
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
et/InetAddress.java Fri Apr 21 14:52:02 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its licensors,
as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its licensors,
as applicable
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -813,7 +813,7 @@
throws UnknownHostException {
// just call the method by the same name passing in a default
scope id
// of 0
- return getByAddress(hostName, ipAddress, 0);
+ return getByAddressInternal(hostName, ipAddress, 0);
}
/**
@@ -837,7 +837,7 @@
*
* @throws UnknownHostException
*/
- static InetAddress getByAddress(String hostName, byte[] ipAddress,
+ sta
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > Yeah, in case RI operates with classes not from public API I would > > propose to base on spec. Or use the nearest class from public API if > > spec doesn't work for some reasons. > > Actually, spec even contains sometimes references to the classes from > > not public API... > > Really? You mean that the spec is not transitively close? > Can you give an example? Of course. I saw that many times. Just the first I can recall: MetalScrollBarUI.bumps Field bumps is of type which is not public api: the reference is not hyperlinked. If you want I can find some other cases: I definitely saw more than one :-) Wishes -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Mikhail, I also thought about this scenario. However, if any TCK tests will fail due to this reason we cannot certify our product. Nobody will talk about the invalidity of TCK. Most likely we will update our sources. Thanks, Vladimir. On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > There is nothing about TCK here: if the spec requires to throw A > and we throw B that extends A then we follow the spec > > And if there is a TCK test that verifies that we throw A and only A > then the test is invalid and we will not have to pass it > > Sometimes it is an easy fix to throw A rather then B. > > But there could be two RI methods - one throwing A and another one > throwing B > such that in our implementation they both refer to some third method. > > In this case if we throw B in that 3rd method - then we conform the spec, > we won't break existing apps and it might cause design weakening > if we choose to go coping how RI works. > > So if the fix is easy then I'd agree to what folks say here, but in > general case > I'd not set the rule to follow RI this way. > > Thanks, > Mikhail > > 2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>: > > The answer to this question (in my opinion) depends on how TCK processes > > similar situations. > > If we want to successfully perform this suite on Harmony we should be > > compatible with RI. > > For certain there are a lot of tests into TCK will fail due to this > reason > > and we should be ready for this. > > > > Thanks, > > Vladimir. > > > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > Look at HARMONY-387. > > > > > > Example: > > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > > > <0, while RI throws IndexOutOfBoundsException. > > > Specification mentions neither ArrayIndexOutOfBoundsException nor > > > IndexOutOfBoundsException. > > > > > > > > > Actually ArrayIndexOutOfBoundsException is a sub class of > > > IndexOutOfBoundsException. > > > > > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" > is > > > true. > > > > > > But do we have to throw exactly those exceptions that are thrown by > RI? > > > > > > > > > Can we throw > > > o.a.h.VMRisenNPE that extends NullPointerException? > > > > > > What if they throw kind of > > > sun.internal.SunFavoriteSubClassOfNullPointerException ? > > > > > > Thanks, > > > Mikhail > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Anton Avtamonov wrote: On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Look at HARMONY-387. Example: 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len <0, while RI throws IndexOutOfBoundsException. Specification mentions neither ArrayIndexOutOfBoundsException nor IndexOutOfBoundsException. Actually ArrayIndexOutOfBoundsException is a sub class of IndexOutOfBoundsException. So the statement "both Harmony and RI throw IndexOutOfBoundsException" is true. But do we have to throw exactly those exceptions that are thrown by RI? Yes. Harmony should throw the exactly same exception in this case. I think so. If RI behavior is reasonable and doesn't contradict to the spec (as above) we should unconditionally copy RI behavior. +1. Only When RI doesn't behave as spec or it's impossible for Harmony to throw the exact exception as RI(I don't know whether RI throws com.sun.internal.SunNullPointerException in some cases), we should discuss whether to follow RI or follow spec or behave as Harmony style :) Really, why do we need additional differences even though we absolutely sure that particular minor deviation would have no impact on client apps? Can we throw o.a.h.VMRisenNPE that extends NullPointerException? What if they throw kind of sun.internal.SunFavoriteSubClassOfNullPointerException ? Yeah, in case RI operates with classes not from public API I would propose to base on spec. Or use the nearest class from public API if spec doesn't work for some reasons. Actually, spec even contains sometimes references to the classes from not public API... Wishes, -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
There is nothing about TCK here: if the spec requires to throw A and we throw B that extends A then we follow the spec And if there is a TCK test that verifies that we throw A and only A then the test is invalid and we will not have to pass it Sometimes it is an easy fix to throw A rather then B. But there could be two RI methods - one throwing A and another one throwing B such that in our implementation they both refer to some third method. In this case if we throw B in that 3rd method - then we conform the spec, we won't break existing apps and it might cause design weakening if we choose to go coping how RI works. So if the fix is easy then I'd agree to what folks say here, but in general case I'd not set the rule to follow RI this way. Thanks, Mikhail 2006/4/24, Vladimir Gorr <[EMAIL PROTECTED]>: > The answer to this question (in my opinion) depends on how TCK processes > similar situations. > If we want to successfully perform this suite on Harmony we should be > compatible with RI. > For certain there are a lot of tests into TCK will fail due to this reason > and we should be ready for this. > > Thanks, > Vladimir. > > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Look at HARMONY-387. > > > > Example: > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > > <0, while RI throws IndexOutOfBoundsException. > > Specification mentions neither ArrayIndexOutOfBoundsException nor > > IndexOutOfBoundsException. > > > > > > Actually ArrayIndexOutOfBoundsException is a sub class of > > IndexOutOfBoundsException. > > > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" is > > true. > > > > But do we have to throw exactly those exceptions that are thrown by RI? > > > > > > Can we throw > > o.a.h.VMRisenNPE that extends NullPointerException? > > > > What if they throw kind of > > sun.internal.SunFavoriteSubClassOfNullPointerException ? > > > > Thanks, > > Mikhail > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r396013 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java test/java/tests/api/java/net/Inet6Add
Hi,
I thought that we agreed on utilizing JUnit's exception handling (see [1]).
So the next code from added unit test doesn't follow this convention. Also
why it checks the same code twice?
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
try {
Inet6Address.getByAddress("123", addr2, 3);
} catch (UnknownHostException e) {
fail("no exception should be thrown");
}
Thanks,
Stepan.
[1] http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit_p.html
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Saturday, April 22, 2006 4:52 AM
>To: [EMAIL PROTECTED]
>Subject: svn commit: r396013 - in
>/incubator/harmony/enhanced/classlib/trunk/modules/luni/src:
>main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java
>test/java/tests/api/java/net/Inet6AddressTest.java
>
>Author: tellison
>Date: Fri Apr 21 14:52:02 2006
>New Revision: 396013
>
>URL: http://svn.apache.org/viewcvs?rev=396013&view=rev
>Log:
>Apply patch HARMONY-360 (Java 5 Enhancement: One new method
>getByAddress(String, byte[], int) in class java.net.Inet6Address)
>
>Modified:
>
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/Inet6Address.java
>
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/InetAddress.java
>
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/
>api/java/net/Inet6AddressTest.java
>
>Modified:
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/Inet6Address.java
>URL:
>http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/mod
>ules/luni/src/main/java/java/net/Inet6Address.java?rev=396013&r1=396012&r2=
>396013&view=diff
>===
>===
>---
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/Inet6Address.java (original)
>+++
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/Inet6Address.java Fri Apr 21 14:52:02 2006
>@@ -1,4 +1,4 @@
>-/* Copyright 2003, 2005 The Apache Software Foundation or its licensors,
>as applicable
>+/* Copyright 2003, 2006 The Apache Software Foundation or its licensors,
>as applicable
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
>@@ -58,7 +58,7 @@
> * @param address
> *network address
> * @param name
>- *Name assocaited with the address
>+ *Name associated with the address
> * @param scope_id
> *The scope id for link or site local addresses
> */
>@@ -71,6 +71,31 @@
> }
> }
>
>+ /**
>+ * Constructs an IPv6 address according to the given
>host,
>+ * addr and scope_id.
>+ *
>+ * @param host
>+ *hostname associated with the address
>+ * @param addr
>+ *network address
>+ * @param scope_id
>+ *the scope id for link or site local addresses
>+ * @return an Inet6Address instance
>+ * @throws UnknownHostException
>+ * if the address is null or of invalid length
>+ */
>+ public static Inet6Address getByAddress(String host, byte[] addr,
>+ int scope_id) throws UnknownHostException {
>+ if (null == addr || 16 != addr.length) {
>+ throw new UnknownHostException("Illegal ipv6 address");
>+ }
>+ if(scope_id < 0){
>+ scope_id = 0;
>+ }
>+ return new Inet6Address(addr, host, scope_id);
>+ }
>+
> /**
> * Constructs an InetAddress, representing the address
>and
> * hostName and scope_id
>
>Modified:
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/InetAddress.java
>URL:
>http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/mod
>ules/luni/src/main/java/java/net/InetAddress.java?rev=396013&r1=396012&r2=3
>96013&view=diff
>===
>===
>---
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/InetAddress.java (original)
>+++
>incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/n
>et/InetAddress.java Fri Apr 21 14:52:02 2006
>@@ -1,4 +1,4 @@
>-/* Copyright 1998, 2005 The Apache Software Foundation or its licensors,
>as applicable
>+/* Copyright 1998, 2006 The Apache Software Foundation or its licensors,
>as applicable
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
>@@ -813,7 +813,7 @@
>throws UnknownHostException {
> // just call the method by the same name passing in a default
>scope id
> // of 0
>- return getByAddress(hostName, ipAddress, 0);
>+ return getByAddressInternal(hostName, ipAddress, 0);
> }
>
> /**
>@@ -837,7 +837,7 @@
> *
> * @throws UnknownHostException
> */
>- static InetAddress getByAddress(String
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
2006/4/24, Anton Avtamonov <[EMAIL PROTECTED]>: > On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > Look at HARMONY-387. > > > > Example: > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > > <0, while RI throws IndexOutOfBoundsException. > > Specification mentions neither ArrayIndexOutOfBoundsException nor > > IndexOutOfBoundsException. > > > > > > Actually ArrayIndexOutOfBoundsException is a sub class of > > IndexOutOfBoundsException. > > > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" is > > true. > > > > But do we have to throw exactly those exceptions that are thrown by RI? > > I think so. If RI behavior is reasonable and doesn't contradict to the > spec (as above) we should unconditionally copy RI behavior. > > Really, why do we need additional differences even though we > absolutely sure that particular minor deviation would have no impact > on client apps? > > > > Can we throw > > o.a.h.VMRisenNPE that extends NullPointerException? > > > > What if they throw kind of > > sun.internal.SunFavoriteSubClassOfNullPointerException ? > > Yeah, in case RI operates with classes not from public API I would > propose to base on spec. Or use the nearest class from public API if > spec doesn't work for some reasons. > Actually, spec even contains sometimes references to the classes from > not public API... Really? You mean that the spec is not transitively close? Can you give an example? Thanks, Mikhail > > Wishes, > -- > Anton Avtamonov, > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
The answer to this question (in my opinion) depends on how TCK processes similar situations. If we want to successfully perform this suite on Harmony we should be compatible with RI. For certain there are a lot of tests into TCK will fail due to this reason and we should be ready for this. Thanks, Vladimir. On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > Look at HARMONY-387. > > Example: > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > <0, while RI throws IndexOutOfBoundsException. > Specification mentions neither ArrayIndexOutOfBoundsException nor > IndexOutOfBoundsException. > > > Actually ArrayIndexOutOfBoundsException is a sub class of > IndexOutOfBoundsException. > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" is > true. > > But do we have to throw exactly those exceptions that are thrown by RI? > > > Can we throw > o.a.h.VMRisenNPE that extends NullPointerException? > > What if they throw kind of > sun.internal.SunFavoriteSubClassOfNullPointerException ? > > Thanks, > Mikhail > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Look at HARMONY-387. > > Example: > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > <0, while RI throws IndexOutOfBoundsException. > Specification mentions neither ArrayIndexOutOfBoundsException nor > IndexOutOfBoundsException. > > > Actually ArrayIndexOutOfBoundsException is a sub class of > IndexOutOfBoundsException. > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" is > true. > > But do we have to throw exactly those exceptions that are thrown by RI? I think so. If RI behavior is reasonable and doesn't contradict to the spec (as above) we should unconditionally copy RI behavior. Really, why do we need additional differences even though we absolutely sure that particular minor deviation would have no impact on client apps? > Can we throw > o.a.h.VMRisenNPE that extends NullPointerException? > > What if they throw kind of > sun.internal.SunFavoriteSubClassOfNullPointerException ? Yeah, in case RI operates with classes not from public API I would propose to base on spec. Or use the nearest class from public API if spec doesn't work for some reasons. Actually, spec even contains sometimes references to the classes from not public API... Wishes, -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
