Re: [classlib] jetty based tests
Hi, Stepan, "With mock objects this can be done with no problems and HARMONY-164 demonstrates the possible way." Shall we write a mock http server for each case? It takes lots of reduplicate efforts and results in many mock http server classes in the end. In fact, for many regular tests, jetty works fine. And I also agree that for negative tests and some other special tests which jetty could not satisfy , we should use mock http server instead. What's your opnion? Thanks. On 5/23/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: Hi George, Tim I'd like to clarify the following questions: 1) Configuring As I understood we say that the server is 'embedded' when we can start/stop it within Ant without additional configuration steps. And all we need to do is just download required jars. Right? What about Eclipse users? 2) Time to run test suite May be it is hard to estimate but anyway - will the test suite run slow down if we'll use jetty instead of mock objects? How much? 3) Testing Quoting Tim from 'local server thread': "There is no way to force a server to send you a chunked response using regular HTTP headers, so in this case the server and client have an understanding that when the client asks for a particular resource the server will send it back in chunks." With mock objects this can be done with no problems and HARMONY-164 demonstrates the possible way. Also are we going to create negative tests, for example, for broken server response? I think yes. Can jetty server be used for negative testing? See other comments below On 5/22/06, George Harley wrote: > > Stepan Mishura wrote: > > On 5/19/06, Tim Ellison wrote: > >> > >> Stepan Mishura wrote: > >> > >> > I'm OK only if we separate tests with Jetty from common test suite > >> run. > >> > >> Why? > > > > > > Because each external dependency complicates 'normal' test suite run ( I > > don't want to face with situation when to run Harmony test suite I > > have to > > configure and run 20 different external servers even they are easy > > configurable). As far as I remember we agreed to use mock objects - so > > let's > > use them! For example, in this case there is no need in jetty server. > > > > I'm not against 'jetty based tests' but I'd prefer to separate such > > tests. > > > > Thanks, > > Stepan. > > > > Hi Stepan, > > Just seen this note and think that my previous append on the "Re: svn > commit: r407752" thread sums up my thoughts. Allow me to quote myself: > > > Jetty or equivalent is a good basis for such local server stubs. It is > fast, it is lightweight, Fast and lightweight as what? I saw sometimes ago java server that has jar size 4k. And jetty-6.0.0beta6.jar is 423k size. > it can be started and stopped very simply from > within Ant (so that it only runs for the duration of a specified batch > of unit tests) and may also be completely controlled from Java test code > so that we can configure its behaviour for any test case from within > that test case. Good. It's architecture means that we do not have to run it as > a complete web server but can stub out any aspect of its runtime > behaviour we wish in order to suit the purposes of the test(s). What about 'chunked response'? Can a testcase force jetty server to send it a chunked response? I don't really understand why such network tests making use of a small, > embedded server running locally would need to be considered as outside > of the "normal test flow". > Because I consider adding jetty server as precedent for adding other dependencies to the "normal test flow". I believe that "normal test flow" should be fast and lightweight as much as possible. Each additional dependency or configuration step adds a brick(even it light) to developer's large. As the result classlib test suite may become very slow and hard to configure. All I want is to understand - do we really need jetty server inside it. Thanks, Stepan. We are not talking about an external server here and we are not talking > about developers having to carry out complex configuration manoeuvres > when running the tests. That is something that nobody wants. The > motivation here is purely to get more of the java.net tests out of the > "excludes" sin bin. > > Best regards, > George > > > > 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] > >> > >> > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -
Re: [classlib] jetty based tests
Hi Andrew,
The test you've mentioned
org.apache.harmony.tests.java.net.URLConnectionTest in not in exclude list.
And it doesn't require jetty server nor mock object to pass.
I will be helpful if you can provide an example how a test case may
force jetty server to sent it chunked or broken response.
Thanks,
Stepan.
On 5/23/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
Hello, all ,
I perfer to embed jetty in our test code to avoid external server in some
test cases.
"I'm not against 'jetty based tests' but I'd prefer to separate such
tests."
Stepan, If jetty is embedded in our test case code, I think it's
unnecessary
still to seperate such tests, since there's no external dependency at all.
Consider following test case from URLConnectionTest.java, luni module:
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL("http://www.apache.org";)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail("Assert 0: expected an IllegalStateException");
} catch (IllegalStateException e) {
// expected
}
}
If we revise the test case with Jetty embedded, as following code:
public class JettySample extends TestCase {
private HttpServer server = null;
protected void setUp() throws Exception {
server = new HttpServer();
SocketListener listener = new SocketListener();
listener.setPort(80);
server.addListener(listener);
HttpContext context = new HttpContext();
context.setContextPath("/");
// currently, a folder named "webapps" is put in the project root
directory
// We could put this folder in project "support" if we decide to embed
jetty
// and configure the resource base sth. like "support/resource/...".
context.setResourceBase("webapps");
context.addHandler(new ResourceHandler());
server.addContext(context);
server.start();
}
protected void tearDown() throws Exception {
if (null != server) {
server.stop();
}
}
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL("http://localhost";)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail("Assert 0: expected an IllegalStateException");
} catch (IllegalStateException e) {
// expected
}
}
}
People could run the revised test case without any external server. And it
costs us two jars (or.mortbay.jetty.jar, commons-logging.jar) and about
300ms overhead (if log info is disabled).
Any suggestion or comment ?
Thanks!
On 5/22/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>
> On 5/19/06, Tim Ellison wrote:
> >
> > Stepan Mishura wrote:
> >
> > > I'm OK only if we separate tests with Jetty from common test suite
> run.
> >
> > Why?
>
>
> Because each external dependency complicates 'normal' test suite run ( I
> don't want to face with situation when to run Harmony test suite I have
to
> configure and run 20 different external servers even they are easy
> configurable). As far as I remember we agreed to use mock objects - so
> let's
> use them! For example, in this case there is no need in jetty server.
>
> I'm not against 'jetty based tests' but I'd prefer to separate such
tests.
>
> Thanks,
> Stepan.
>
> 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]
> >
> >
>
>
> --
> 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]
>
>
--
Andrew Zhang
China Software Development Lab, IBM
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
Hi George, Tim I'd like to clarify the following questions: 1) Configuring As I understood we say that the server is 'embedded' when we can start/stop it within Ant without additional configuration steps. And all we need to do is just download required jars. Right? What about Eclipse users? 2) Time to run test suite May be it is hard to estimate but anyway - will the test suite run slow down if we'll use jetty instead of mock objects? How much? 3) Testing Quoting Tim from 'local server thread': "There is no way to force a server to send you a chunked response using regular HTTP headers, so in this case the server and client have an understanding that when the client asks for a particular resource the server will send it back in chunks." With mock objects this can be done with no problems and HARMONY-164 demonstrates the possible way. Also are we going to create negative tests, for example, for broken server response? I think yes. Can jetty server be used for negative testing? See other comments below On 5/22/06, George Harley wrote: Stepan Mishura wrote: > On 5/19/06, Tim Ellison wrote: >> >> Stepan Mishura wrote: >> >> > I'm OK only if we separate tests with Jetty from common test suite >> run. >> >> Why? > > > Because each external dependency complicates 'normal' test suite run ( I > don't want to face with situation when to run Harmony test suite I > have to > configure and run 20 different external servers even they are easy > configurable). As far as I remember we agreed to use mock objects - so > let's > use them! For example, in this case there is no need in jetty server. > > I'm not against 'jetty based tests' but I'd prefer to separate such > tests. > > Thanks, > Stepan. > Hi Stepan, Just seen this note and think that my previous append on the "Re: svn commit: r407752" thread sums up my thoughts. Allow me to quote myself: Jetty or equivalent is a good basis for such local server stubs. It is fast, it is lightweight, Fast and lightweight as what? I saw sometimes ago java server that has jar size 4k. And jetty-6.0.0beta6.jar is 423k size. it can be started and stopped very simply from within Ant (so that it only runs for the duration of a specified batch of unit tests) and may also be completely controlled from Java test code so that we can configure its behaviour for any test case from within that test case. Good. It's architecture means that we do not have to run it as a complete web server but can stub out any aspect of its runtime behaviour we wish in order to suit the purposes of the test(s). What about 'chunked response'? Can a testcase force jetty server to send it a chunked response? I don't really understand why such network tests making use of a small, embedded server running locally would need to be considered as outside of the "normal test flow". Because I consider adding jetty server as precedent for adding other dependencies to the "normal test flow". I believe that "normal test flow" should be fast and lightweight as much as possible. Each additional dependency or configuration step adds a brick(even it light) to developer's large. As the result classlib test suite may become very slow and hard to configure. All I want is to understand - do we really need jetty server inside it. Thanks, Stepan. We are not talking about an external server here and we are not talking about developers having to carry out complex configuration manoeuvres when running the tests. That is something that nobody wants. The motivation here is purely to get more of the java.net tests out of the "excludes" sin bin. Best regards, George > 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] >> >> > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Ah, I only checked the bug type just now, I just noticed that the "non-bug differences from RI" is not type but component. Sorry and thanks:). Mikhail Loenko wrote: Hi Paulex I've changed JIRA category to "non-bug differences from RI" just before I closed the bug Thanks, Mikhail 2006/5/23, Paulex Yang <[EMAIL PROTECTED]>: Currently Mikhail marked this issue as "won't fix" with comments of " non-bug difference from RI". I remember there is a similar category in JIRA(I just cannot recall the exact name, but it should be obvious), is there any chance in JIRA system to change this issue's category to that one? I think it will be easier to search later. If not, how about raise another one in that "non-bug difference from RI" category and add a link to 410? Vladimir Strigun wrote: > Hi Andrew, > > Thanks for your answer, please see my comments inside. > > On 5/22/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: >> Hi, Mikhail and Vladimir, >> >> I'd rather consider it as compatibility bug and close it as wontfix. > > Yes, we can close the issue as wontfix with compatibility comments, > but I think we should put some description to Wiki. Or possible you > can suggest more appropriate place for this. > >> "Did I get it right that both solutions do not contradict to the spec >> and >> that RI acts as the second one?" >> >> Partly right. Vladimir, maybe as you know, deep studying on decode >> will show >> many RI's unreasonable behaviours. >> >> Since RI's behaviour is not logical and the spec description is very >> vague >> in some situations (e.g. decode state defination, in/out buffer poistion >> defination), > > I can't say that RI's behaviour is not logical, but I can agree that > decoding process implemented in Harmony is more convenient for > developers (you don't need to get undecoded part from buffer and put > it to the next decoding operation). > >> we finally decided not to follow RI's behaviour. >> >> IMO, current Harmony implementation complies with spec strictly, acts in >> logical way and also doesn't affect end-users. >> So I'd rather consider it as compatibility bug and close it as wontfix. > > Corresponding to my previous comment, I can't agree that Harmony > strictly comply with the spec, it's just our understanding of the > spec. That's why I'd like to document this behaviour. > > > Thanks. > Vladimir. > >> What's your opnion? >> >> Thanks. >> >> >> On 5/15/06, Vladimir Strigun <[EMAIL PROTECTED]> wrote: >> > >> > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> > > 2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>: >> > > > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> > > > > Vladimir, Andrew >> > > > > >> > > > > 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>: >> > > > > > Here I propose two solutions: >> > > > > > >> > > > > > 1. Set the ByteBuffer to the limit, and store the remaining >> > ByteBuffer in >> > > > > > decoder. Invokers doesn't care the position of in. If the >> result >> > is >> > > > > > UNDERFLOW and there're furthur input, just pass the new >> input to >> > the >> > > > > > decoder. It's a typical streaming decoder. That's what >> Harmony >> > does >> > > > > > currently. >> > > > > > >> > > > > > 2. Decoder doesn't store remaining ByteBuffer. Position of >> "in" is >> > set to >> > > > > > indicate the remaining ByteBuffer. Invoker should take care to >> > generate new >> > > > > > input ByteBuffer for next invocation. RI acts in this way. >> > > > > > >> > > > > > Both are acceptable. >> > > > > >> > > > > >> > > > > Did I get it right that both solutions do not contradict to >> the spec >> > > > > and that RI acts as the second one? >> > > > >> > > > Mikhail, >> > > > >> > > > you absolutely right. I think this issue could be closed, but >> possibly >> > > > it would be better to mark it as non-bug difference from RI. >> > > > Richard, what do you think? >> > > >> > > In this case according to our compatibility guidelines we should >> switch >> > > behavior to RI-like. >> > >> > Andrew, >> > >> > what do you think about it? I think we should mark it as compatibility >> > bug and close it as wontfix. If we will switch to RI behaviour, we >> > need to check all decoding operations in java.io package and possibly >> > correct some methods. >> > >> > Thanks. >> > Vladimir. >> > >> > >> > > Thanks, >> > > Mikhail >> > > >> > > >> > > >> > > > >> > > > >> > > > Thanks. >> > > > Vladimir. >> > > > >> > > > > Thanks, >> > > > > Mikhail >> > > > > >> > > > > >> > > > > > >> > > > > > However, I think solution 1 is more reasonable. >> > > > > > >> > > > > > "Is it possible to store bytes in decoder, support streaming >> > decoding, and, >> > > > > > at the same time sets correct position in input buffer >> after each >> > operation? >> > > > > > " >> > > > > > >> > > > > > Yes. In fact, your patch will make Harmony act as the >> description >> > above. >> > > > > > >> > > > > > However, I don't think it solve the problem. Maybe invoker >> is more >
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Hi Paulex I've changed JIRA category to "non-bug differences from RI" just before I closed the bug Thanks, Mikhail 2006/5/23, Paulex Yang <[EMAIL PROTECTED]>: Currently Mikhail marked this issue as "won't fix" with comments of " non-bug difference from RI". I remember there is a similar category in JIRA(I just cannot recall the exact name, but it should be obvious), is there any chance in JIRA system to change this issue's category to that one? I think it will be easier to search later. If not, how about raise another one in that "non-bug difference from RI" category and add a link to 410? Vladimir Strigun wrote: > Hi Andrew, > > Thanks for your answer, please see my comments inside. > > On 5/22/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: >> Hi, Mikhail and Vladimir, >> >> I'd rather consider it as compatibility bug and close it as wontfix. > > Yes, we can close the issue as wontfix with compatibility comments, > but I think we should put some description to Wiki. Or possible you > can suggest more appropriate place for this. > >> "Did I get it right that both solutions do not contradict to the spec >> and >> that RI acts as the second one?" >> >> Partly right. Vladimir, maybe as you know, deep studying on decode >> will show >> many RI's unreasonable behaviours. >> >> Since RI's behaviour is not logical and the spec description is very >> vague >> in some situations (e.g. decode state defination, in/out buffer poistion >> defination), > > I can't say that RI's behaviour is not logical, but I can agree that > decoding process implemented in Harmony is more convenient for > developers (you don't need to get undecoded part from buffer and put > it to the next decoding operation). > >> we finally decided not to follow RI's behaviour. >> >> IMO, current Harmony implementation complies with spec strictly, acts in >> logical way and also doesn't affect end-users. >> So I'd rather consider it as compatibility bug and close it as wontfix. > > Corresponding to my previous comment, I can't agree that Harmony > strictly comply with the spec, it's just our understanding of the > spec. That's why I'd like to document this behaviour. > > > Thanks. > Vladimir. > >> What's your opnion? >> >> Thanks. >> >> >> On 5/15/06, Vladimir Strigun <[EMAIL PROTECTED]> wrote: >> > >> > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> > > 2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>: >> > > > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> > > > > Vladimir, Andrew >> > > > > >> > > > > 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>: >> > > > > > Here I propose two solutions: >> > > > > > >> > > > > > 1. Set the ByteBuffer to the limit, and store the remaining >> > ByteBuffer in >> > > > > > decoder. Invokers doesn't care the position of in. If the >> result >> > is >> > > > > > UNDERFLOW and there're furthur input, just pass the new >> input to >> > the >> > > > > > decoder. It's a typical streaming decoder. That's what >> Harmony >> > does >> > > > > > currently. >> > > > > > >> > > > > > 2. Decoder doesn't store remaining ByteBuffer. Position of >> "in" is >> > set to >> > > > > > indicate the remaining ByteBuffer. Invoker should take care to >> > generate new >> > > > > > input ByteBuffer for next invocation. RI acts in this way. >> > > > > > >> > > > > > Both are acceptable. >> > > > > >> > > > > >> > > > > Did I get it right that both solutions do not contradict to >> the spec >> > > > > and that RI acts as the second one? >> > > > >> > > > Mikhail, >> > > > >> > > > you absolutely right. I think this issue could be closed, but >> possibly >> > > > it would be better to mark it as non-bug difference from RI. >> > > > Richard, what do you think? >> > > >> > > In this case according to our compatibility guidelines we should >> switch >> > > behavior to RI-like. >> > >> > Andrew, >> > >> > what do you think about it? I think we should mark it as compatibility >> > bug and close it as wontfix. If we will switch to RI behaviour, we >> > need to check all decoding operations in java.io package and possibly >> > correct some methods. >> > >> > Thanks. >> > Vladimir. >> > >> > >> > > Thanks, >> > > Mikhail >> > > >> > > >> > > >> > > > >> > > > >> > > > Thanks. >> > > > Vladimir. >> > > > >> > > > > Thanks, >> > > > > Mikhail >> > > > > >> > > > > >> > > > > > >> > > > > > However, I think solution 1 is more reasonable. >> > > > > > >> > > > > > "Is it possible to store bytes in decoder, support streaming >> > decoding, and, >> > > > > > at the same time sets correct position in input buffer >> after each >> > operation? >> > > > > > " >> > > > > > >> > > > > > Yes. In fact, your patch will make Harmony act as the >> description >> > above. >> > > > > > >> > > > > > However, I don't think it solve the problem. Maybe invoker >> is more >> > > > > > confusable and may think: >> > > > > > >> > > > > > "Is the remaining bytebuffer maintained in decoder or in ? >> Shall >> > I get the >> > > > > > remaining buffer from
Re: [classlib] jetty based tests
Hello, all ,
I perfer to embed jetty in our test code to avoid external server in some
test cases.
"I'm not against 'jetty based tests' but I'd prefer to separate such tests."
Stepan, If jetty is embedded in our test case code, I think it's unnecessary
still to seperate such tests, since there's no external dependency at all.
Consider following test case from URLConnectionTest.java, luni module:
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL("http://www.apache.org";)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail("Assert 0: expected an IllegalStateException");
} catch (IllegalStateException e) {
// expected
}
}
If we revise the test case with Jetty embedded, as following code:
public class JettySample extends TestCase {
private HttpServer server = null;
protected void setUp() throws Exception {
server = new HttpServer();
SocketListener listener = new SocketListener();
listener.setPort(80);
server.addListener(listener);
HttpContext context = new HttpContext();
context.setContextPath("/");
// currently, a folder named "webapps" is put in the project root
directory
// We could put this folder in project "support" if we decide to embed
jetty
// and configure the resource base sth. like "support/resource/...".
context.setResourceBase("webapps");
context.addHandler(new ResourceHandler());
server.addContext(context);
server.start();
}
protected void tearDown() throws Exception {
if (null != server) {
server.stop();
}
}
/**
* @tests java.net.URLConnection#setUseCaches(boolean)
*/
public void test_setUseCachesZ() throws MalformedURLException, IOException
{
// Regression for HARMONY-71
URLConnection u = new URLConnection(new URL("http://localhost";)) {
public void connect() {
connected = true;
}
};
u.connect();
try {
u.setUseCaches(true);
fail("Assert 0: expected an IllegalStateException");
} catch (IllegalStateException e) {
// expected
}
}
}
People could run the revised test case without any external server. And it
costs us two jars (or.mortbay.jetty.jar, commons-logging.jar) and about
300ms overhead (if log info is disabled).
Any suggestion or comment ?
Thanks!
On 5/22/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 5/19/06, Tim Ellison wrote:
>
> Stepan Mishura wrote:
>
> > I'm OK only if we separate tests with Jetty from common test suite
run.
>
> Why?
Because each external dependency complicates 'normal' test suite run ( I
don't want to face with situation when to run Harmony test suite I have to
configure and run 20 different external servers even they are easy
configurable). As far as I remember we agreed to use mock objects - so
let's
use them! For example, in this case there is no need in jetty server.
I'm not against 'jetty based tests' but I'd prefer to separate such tests.
Thanks,
Stepan.
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]
>
>
--
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]
--
Andrew Zhang
China Software Development Lab, IBM
Re: Repackaged IBM VME
Oliver Deakin wrote: Hi all, There is now a repackaged version of the IBM VME available at: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=ahdk The new VME archives are called Harmony-vme-win.IA32-v3.zip for Windows and Harmony-vme-linux.IA32-v3.tar.gz for Linux. Following discussion on the mailing list [1], the IBM VME has been reorganised into the following directory layout: | +---jre || |\---bin | | | \---default | \---vme_license The actual VME binaries are still the same as the previous version, but the new layout means it can be dropped into both the current development environment and also any future classlib jre/jdk/hdk snapshots that are taken. Since this is purely a directory layout update, those who already have a version of the IBM VME in their environment will *not* need to get the new packages. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] That's great! And we are solicitous of a new VM of Java 5. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-479) java.io.FileInputStream and FileOutputStream might cause Finalizer thread suspending
Gregory,
Sorry I response so late. I just back from a long vacation and it took
me longer time than I expected to catch up the mailing list (after all,
it's very active!). Please see my comments below.
Gregory Shimansky wrote:
Hello Paulex
I have a question about this problem. Do you know how exception in
finalizer
method affects the finalizer thread that it becomes suspended? I thought
that when calling finalize method the code should catch all exceptions
thrown by it and ignore them. AFAIK that's how finalizers are
implemented in
DRLVM. It specification it is written that
First of all, I think this issue should not happen if the spec of
FileInputStream/OutputStream doesn't require the implementation to
invoke close() in finalize() method, IMHO, generally it's not good
practice to depend on finalize(), and I guess this spec is inherited
from very early version, say, JDK 1.0, when the channel hasn't been not
introduced.
And actually I don't know exactly what happened to the finalizer thread
when the NullPointerException thrown, because, as you know, the Harmony
VME provided by IBM is only binary. What I saw is that the debugger
sometimes stops on the suspending finalizer thread at the
FileInputStream/OutputStream's close(), and the message shows that
"NullPointerException caused suspending"(maybe not exact words, but very
similar). So I tried to fix this problem in Java codes.
And I'd glad to have a try on DRLVM later, but anyway, I think it is
not bad idea to make our classlib codes more defensive and reliable.
your ideas?
"If an uncaught exception is thrown by the finalize method, the
exception is
ignored and finalization of that object terminates."
2006/5/19, Paulex Yang (JIRA) <[EMAIL PROTECTED]>:
java.io.FileInputStream and FileOutputStream might cause Finalizer
thread
suspending
Key: HARMONY-479
URL: http://issues.apache.org/jira/browse/HARMONY-479
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
If one FileInputStream instance is not constructed properly, say, the
given file doesn't exist, the constructor will throw exception but the
FileInputStream instance is still necessary to be garbage collected,
and the
spec of FileInputStream's finalize() method requires that close()
must be
invoked, but the current implementation of FileInputStream.close()(as
below) will causes NullPointerException in Finalizer thread because
channel
field has not been initialized yet.
public void close() throws IOException {
synchronized (channel) {
synchronized (this) {
if (channel.isOpen() && fd.descriptor >= 0) {
channel.close();
}
fd.descriptor = -1;
}
}
}
This issue applies to FileOutputStream, too. Test case below can
reproduce
this issue only in debugger, because it is not easy to get the handle of
Finalizer thread. Debugging the test case to the statement following the
System.gc(), the debugger will show that the Finalizer thread is
suspended
due to NullPointerException.
public class FileInputStreamTest {
public static void main(String[] args) throws Exception{
FileInputStream is = null;
try{
is = new FileInputStream(new File("nonexist"));
}catch(Exception e){
System.gc();
e.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Currently Mikhail marked this issue as "won't fix" with comments of " non-bug difference from RI". I remember there is a similar category in JIRA(I just cannot recall the exact name, but it should be obvious), is there any chance in JIRA system to change this issue's category to that one? I think it will be easier to search later. If not, how about raise another one in that "non-bug difference from RI" category and add a link to 410? Vladimir Strigun wrote: Hi Andrew, Thanks for your answer, please see my comments inside. On 5/22/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: Hi, Mikhail and Vladimir, I'd rather consider it as compatibility bug and close it as wontfix. Yes, we can close the issue as wontfix with compatibility comments, but I think we should put some description to Wiki. Or possible you can suggest more appropriate place for this. "Did I get it right that both solutions do not contradict to the spec and that RI acts as the second one?" Partly right. Vladimir, maybe as you know, deep studying on decode will show many RI's unreasonable behaviours. Since RI's behaviour is not logical and the spec description is very vague in some situations (e.g. decode state defination, in/out buffer poistion defination), I can't say that RI's behaviour is not logical, but I can agree that decoding process implemented in Harmony is more convenient for developers (you don't need to get undecoded part from buffer and put it to the next decoding operation). we finally decided not to follow RI's behaviour. IMO, current Harmony implementation complies with spec strictly, acts in logical way and also doesn't affect end-users. So I'd rather consider it as compatibility bug and close it as wontfix. Corresponding to my previous comment, I can't agree that Harmony strictly comply with the spec, it's just our understanding of the spec. That's why I'd like to document this behaviour. Thanks. Vladimir. What's your opnion? Thanks. On 5/15/06, Vladimir Strigun <[EMAIL PROTECTED]> wrote: > > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > 2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>: > > > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Vladimir, Andrew > > > > > > > > 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>: > > > > > Here I propose two solutions: > > > > > > > > > > 1. Set the ByteBuffer to the limit, and store the remaining > ByteBuffer in > > > > > decoder. Invokers doesn't care the position of in. If the result > is > > > > > UNDERFLOW and there're furthur input, just pass the new input to > the > > > > > decoder. It's a typical streaming decoder. That's what Harmony > does > > > > > currently. > > > > > > > > > > 2. Decoder doesn't store remaining ByteBuffer. Position of "in" is > set to > > > > > indicate the remaining ByteBuffer. Invoker should take care to > generate new > > > > > input ByteBuffer for next invocation. RI acts in this way. > > > > > > > > > > Both are acceptable. > > > > > > > > > > > > Did I get it right that both solutions do not contradict to the spec > > > > and that RI acts as the second one? > > > > > > Mikhail, > > > > > > you absolutely right. I think this issue could be closed, but possibly > > > it would be better to mark it as non-bug difference from RI. > > > Richard, what do you think? > > > > In this case according to our compatibility guidelines we should switch > > behavior to RI-like. > > Andrew, > > what do you think about it? I think we should mark it as compatibility > bug and close it as wontfix. If we will switch to RI behaviour, we > need to check all decoding operations in java.io package and possibly > correct some methods. > > Thanks. > Vladimir. > > > > Thanks, > > Mikhail > > > > > > > > > > > > > > > Thanks. > > > Vladimir. > > > > > > > Thanks, > > > > Mikhail > > > > > > > > > > > > > > > > > > However, I think solution 1 is more reasonable. > > > > > > > > > > "Is it possible to store bytes in decoder, support streaming > decoding, and, > > > > > at the same time sets correct position in input buffer after each > operation? > > > > > " > > > > > > > > > > Yes. In fact, your patch will make Harmony act as the description > above. > > > > > > > > > > However, I don't think it solve the problem. Maybe invoker is more > > > > > confusable and may think: > > > > > > > > > > "Is the remaining bytebuffer maintained in decoder or in ? Shall > I get the > > > > > remaining buffer from in and pass it for next invocation?" > > > > > > > > > > Anyway, we need a decision on this compatibility issue. > > > > > By the way, Vladimir, does solution one cause any problem on other > classlib > > > > > implementation? > > > > > > > > > > Any comment? > > > > > > > > > > Thanks ! > > > > > > > > > > > > > > > Vladimir Strigun commented on HARMONY-410: > > > > > -- > > > > > > > > > > Hi Richard, > > > > > > > > > > Thanks for the clarification, I agree that st
Re: jchevm status?
Weldon Washburn wrote: Please hold off the check-in for a few days. I would like to try Ivan's mods on my machine to make certain they are complete. The intention is to reduce the chance of secondary patch-up check-ins and the related blizzard of emails. No problem.. I'll wait for both (a) your confirmation and (b) Apache contributor license thingie. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Archie, Please hold off the check-in for a few days. I would like to try Ivan's mods on my machine to make certain they are complete. The intention is to reduce the chance of secondary patch-up check-ins and the related blizzard of emails. Thanks Weldon On 5/22/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: Weldon Washburn wrote: > I just now looked at 483. Good work. I'd like to check-in these mods > into svn but don't have check-in permission. I can check them in, but I think Ivan's code needs official blessing first. -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] -- Weldon Washburn 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: jchevm status?
On 22 May 2006 at 23:05, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > 2006/5/22, Archie Cobbs <[EMAIL PROTECTED]>: > > Weldon Washburn wrote: > > > I just now looked at 483. Good work. I'd like to check-in these > > > mods into svn but don't have check-in permission. > > > > I can check them in, but I think Ivan's code needs official blessing > > first. > > What kind of official blessing? Is something required from me? Archie can answer for himself if this isn't what he meant but . . . Have you completed an Apache Individual Contributor License Agreement and an Authorized Contributor Questionnaire? See the "Policy for Committers" section of: http://incubator.apache.org/harmony/contribution_policy.html Small changes might be integrated without the documentation - on the basis that backing them out wouldn't be too painful - but generally I think it is preferable to have the documents before code is committed. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY-199 Contents
Ok. I will add a coment to JIRA Miguel On 5/22/06, George Harley <[EMAIL PROTECTED]> wrote: Hi Miguel, A list of files that you think can be removed would be ideal. Maybe add it as a comment to the JIRA ? Thank you, George Miguel Montes wrote: > George: > Ok. Would you like me to send a pruned version, or a list of files to be > removed? > Miguel > > On 5/18/06, George Harley <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> While preparing to commit the javax.crypto and java.math contributions >> attached to HARMONY-199 I noticed that there is a lot of extra test >> artefacts in there that are pretty major in size. Not talking about test >> resources here (e.g. serialization data files etc) but stuff like XML >> documents detailing the results of tests conducted in January >> (itc/doc/testing/crypto/Linux/AllProviders.xml which weighs in at over >> 25 MB !!!), spreadsheets of performance comparison figures >> (itc/doc/testing/math/Windows/Performance Math Windows.xls which is >> about 800K) and so on. >> >> If no one objects I would like to prune these files out of the initial >> commit. No modifications to any content, just remove what appears (to my >> eyes) to be extra data scooped up when the zips were created by ITC. >> >> Daniel, Miguel and the rest of the ITC team : assuming that you agree >> with my observation it would be great if you could advise me on what can >> be removed from the contribution. >> >> >> Best regards, >> George >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Miguel Montes
Re: jchevm status?
2006/5/22, Archie Cobbs <[EMAIL PROTECTED]>: Weldon Washburn wrote: > I just now looked at 483. Good work. I'd like to check-in these mods > into svn but don't have check-in permission. I can check them in, but I think Ivan's code needs official blessing first. What kind of official blessing? Is something required from me? -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Weldon Washburn wrote: I just now looked at 483. Good work. I'd like to check-in these mods into svn but don't have check-in permission. I can check them in, but I think Ivan's code needs official blessing first. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (HARMONY-337) Contribution of RMI framework
Mark, Well, I see your point. This strategy sounds reasonable, thank you very much for your efforts on integration. Confusion is really not a problem, as it's the easiest problem to resolve. :) Vasily -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 10:25 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-337) Contribution of RMI framework On 22 May 2006 at 21:20, "Zakharov, Vasily M" <[EMAIL PROTECTED]> wrote: > > By the way, if "rmi2" module is ITC donation and "rmi3" module is Intel > donation, then what is the contents of "rmi" module? See HARMONY-471. This JIRA was the first part of my trying to replace the rmi stubs with the contents of modules/rmi2. It is incomplete because the tests still need to be moved - and updated. modules/rmi2 should probably go away once the migration of tests is completed. Incidentally, don't read too much in to the names rmi, rmi2, rmi3. The main reason I didn't do the changes in place in the rmi2 tree was because of the difficulty of creating a patches/recipes for the moves and creation of new files. Specifically, you can't easily do "svn move blah blah.old" and then add a new blah with "svn add blah" without doing a commit in between. > And how the process of getting the actual RMI implementation for Harmony > is going to go? The above JIRA also introduce an ant variable, hy.rmi.module, that allows an rmi implementation to be selected at build time - using "ant -Dhy.rmi.module=rmi3". I hope that this will allow several implementations to co-exist and be easily evaluated. It may be that in order to take the best from both contributions a third implementation will be developed. The mechanism I put in place should allow for this. Unless someone beats me too it, I will try to construct a JIRA that integrates the modules/rmi3 tree. (I might try to do this one without moving to yet another new directory tree and confusing people even more.) Regards, Mark. > -Original Message- > From: Vasily Zakharov (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Monday, May 22, 2006 9:02 PM > To: Zakharov, Vasily M > Subject: [jira] Commented: (HARMONY-337) Contribution of RMI framework > > [ > http://issues.apache.org/jira/browse/HARMONY-337?page=3Dcomments#action_ 1= > 2 > 412803 ]=20 > > Vasily Zakharov commented on HARMONY-337: > - > > George, > > Thank you very much for the bringover, looks like rmi3 module is ok. > > Vasily > > > > Contribution of RMI framework > > - > > > > Key: HARMONY-337 > > URL: http://issues.apache.org/jira/browse/HARMONY-337 > > Project: Harmony > > Type: New Feature > > > Components: Contributions > > Reporter: Vasily Zakharov > > Assignee: George Harley > > Attachments: rmi_src_20060410_2125-Harmony.zip > > > > Contains independent implementation of Remote Method Invocation (RMI) > framework and some unit tests. > > The RMI framework enables an object in one virtual machine to call > methods of an object in another one, to create applications distributed > on various Java virtual machines on the same or different hosts. > > For more information see the documentation included. > > --=20 > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: >http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: >http://www.atlassian.com/software/jira > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-337) Contribution of RMI framework
On 22 May 2006 at 21:20, "Zakharov, Vasily M" <[EMAIL PROTECTED]> wrote: > > By the way, if "rmi2" module is ITC donation and "rmi3" module is Intel > donation, then what is the contents of "rmi" module? See HARMONY-471. This JIRA was the first part of my trying to replace the rmi stubs with the contents of modules/rmi2. It is incomplete because the tests still need to be moved - and updated. modules/rmi2 should probably go away once the migration of tests is completed. Incidentally, don't read too much in to the names rmi, rmi2, rmi3. The main reason I didn't do the changes in place in the rmi2 tree was because of the difficulty of creating a patches/recipes for the moves and creation of new files. Specifically, you can't easily do "svn move blah blah.old" and then add a new blah with "svn add blah" without doing a commit in between. > And how the process of getting the actual RMI implementation for Harmony > is going to go? The above JIRA also introduce an ant variable, hy.rmi.module, that allows an rmi implementation to be selected at build time - using "ant -Dhy.rmi.module=rmi3". I hope that this will allow several implementations to co-exist and be easily evaluated. It may be that in order to take the best from both contributions a third implementation will be developed. The mechanism I put in place should allow for this. Unless someone beats me too it, I will try to construct a JIRA that integrates the modules/rmi3 tree. (I might try to do this one without moving to yet another new directory tree and confusing people even more.) Regards, Mark. > Vasily Zakharov > Intel Middleware Products Division > > > -Original Message- > From: Vasily Zakharov (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Monday, May 22, 2006 9:02 PM > To: Zakharov, Vasily M > Subject: [jira] Commented: (HARMONY-337) Contribution of RMI framework > > [ > http://issues.apache.org/jira/browse/HARMONY-337?page=3Dcomments#action_1= > 2 > 412803 ]=20 > > Vasily Zakharov commented on HARMONY-337: > - > > George, > > Thank you very much for the bringover, looks like rmi3 module is ok. > > Vasily > > > > Contribution of RMI framework > > - > > > > Key: HARMONY-337 > > URL: http://issues.apache.org/jira/browse/HARMONY-337 > > Project: Harmony > > Type: New Feature > > > Components: Contributions > > Reporter: Vasily Zakharov > > Assignee: George Harley > > Attachments: rmi_src_20060410_2125-Harmony.zip > > > > Contains independent implementation of Remote Method Invocation (RMI) > framework and some unit tests. > > The RMI framework enables an object in one virtual machine to call > methods of an object in another one, to create applications distributed > on various Java virtual machines on the same or different hosts. > > For more information see the documentation included. > > --=20 > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: >http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: >http://www.atlassian.com/software/jira > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (HARMONY-337) Contribution of RMI framework
By the way, if "rmi2" module is ITC donation and "rmi3" module is Intel donation, then what is the contents of "rmi" module? And how the process of getting the actual RMI implementation for Harmony is going to go? Vasily Zakharov Intel Middleware Products Division -Original Message- From: Vasily Zakharov (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 9:02 PM To: Zakharov, Vasily M Subject: [jira] Commented: (HARMONY-337) Contribution of RMI framework [ http://issues.apache.org/jira/browse/HARMONY-337?page=comments#action_12 412803 ] Vasily Zakharov commented on HARMONY-337: - George, Thank you very much for the bringover, looks like rmi3 module is ok. Vasily > Contribution of RMI framework > - > > Key: HARMONY-337 > URL: http://issues.apache.org/jira/browse/HARMONY-337 > Project: Harmony > Type: New Feature > Components: Contributions > Reporter: Vasily Zakharov > Assignee: George Harley > Attachments: rmi_src_20060410_2125-Harmony.zip > > Contains independent implementation of Remote Method Invocation (RMI) framework and some unit tests. > The RMI framework enables an object in one virtual machine to call methods of an object in another one, to create applications distributed on various Java virtual machines on the same or different hosts. > For more information see the documentation included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [rmi] package comparison
Daniel, Sure, I use Sun's J2SE 5.0. Here's how I run the tests: c:\jdk1.5.0_05\bin\java -cp junit.jar;test.jar;stubs_dir -Djava.security.policy=all.policy Are there some additional configurations I should provide? Below is the list of tests that fail, with the respective stack traces I get. TestSuiteRMIActivation: testCreateGroup002 junit.framework.AssertionFailedError: Should not raise an Exception... java.rmi.activation.ActivationException: exception creating group; nested exception is: java.lang.NullPointerException at ar.org.fitc.test.rmi.activation.TestActivationGroup.testCreateGroup002(U nknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at ar.org.fitc.test.rmi.activation.TestSuiteRMIActivation.main(Unknown Source) TestSuiteRMIServer: testGetClassLoader003 testGetDefaultProviderInstance002 testLoadClassStringString002 testLoadClassStringString003 testLoadClassURLString002 testLoadClassURLString003 testLoadProxyClass005 testSetSocketFactory001 java.lang.NoClassDefFoundError at java.lang.System.setSecurityManager0(System.java:275) at java.lang.System.setSecurityManager(System.java:244) at ar.org.fitc.test.rmi.server.TestRMIClassLoader.testGetClassLoader003(Unk nown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at ar.org.fitc.test.rmi.server.TestSuiteRMIServer.main(Unknown Source) TestSuiteRMIServer: testUID001 testUID002 testHashCode001 testHashCode002 testHashCode003 testHashCode004 testEquals001 testEquals002 testEquals003 testEquals004 testEquals005 testEquals006 testEquals007 testEquals008 testEquals009 testEquals010 testEquals011 testEquals012 testToString005 java.lang.NoClassDefFoundError at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:160) at java.security.AccessController.doPrivileged(Native Method) at sun.security.provider.SeedGenerator.getSystemEntropy(SeedGenerator.java: 145) at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:170 ) at java.security.SecureRandom.nextBytes(SecureRandom.java:413) at java.security.SecureRandom.next(SecureRandom.java:435) at java.util.Random.nextInt(Random.java:188) at java.rmi.server.UID.(UID.java:98) at ar.org.fitc.test.rmi.server.TestUID.testUID001(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at ar.org.fitc.test.rmi.server.TestSuiteRMIServer.main(Unknown Source) TestSuiteRMIServer2: testGetClientHost002(ar.org.fitc.test.rmi.server.TestUnicastRemoteObject ) testGetClientHost002(ar.org.fitc.test.rmi.server.TestRemoteServer) junit.framework.AssertionFailedError: Failed with: java.rmi.ServerError: Error occurred in server thread; nested exception is: junit.framework.ComparisonFailure: The client is localhost expected:<...151.151> but was:<...-105.-105> at ar.org.fitc.test.rmi.server.TestRemoteServer.testGetClientHost002(Unknow n Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at ar.org.fitc.test.rmi.server.TestSuiteRMIServer2.main(Unknown Source) Thanks, Vasily -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Thursday, May 18, 2006 10:50 PM To: harmony-dev@incubator.apache.org Subject: Re: [rmi] package comparison Vasily, test are not implementation specific; they were developed against the RI and all of them are supposed to work fine with RI. I believe the issue is due to the jre version you are using, remember that we have always assumed Sun's J2SE 5.0 as the RI. Daniel - Original Message - From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 17, 2006 3:14 PM Subject: RE: [rmi] package comparison Daniel, I've started with trying to run the unit tests on reference imlementation, and some tests failed. So the question is, are those tests implementation specific or not, and whether there're some expected failures that should occur on RI? Vasily -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 17, 2006 7:39 PM To: harmony-dev@incubator.apache.org Subject: Re: [rmi] pac
Repackaged IBM VME
Hi all, There is now a repackaged version of the IBM VME available at: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=ahdk The new VME archives are called Harmony-vme-win.IA32-v3.zip for Windows and Harmony-vme-linux.IA32-v3.tar.gz for Linux. Following discussion on the mailing list [1], the IBM VME has been reorganised into the following directory layout: | +---jre || |\---bin | | | \---default | \---vme_license The actual VME binaries are still the same as the previous version, but the new layout means it can be dropped into both the current development environment and also any future classlib jre/jdk/hdk snapshots that are taken. Since this is purely a directory layout update, those who already have a version of the IBM VME in their environment will *not* need to get the new packages. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY-199 Contents
Hi Miguel, A list of files that you think can be removed would be ideal. Maybe add it as a comment to the JIRA ? Thank you, George Miguel Montes wrote: George: Ok. Would you like me to send a pruned version, or a list of files to be removed? Miguel On 5/18/06, George Harley <[EMAIL PROTECTED]> wrote: Hi, While preparing to commit the javax.crypto and java.math contributions attached to HARMONY-199 I noticed that there is a lot of extra test artefacts in there that are pretty major in size. Not talking about test resources here (e.g. serialization data files etc) but stuff like XML documents detailing the results of tests conducted in January (itc/doc/testing/crypto/Linux/AllProviders.xml which weighs in at over 25 MB !!!), spreadsheets of performance comparison figures (itc/doc/testing/math/Windows/Performance Math Windows.xls which is about 800K) and so on. If no one objects I would like to prune these files out of the initial commit. No modifications to any content, just remove what appears (to my eyes) to be extra data scooped up when the zips were created by ITC. Daniel, Miguel and the rest of the ITC team : assuming that you agree with my observation it would be great if you could advise me on what can be removed from the contribution. Best regards, George - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] jetty based tests
Stepan Mishura wrote: On 5/19/06, Tim Ellison wrote: Stepan Mishura wrote: > I'm OK only if we separate tests with Jetty from common test suite run. Why? Because each external dependency complicates 'normal' test suite run ( I don't want to face with situation when to run Harmony test suite I have to configure and run 20 different external servers even they are easy configurable). As far as I remember we agreed to use mock objects - so let's use them! For example, in this case there is no need in jetty server. I'm not against 'jetty based tests' but I'd prefer to separate such tests. Thanks, Stepan. Hi Stepan, Just seen this note and think that my previous append on the "Re: svn commit: r407752" thread sums up my thoughts. Allow me to quote myself: Jetty or equivalent is a good basis for such local server stubs. It is fast, it is lightweight, it can be started and stopped very simply from within Ant (so that it only runs for the duration of a specified batch of unit tests) and may also be completely controlled from Java test code so that we can configure its behaviour for any test case from within that test case. It's architecture means that we do not have to run it as a complete web server but can stub out any aspect of its runtime behaviour we wish in order to suit the purposes of the test(s). I don't really understand why such network tests making use of a small, embedded server running locally would need to be considered as outside of the "normal test flow". We are not talking about an external server here and we are not talking about developers having to carry out complex configuration manoeuvres when running the tests. That is something that nobody wants. The motivation here is purely to get more of the java.net tests out of the "excludes" sin bin. Best regards, George 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] - 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] jetty based tests
Stepan Mishura wrote: > On 5/19/06, Tim Ellison wrote: >> >> Stepan Mishura wrote: >> >> > I'm OK only if we separate tests with Jetty from common test suite run. >> >> Why? > > > Because each external dependency complicates 'normal' test suite run ( I > don't want to face with situation when to run Harmony test suite I have to > configure and run 20 different external servers even they are easy > configurable). As far as I remember we agreed to use mock objects - so > let's > use them! For example, in this case there is no need in jetty server. > > I'm not against 'jetty based tests' but I'd prefer to separate such tests. AIUI the plan is to embed Jetty into the harmony test suite, not call it out as a dependency we expect people to configure. This is in contrast to, say, tests for the DNS provider that we will likely want to use mocks objects to test rather than embed/require an external DNS server. 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: svn commit: r407752 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/org/apache/harmony/luni/internal/net/www/protocol/http/HttpURLConnection.java
Stepan Mishura wrote:
Hi George,
On 5/19/06, George Harley wrote:
Stepan Mishura wrote:
[SNIP]
Hi Stepan,
Is your preference to separate out all "remote server dependent" tests
(that could be made work with a locally installed server) from the
normal test flow ?
Yes.
For instance, have them run in a separate junit batch
that was dependent on an Ant property value (e.g. run.net.tests) ?
Another possibility is to invoke the tests under discussion via a JUnit
TestSuite - again, perhaps depending on an Ant property.
Basically I want to be sure here that we are talking about a logical
separation of the tests using Ant and JUnit techniques and not a
physical separation of files in the file system.
We can separate them in any acceptable way. All I want that we clearly
define which tests require 'remote server' to be run and keep these test
separately from 'normal test flow'. For this particular case I believe
that
there is no need in 'remote server' and we can use local server stub.
Thanks,
Stepan.
Hi Stepan,
I agree that we can modify this test so that there is no need for a
remote server and that we can use something local. Jetty or equivalent
is a good basis for such local server stubs. It is fast, it is
lightweight, it can be started and stopped very simply from within Ant
(so that it only runs for the duration of a specified batch of unit
tests) and may also be completely controlled from Java test code so that
we can configure its behaviour for any test case from within that test
case. It's architecture means that we do not have to run it as a
complete web server but can stub out any aspect of its runtime behaviour
we wish in order to suit the purposes of the test(s).
I don't really understand why such network tests making use of a small,
embedded server running locally would need to be considered as outside
of the "normal test flow".
Best regards,
George
Best regards,
George
>
>
>> Best regards,
>> George
>>
>>
>>
>> Stepan Mishura wrote:
>> > Richard, George
>> >
>> > I'm not fan of tests that depend on network connection. Is it
>> > necessary for
>> > this test:
>> >
>> > + public void test_getOutputStream_afterConnection() throws
>> Exception {
>> > + URLConnection uc = new
>> > URL("http://www.apache.org";).openConnection> ").openconnection/>
>> >
>> > ();
>> > + uc.setDoOutput(true);
>> > + uc.connect();
>> > + assertNotNull(uc.getOutputStream());
>> > + }
>> >
>> > Thanks,
>> > Stepan Mishura
--
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: [jchevm] class loader questions
Method class$ is synthetic and is produced by the Java compiler for some class which references some class by the construct .class in its method' code. For example, the code --- Class c1 = Object.class; --- will produce the following Java assembly for method class$ --- Method name:"class$" static Signature: 26=(java.lang.String)java.lang.Class Attribute "Code", length:50, max_stack:3, max_locals:2, code_length:18 0: aload_0 1: invokestatic #1= 4: areturn 5: astore_1 6: new #3= 9: dup 10: aload_1 11: invokevirtual #4= 14: invokespecial #5= ( java.lang.String)void> 17: athrow Exceptions (count: 1): start: 0, end: 4, handler: 5, type: 2=java.lang.ClassNotFoundException Attribute "LineNumberTable", length:6, count: 1 line: 4 at pc: 0 Attribute "Synthetic", length:0 --- On 5/22/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: There is a problem in the early boot stage with the method "class$" from the current version of java/lang/Character. What is exact problem you are experiencing with this method? How did you get to the fact it is related to java/lang/Character? Pavel Pervov, Intel Middleware Products Division.
Re: [jchevm] class loader questions
Weldon,
I confused this$ and class$ fields in your example.
Here is another example where class$ method is generated and used:
public class Test2 {
public static void main(String[] args) {
Class cls = Test2.class;
}
}
and javap output is:
public class Test2 extends java.lang.Object{
static java.lang.Class class$Test2;
public Test2();
Code:
0:aload_0
1:invokespecial#6; //Method java/lang/Object."":()V
4:return
public static void main(java.lang.String[]);
Code:
0:getstatic#7; //Field class$Test2:Ljava/lang/Class;
3:ifnonnull18
6:ldc#8; //String Test2
8:invokestatic#9; //Method
class$:(Ljava/lang/String;)Ljava/lang/Class;
11:dup
12:putstatic#7; //Field class$Test2:Ljava/lang/Class;
15:goto21
18:getstatic#7; //Field class$Test2:Ljava/lang/Class;
21:astore_1
22:return
static java.lang.Class class$(java.lang.String);
Code:
0:aload_0
1:invokestatic#1; //Method
java/lang/Class.forName:(Ljava/lang/String;)Ljava/lang/Class;
4:areturn
5:astore_1
6:new#3; //class NoClassDefFoundError
9:dup
10:aload_1
11:invokevirtual#4; //Method
java/lang/ClassNotFoundException.getMessage:()Ljava/lang/String;
14:invokespecial#5; //Method
java/lang/NoClassDefFoundError."":(Ljava/lang/String;)V
17:athrow
Exception table:
from to target type
0 4 5 Class java/lang/ClassNotFoundException
}
On 5/22/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
--
Mikhail Fursov
Intel Middleware Products Division
Re: [jchevm] class loader questions
May be this is synthetic field (inner->parent reference)?
Check java asm for this test:
public class Test {
Object field;
public class Inner {
Inner() {
field = null;
}
}
}
public class Test$Inner extends java.lang.Object{
Test$Inner(Test);
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: aload_0
5: aload_1
6: putfield#2; //Field this$0:LTest;
9: aload_1
10: aconst_null
11: putfield#3; //Field Test.field:Ljava/lang/Object;
14: return
On 5/22/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
--
Mikhail Fursov
Intel Middleware Products Division
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Hi Andrew, Thanks for your answer, please see my comments inside. On 5/22/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: Hi, Mikhail and Vladimir, I'd rather consider it as compatibility bug and close it as wontfix. Yes, we can close the issue as wontfix with compatibility comments, but I think we should put some description to Wiki. Or possible you can suggest more appropriate place for this. "Did I get it right that both solutions do not contradict to the spec and that RI acts as the second one?" Partly right. Vladimir, maybe as you know, deep studying on decode will show many RI's unreasonable behaviours. Since RI's behaviour is not logical and the spec description is very vague in some situations (e.g. decode state defination, in/out buffer poistion defination), I can't say that RI's behaviour is not logical, but I can agree that decoding process implemented in Harmony is more convenient for developers (you don't need to get undecoded part from buffer and put it to the next decoding operation). we finally decided not to follow RI's behaviour. IMO, current Harmony implementation complies with spec strictly, acts in logical way and also doesn't affect end-users. So I'd rather consider it as compatibility bug and close it as wontfix. Corresponding to my previous comment, I can't agree that Harmony strictly comply with the spec, it's just our understanding of the spec. That's why I'd like to document this behaviour. Thanks. Vladimir. What's your opnion? Thanks. On 5/15/06, Vladimir Strigun <[EMAIL PROTECTED]> wrote: > > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > 2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>: > > > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Vladimir, Andrew > > > > > > > > 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>: > > > > > Here I propose two solutions: > > > > > > > > > > 1. Set the ByteBuffer to the limit, and store the remaining > ByteBuffer in > > > > > decoder. Invokers doesn't care the position of in. If the result > is > > > > > UNDERFLOW and there're furthur input, just pass the new input to > the > > > > > decoder. It's a typical streaming decoder. That's what Harmony > does > > > > > currently. > > > > > > > > > > 2. Decoder doesn't store remaining ByteBuffer. Position of "in" is > set to > > > > > indicate the remaining ByteBuffer. Invoker should take care to > generate new > > > > > input ByteBuffer for next invocation. RI acts in this way. > > > > > > > > > > Both are acceptable. > > > > > > > > > > > > Did I get it right that both solutions do not contradict to the spec > > > > and that RI acts as the second one? > > > > > > Mikhail, > > > > > > you absolutely right. I think this issue could be closed, but possibly > > > it would be better to mark it as non-bug difference from RI. > > > Richard, what do you think? > > > > In this case according to our compatibility guidelines we should switch > > behavior to RI-like. > > Andrew, > > what do you think about it? I think we should mark it as compatibility > bug and close it as wontfix. If we will switch to RI behaviour, we > need to check all decoding operations in java.io package and possibly > correct some methods. > > Thanks. > Vladimir. > > > > Thanks, > > Mikhail > > > > > > > > > > > > > > > Thanks. > > > Vladimir. > > > > > > > Thanks, > > > > Mikhail > > > > > > > > > > > > > > > > > > However, I think solution 1 is more reasonable. > > > > > > > > > > "Is it possible to store bytes in decoder, support streaming > decoding, and, > > > > > at the same time sets correct position in input buffer after each > operation? > > > > > " > > > > > > > > > > Yes. In fact, your patch will make Harmony act as the description > above. > > > > > > > > > > However, I don't think it solve the problem. Maybe invoker is more > > > > > confusable and may think: > > > > > > > > > > "Is the remaining bytebuffer maintained in decoder or in ? Shall > I get the > > > > > remaining buffer from in and pass it for next invocation?" > > > > > > > > > > Anyway, we need a decision on this compatibility issue. > > > > > By the way, Vladimir, does solution one cause any problem on other > classlib > > > > > implementation? > > > > > > > > > > Any comment? > > > > > > > > > > Thanks ! > > > > > > > > > > > > > > > Vladimir Strigun commented on HARMONY-410: > > > > > -- > > > > > > > > > > Hi Richard, > > > > > > > > > > Thanks for the clarification, I agree that streaming decode is > good thing, > > > > > but I'd like to explain my understanding of specification :) > > > > > According to specification of CharsetDecoder decoding operation > should > > > > > process by the following steps: > > > > > " > > > > > 2. Invoke the decode method zero or more times, as long as > additional input > > > > > may be available, passing false for the endOfInput argument and > filling the > > > > > input buffer and flushing the output buffer between invocations; > > > > >
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Hi, Mikhail and Vladimir, I'd rather consider it as compatibility bug and close it as wontfix. "Did I get it right that both solutions do not contradict to the spec and that RI acts as the second one?" Partly right. Vladimir, maybe as you know, deep studying on decode will show many RI's unreasonable behaviours. Since RI's behaviour is not logical and the spec description is very vague in some situations (e.g. decode state defination, in/out buffer poistion defination), we finally decided not to follow RI's behaviour. IMO, current Harmony implementation complies with spec strictly, acts in logical way and also doesn't affect end-users. So I'd rather consider it as compatibility bug and close it as wontfix. What's your opnion? Thanks. On 5/15/06, Vladimir Strigun <[EMAIL PROTECTED]> wrote: On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > 2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>: > > On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > Vladimir, Andrew > > > > > > 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>: > > > > Here I propose two solutions: > > > > > > > > 1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in > > > > decoder. Invokers doesn't care the position of in. If the result is > > > > UNDERFLOW and there're furthur input, just pass the new input to the > > > > decoder. It's a typical streaming decoder. That's what Harmony does > > > > currently. > > > > > > > > 2. Decoder doesn't store remaining ByteBuffer. Position of "in" is set to > > > > indicate the remaining ByteBuffer. Invoker should take care to generate new > > > > input ByteBuffer for next invocation. RI acts in this way. > > > > > > > > Both are acceptable. > > > > > > > > > Did I get it right that both solutions do not contradict to the spec > > > and that RI acts as the second one? > > > > Mikhail, > > > > you absolutely right. I think this issue could be closed, but possibly > > it would be better to mark it as non-bug difference from RI. > > Richard, what do you think? > > In this case according to our compatibility guidelines we should switch > behavior to RI-like. Andrew, what do you think about it? I think we should mark it as compatibility bug and close it as wontfix. If we will switch to RI behaviour, we need to check all decoding operations in java.io package and possibly correct some methods. Thanks. Vladimir. > Thanks, > Mikhail > > > > > > > > > Thanks. > > Vladimir. > > > > > Thanks, > > > Mikhail > > > > > > > > > > > > > > However, I think solution 1 is more reasonable. > > > > > > > > "Is it possible to store bytes in decoder, support streaming decoding, and, > > > > at the same time sets correct position in input buffer after each operation? > > > > " > > > > > > > > Yes. In fact, your patch will make Harmony act as the description above. > > > > > > > > However, I don't think it solve the problem. Maybe invoker is more > > > > confusable and may think: > > > > > > > > "Is the remaining bytebuffer maintained in decoder or in ? Shall I get the > > > > remaining buffer from in and pass it for next invocation?" > > > > > > > > Anyway, we need a decision on this compatibility issue. > > > > By the way, Vladimir, does solution one cause any problem on other classlib > > > > implementation? > > > > > > > > Any comment? > > > > > > > > Thanks ! > > > > > > > > > > > > Vladimir Strigun commented on HARMONY-410: > > > > -- > > > > > > > > Hi Richard, > > > > > > > > Thanks for the clarification, I agree that streaming decode is good thing, > > > > but I'd like to explain my understanding of specification :) > > > > According to specification of CharsetDecoder decoding operation should > > > > process by the following steps: > > > > " > > > > 2. Invoke the decode method zero or more times, as long as additional input > > > > may be available, passing false for the endOfInput argument and filling the > > > > input buffer and flushing the output buffer between invocations; > > > > > > > > 3. Invoke the decode method one final time, passing true for the endOfInput > > > > argument; and then > > > > " > > > > spec also says: > > > > "The buffers' positions will be advanced to reflect the bytes read and the > > > > characters written, but their marks and limits will not be modified" > > > > > > > > I understand these sentences in the next way: > > > > invoke decode with endOfInput = false if you have additional input, then > > > > fill the buffer (i.e. add to buffer some additional input), invoke decode > > > > again and pass correct endOfInput parameter dependent of availability of > > > > input. > > > > > > > > Example you provided is very useful and, of course, 1st option looks better, > > > > but what I'm suggest here is to reflect actual processed bytes in input. > > > > After first invocation of decode, not all bytes processed actually, i.e. > > > > almost all bytes processed, but some stored in decoder to further operation. > >
