Re: [announcement] Apache Board approved Apache Harmony as a Top Level Project of the ASF

[Daniel Gandara]

congratulations

Daniel

- Original Message - 
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, October 25, 2006 5:21 PM
Subject: [announcement] Apache Board approved Apache Harmony as a Top Level 
Project of the ASF



I am happy to report that the Apache Board was willing to consider our 
proposal and voted to accept it at today's board meeting.


As stated in the Incubation vote, this is a necessary condition for 
graduation from the Incubator.


Therefore, upon a successful outcome of the Incubator PMC vote, we are 
Apache Harmony, project of the Apache Software Foundation!



  Congratulations to everyone!


When the vote is complete, we'll get to work on the transition activities, 
but until then, just give yourself a well-deserved pat on the back.


Thanks all!

geir

Re: [vote] Graduate Apache Harmony podling from the Incubator

[Daniel Gandara]

+1

sorry for the delay

Congrats to all,

Daniel

- Original Message - 
From: "Konovalova, Svetlana" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, October 24, 2006 3:21 AM
Subject: RE: Re: [vote] Graduate Apache Harmony podling from the Incubator


+1 :)

Sorry for delay...

Cheers,
Sveta Konovalova

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Tuesday, October 24, 2006 10:19 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [vote] Graduate Apache Harmony podling from the Incubator

+1 (no surprize here)

sorry for delay :(
On the 0x209 day of Apache Harmony Geir Magnusson, Jr. wrote:

We're trying something a little different.  I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."

So to bring the Harmony community and the Incubator community together
for this important event in Harmony's life, I'm calling for a vote on
graduating Harmony here on our own -dev list.  The objective is for
all in both the Harmony community and the Incubator community that
have an opinion to vote together, in the same place, and have it
"hosted" by the Harmony podling.

This is an unconventional way to do this, but I think that it's valid
and could provide one example to the Incubator on how it can work
going forward.

So, without any further ado :

[ ] +1 Graduate Apache Harmony from incubation, and let it petition
the board for Top Level Project status

[ ] 0 No opinion

[ ] -1 No, don't graduate Harmony.  Here's why :


This vote will end 72 hours from now + time of Apache mail outage.  It
will therefore end on Monday, October 23, at 3:30 PM eastern, + delta
for mail outage.

Thanks

geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Egor Pasko, Intel Managed Runtime Division 

Re: [classlib] [ldap] reuse of security parser

[Daniel Gandara]

Hi Stephan,

   Ok I agree with your approach, we´ll make the changes on the parser
and then upload a patch to the JIRA to open discussion.

thanks,

Daniel

- Original Message - 
From: "Stepan Mishura" <[EMAIL PROTECTED]>

To: 
Sent: Monday, September 11, 2006 11:08 AM
Subject: Re: [classlib] [ldap] reuse of security parser



Hi Daniel,

Yes, the parser used by 'security' code put some restrictions on
distinguished names (see [1]) and
IMO it is a good idea to try to improve the parser to make it possible to
reuse it by 'jndi' module.

When we developed security code we also thought about creating a common
'engine' for parsing distinguished names that can be extended by 
'security'

and 'ldap' code. But because of time limit we put off developing such
'engine' for a while. It is great to hear that you work on completing 
'ldap'

public API and I think that it is time to return this.

As I understood you the current parser suits for 'ldap' code and can be 
used

as common 'engine' for both modules (only minor updates are required, like
changing visibility attributes). Then I think the best way is to submit a
patch to JIRA and discuss it. And if we'll find out later that more 
updates

are required then IMO we should think about redesigning the parser code.

Thoughts? Ideas?

Thanks,
Stepan.

[1]
http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html

On 9/9/06, Daniel Gandara  wrote:


Hi all,

   as you know at the ITC we are working to complete javax.naming.ldap
package v 1.5.  We are currently implementing the 1.5 classes and I have
one question regarding the reuse of an already donated code from other
package (org.apache.harmony.security.x509).
   The specific issue is as follow: in order to implement the classes
LdapName and Rdn -from javax.naming.ldap- we need a Distinguished Name
parser that parses according to the bnf syntax specified in RFC2253 and
RFC1779.
   We've found a DNParser class in the package
org.apache.harmony.security.x509
we could re-use, but it checks for valid AttributeTypes by looking in a
table of valid OIDs.   What we need is a less restrictive parser that
allows
types that do not have a valid OID.
   We could easily implement this behavior extending from this class and
rewriting the specific functionality; but we would have to change some
methods and attributes visibility of DNParser and AttributeTypeAndValue
from private to protected.
   The specific question is: should we made this change on the security
package and submit it with our contribution?  or should we ask for this
change
to be made by the ones who wrote the security package?

I'll wait for feedback,

Thanks,

Daniel





--
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]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib] [ldap] reuse of security parser

[Daniel Gandara]

Hi all, 

as you know at the ITC we are working to complete javax.naming.ldap 
package v 1.5.  We are currently implementing the 1.5 classes and I have 
one question regarding the reuse of an already donated code from other 
package (org.apache.harmony.security.x509).   
The specific issue is as follow: in order to implement the classes 
LdapName and Rdn -from javax.naming.ldap- we need a Distinguished Name 
parser that parses according to the bnf syntax specified in RFC2253 and 
RFC1779.   
We've found a DNParser class in the package org.apache.harmony.security.x509
we could re-use, but it checks for valid AttributeTypes by looking in a 
table of valid OIDs.   What we need is a less restrictive parser that allows 
types that do not have a valid OID.   
We could easily implement this behavior extending from this class and 
rewriting the specific functionality; but we would have to change some 
methods and attributes visibility of DNParser and AttributeTypeAndValue 
from private to protected.
The specific question is: should we made this change on the security 
package and submit it with our contribution?  or should we ask for this change
to be made by the ones who wrote the security package?

I'll wait for feedback,

Thanks,

Daniel 

[classlib][ldap] contribution of missing javax.naming.ldap 1.4 classes

[Daniel Gandara]

Hi all, 

on http://issues.apache.org/jira/browse/HARMONY-1296 we have contributed 
the missing classes for v1.4 of the javax.naming.ldap package.At the ITC we 
are working to complete the 1.5 version of the package, in the following weeks 
we plan to contribute it.
Within the contribution you will find a test suite for the package and a 
coverage analysis of it.

Thanks, 

Daniel Gándara

Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

[Daniel Gandara]

I agree, I think it is a good idea, since changes can still be made, code
will be on the archive, and we do not confuse people with multiple rmi 
versions

within the classlib.


Daniel

- Original Message - 
From: "Nathan Beyer" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 21, 2006 9:51 PM
Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the 
others to archive



I like this approach. Anyone that wants to integrate changes can just 
submit

patches.


-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Monday, August 21, 2006 8:34 AM
To: harmony-dev@incubator.apache.org
Subject: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
others to archive

We've had multiple RMI modules hanging around for a while due to our
fortune of multiple submissions.

Would anyone have a problem if we 'retired' all except modules/rmi to
the archive, and then took whatever was needed from there?

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] [ldap] support for multiple VMs?

[Daniel Gandara]

Tim Ellison wrote:

Daniel Gandara wrote:

Hi all,

We are working on the javax.naming.ldap and we are facing the
following issue when thinking about supporting multiple VMs.
Following the SPEC there is a method createExtendedResponse in the
StartTlsRequest class which states that the returning object must be
an instance of a concrete subclass of StartTlsResponse and must have
a public zero-argument constructor. The concrete subclass is
determined by reading the configuration file located in
META-INF/services/javax.naming.ldap.StartTlsResponse (see
http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html)

The search for this configuration file is done by looking in the
classpath, java.home and user.dir; also the Xbootclasspath should be
inspected, and that seems to be a problematic situation, since there
is not a standard property to look for its value. Different VM
implementations have different property names for the boot class path
value. In the old Harmony VM implementation was
com.ibm.oti.system.class.path; in the new one is
org.apache.harmony.boot.class. The property name in the Sun's VM is
sun.boot.class.path. We are wondering which property name to use in
the code. At first sight the Harmony new VM implementation property
seems to be the better option, but maybe looking for the other
properties will be interesting for compatibility purposes.

We would be very interested in opinions.


I'd ignore the com.ibm property and look through the path defined by
org.apache.harmony.boot.class.path

I don't know what property is set by the DRLVM / JCHEVM / etc., but it
would be good if they set the same property (maybe in addition to their
current property).

If you want the code to run on the Sun implementation too then you
should *also* search the sun.boot.class.path, and of course be tolerant
of o.a.harmony... or sun.boot... being absent.  Is running on Sun a goal
for you?


our goal is Harmony, but within our development and test procedure,
we do check against the RI, just to be sure our code is working ok.


It's not something that we would require for including the
LDAP code in Harmony.


:)   next week we'll contribute the code for  some classes that were missing
from 1.4 version of javax.naming.ldap, and after that we'll send code for 
the

1.5 classes of the package.


Thanks,

Daniel



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]

[classlib] [ldap] support for multiple VMs?

[Daniel Gandara]

Hi all, 

We are working on the javax.naming.ldap and we are facing the following 
issue when thinking about supporting multiple VMs.   
Following the SPEC there is a method createExtendedResponse in the 
StartTlsRequest class which states that the returning object must be an 
instance of a concrete subclass of StartTlsResponse and must have a public 
zero-argument constructor.   The concrete subclass is determined by reading the 
configuration file located in 
META-INF/services/javax.naming.ldap.StartTlsResponse (see 
http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html)
 
The search for this configuration file is done by looking in the classpath, 
java.home and user.dir; also the Xbootclasspath should be inspected, and that 
seems to be a problematic situation, since there is not a standard property to 
look for its value.   Different VM implementations have different property 
names for the boot class path value.  In the old Harmony VM implementation was 
com.ibm.oti.system.class.path; in the new one is org.apache.harmony.boot.class. 
The property name in the Sun's VM is sun.boot.class.path. 
We are wondering which property name to use in the code.  At first sight the 
Harmony new VM implementation property seems to be the better option, but maybe 
looking for the other properties will be interesting for compatibility purposes.
 
We would be very interested in opinions.

Thanks,

Daniel

[classlib] ldap

[Daniel Gandara]

Hi all, 
 
We are working on the javax.naming.ldap package, we know that there is a 
contributed ldap 1.4 package which is not complete; so we are thinking about 
extending it to accomplish the Java 1.5 specification and contribute it to the 
project.
That said, it would be very important for us to get in touch with the 
contributors 
of the package, to talk about some issues related to the current state of the 
package implementation.   At this point the most important question we have 
is related with the implementation of the classes StartTlsRequest and 
StartTlsResponse what are not implemented in the contributed package (classes 
are missing in the package).  We would like to know if there were any special 
reason why they were not implemented or if the package is still incomplete or 
under development.
Any other development documentation of the package (if available) would be 
very useful for us too.
 
Best regards, 
 
Daniel

Re: [classlib] resolution of rmi/math/crypto duplication?

[Daniel Gandara]

>On 7/21/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>>
>>
>> Daniel Fridlender wrote:
>> > On 7/21/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> >> Geir Magnusson Jr wrote:
>> >> > While it's not a critical thing, this seems like something we want to
>> >> > put to bed.  Tim tried taking a run at this for one of these last week,
>> >> > and I'd like to try again.
>> >> >
>> >> > Would some number of days of discussion (like 3) plus a vote be an
>> >> > acceptable way to get this resolved?
>> >>
>> >> Yes.  IMHO there is better value in performing a quick comparison and
>> >> choosing one to work on and improve, compared to spending a long time
>> >> evaluating the two/three impls.
>> >
>> > In the case of java.math I think we should pick the new implementation
>> > (H-935 which combines H-380 and H-199 and some of H-551) to improve
>> > from now on.
>>
>> It doesn't surprise me that you'd say that :)
>>
>> What is your opinion for RMI?

In the case of RMI we have been working comparing both implementations
(I'm currently working on the final review and conclusion of the document) 
and my suggestion based on to what we've seen so far is that we should
chose the Intel contributed rmi and work to improve it; needless to say, 
we are willing to help improving the rmi package if needed.


Daniel

PS: I'll post the DOC as soon as I have it finished.

>
>I am the wrong Daniel to answer that.  I don't know enough about rmi
>to compare the two implementations.
>
>Daniel

>>
>> geir
>>
>>

Re: [classlib] rmi2.1.4?

[Daniel Gandara]

Geir Magnusson Jr wrote:

Daniel Gandara wrote:
ITC's rmi is 5.0 compliant and dependent, but we realized that Harmony 
was 1.4;
so, since our package made use of still not available 5.0 features (like 
j.u.c) , we
decide to deploy a 1.4 version of the code, in which we remove all 5.0 
dependencies.

I believe that's the reason why rmi2.1.4


Can we resolve down to 1 version of RMI and cull goodness from the rest?


I believe given the fact that j.u.c is not there and no one is working on 
it,

1.4 version is the one that should remain for now (remember there is a
performance penalty compared to 5.0), when j.u.c be there we can
easily include it.
I see no point in keeping the 5.0 since it cannot be run with current 
classlib...

What do you think?



is there any advance with getting j.u.c?


According to Doug, we should just be able to use what we want from there. 
IIRC, Doug's assertion is that since this was the first implementation of 
j.u.c, and it was done in the public view, it therefore cannot be 
influenced by some other version, since there wasn't any other versions 
around.


I'll start a new thread and we'll see if we can get doug to comment.


I'll keep an eye on it to see what Doug says.

Daniel


geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] rmi2.1.4?

[Daniel Gandara]

ITC's rmi is 5.0 compliant and dependent, but we realized that Harmony was 
1.4;
so, since our package made use of still not available 5.0 features (like 
j.u.c) , we
decide to deploy a 1.4 version of the code, in which we remove all 5.0 
dependencies.

I believe that's the reason why rmi2.1.4

is there any advance with getting j.u.c?

- Original Message - 
From: "Geir Magnusson Jr" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, May 30, 2006 11:51 AM
Subject: [classlib] rmi2.1.4?



why?

-
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] millions of rmi tests

[Daniel Gandara]

Mikhail,
   Let me explain the reasons why we developed this amount of tests;
We decided to develop implementation independant tests cases which
will show if a given implementation of the package behaves as it should
(RI); we also decided to implement them at the same time the package
was being coded, so no implementation specific detail was known by
the time the tests were developed.
  In order to do this we developed:
- Unit tests: for them we took different approachs, which were:
   - broad tests: where we test each public method with a set of
possible  inputs
   - specific tests: using 'suspicious' parameters like null
   unit tests were developed using a mix of automatic code generation
   and regular coding.
- Integration tests: http tunneling and distributed integration tests
   which provide a more realistic and "smart" test for the package.

All this tests allowed us to check the correct functionality of our
package.

That said, I will agree with you that at this moment some of this tests
(mostly basic JUnit tests) might not be very usefull, and I would add
that more and complex integration tests should be written to check
the correct functionality of rmi package.
At this moment we are running all tests (both itc and intel) against
contributed rmi packages (both itc and intel); I'll send the report as
soon as I have it.

Thanks,

Daniel
note: latest tests source code and doc can be found at
http://issues.apache.org/jira/browse/HARMONY-473
btw: there were not millions but a few thousands tests :)

- Original Message - 
From: "Mikhail Loenko" <[EMAIL PROTECTED]>

To: 
Sent: Monday, May 29, 2006 10:01 AM
Subject: [classlib] millions of rmi tests


I've tried to integrate rmi2 tests to rmi module,  and found some odd 
things.


Let's take a look for example at TestActivationGroupDesc.java

it has 5158 test methods, most of which are very similar.
For example it has 855 tests that invoke constructor with various parameters
and check that new did not return null and no exception was thrown:

Compare

public void 
testActivationGroupDescStringStringMarshalledObjectPropertiesCommandEnvironment006()

{

   try{
   Properties p= new Properties();
   assertNotNull(msgNotNull, new ActivationGroupDesc(null ,  null ,
   new MarshalledObject(new Double(23.4))  ,  new Properties() 
,

   new ActivationGroupDesc.CommandEnvironment("Hola la",
   new String[0])));
   } catch (Throwable e) {
   fail(msgNoException+e);
   }
}

and

public void 
testActivationGroupDescStringStringMarshalledObjectPropertiesCommandEnvironment007()

{
   try{
   Properties p= new Properties();
   assertNotNull(msgNotNull, new ActivationGroupDesc(null , null ,
   new MarshalledObject(new Double(23.4))  ,  new Properties() 
,

   new ActivationGroupDesc.CommandEnvironment("", null)));
   } catch (Throwable e) {
   fail(msgNoException+e);
   }
}


This is how the constructor under test looks like:
public ActivationGroupDesc(String className, String codebase,
   MarshalledObject data, Properties props,
   ActivationGroupDesc.CommandEnvironment env) {

   this.className = className;
   this.location = codebase;
   this.data = data;
   this.props = props;
   this.env = env;
}

It seems that instead of those million test cases we need just a few
that would verify that getXXX() methods return what was passed into 
constructor

plus possibly some tests that pass 'suspicious' parameters like null.

Thoughts?

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: [rmi] package comparison

[Daniel Gandara]

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] package comparison

Vasily,

   We've reviewed and improved (code and documentation) our test suite
for rmi, I've created a new JIRA 
http://issues.apache.org/jira/browse/HARMONY-473

with the latest version of it.
   There you will find 3 diferent types of tests:
   - Unit Test
   - Http Tunneling test
   - Distributed Integration Test

   toghether with a PDF with explanations and instructions to run them.

Hope this helps,

Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, May 05, 2006 3:33 PM
Subject: RE: [rmi] package comparison


Daniel,

I was going to run your tests against our implementation, and it looks
like there's a lot of tests in the package, but I found no

documentation

on how to run them. Could you please instruct me on how your test

suite

works and how can I run it?

Thank you!

Vasily


-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Monday,
April 

17, 2006 7:38 PM
To: harmony-dev@incubator.apache.org
Subject: [rmi] package comparison (was Re: Contribution of RMI
framework)

Vasily,
   a couple of things about package comparison:

a) java 5.0 vs 1.4.2
Our rmi package was developed according to 5.0 rmi spec, and
it takes full advantage of 5.0 new features (like

java.util.concurrent)

Since Harmony classlib and VMs are still in 1.4.2 we deployed
a 1.4.2 version of our package in which we removed the 5.0
dependencies.There is obviously a performance penalty
paid by the 1.4.2 release of the package.
You can find both versions of the packages at 
http://issues.apache.org/jira/browse/HARMONY-211


b) compatibility with reference implementation
  within our contribution you will find a complete set of test cases
(source code and documentation for each).   We run these test cases
against our package before contributing it, so I guess one way to
move further is to cross run test cases (you run ours and we run
yours).   What do you think?

c) performance analysis and comparison
   I believe the first step here is to get along about which is the
workload or set of applications that represent a "real" use of rmi
package.   I see a big challenge here...

I'll wait for your comments,

Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

Vasily


-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED]
Sent: Friday, April 14, 2006 7:53 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>:

Vasily,
   good to know that there is someone out there who has also
been working on rmi; I believe we'll have a lot to share and discuss
 about it.

Thanks,

Daniel

- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony

project

on
behalf of Intel corporation. This contribut

Re: ITC rmi tests (was Re: towards a new implementation of java.math)

[Daniel Gandara]

Tim Ellison wrote

Mark Hindess wrote:
On 17 May 2006 at 12:30, "Daniel Gandara" <[EMAIL PROTECTED]> 
wrote:

Mark Hindess wrote:

Daniel,

I've just contributed a JIRA,
 http://issues.apache.org/jira/browse/HARMONY-471
that integrates the ITC rmi implementation as modules/rmi.  (The jsr14
version.  Only the code at the moment, I creating the scripts/patches
for the tests next.)

   We've been working on improvements to the rmi test suite,
I've contributed that at 
http://issues.apache.org/jira/browse/HARMONY-473

(I created a new JIRA since previous one HARMONY-211 was closed-)
so please take that test suite.


Thanks for the heads-up.  I just saw the JIRA messages.  (I notice it
includes all the code again and is classified as a contribution.  But
I assume this is just a derivative work of the previous contribution
rather than a new contribution?  That is we don't need to wait for
another vote.)


I disagree -- i think the simplest thing would be for Daniel to submit
the delta rather than another version of the original contribution.


ok, I can do that, I did not mean to create a problem :)
we reorganized (renamed) the test suite for a better understanding,
that's why I uploaded the whole thing, but I can submit a delta.

which would be the procedure for me to send the delta? create a new
JIRA with just the changes to the previous code? clasify it as "classlib"?

Daniel


Regards,
Tim



Integrating the tests was proving interesting.  Have you been following
the discussion of the test naming/layout conventions?  The latest
proposal is here:


http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html

I was having a little difficulty in (quickly) figuring out which tests
are implementation-independent (api) tests.  Or indeed which tests will
run stand-alone without any infrastructure being configured.  Perhaps
you could help?  I don't really like the idea of integrating code
without at least some tests that everyone can run.

In the meantime, I'll take a look at the new JIRA.


Daniel Gandara
BTW: we are a bunch of Daniels here at Cordoba :)))


;-)

Regards,
-Mark.


On 17 May 2006 at 11:19, "Daniel Fridlender" <[EMAIL PROTECTED]>
wrote:

Hi,

After a discussion we had a few weeks ago in this forum on the
different implementations of java.math donated to Harmony
(Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
the task of integrating them into a single implementation which would
benefit from the best features of Harmony-39, 380 and 199.

We will consider comparing on a method-by-method level but also on
ideas level so that the new implementation will probably require
re-programming good ideas from the existing implementations.  In the
case of BigInteger we will also compare the benefits of the different
internal representations.

Right now we are analysing the two implementations.  Once we are done
with this analysis we will make it public and propose a way to proceed
towards an integration.

BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
to erase non-existing lines.  Did we miss something?  Is there any
other intermediate patch that we have missed?

Regards,

Daniel Fridlender
ITC




-
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]





-
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 rmi tests (was Re: towards a new implementation of java.math)

[Daniel Gandara]

Geir Magnusson Jr wrote:


Mark Hindess wrote:
On 17 May 2006 at 12:30, "Daniel Gandara" <[EMAIL PROTECTED]> 
wrote:

Mark Hindess wrote:

Daniel,

I've just contributed a JIRA,
 http://issues.apache.org/jira/browse/HARMONY-471
that integrates the ITC rmi implementation as modules/rmi.  (The jsr14
version.  Only the code at the moment, I creating the scripts/patches
for the tests next.)

   We've been working on improvements to the rmi test suite,
I've contributed that at 
http://issues.apache.org/jira/browse/HARMONY-473

(I created a new JIRA since previous one HARMONY-211 was closed-)
so please take that test suite.


Thanks for the heads-up.  I just saw the JIRA messages.  (I notice it
includes all the code again and is classified as a contribution.  But
I assume this is just a derivative work of the previous contribution
rather than a new contribution?  That is we don't need to wait for
another vote.)


Why not?


not sure how this should be handled, since we improved the code
and documentation of the previously contributed test suite; I do not see 
this

as a new contribution if not as a derivative work done based on the
existing code...


geir


Daniel


-
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: ITC rmi tests (was Re: towards a new implementation of java.math)

[Daniel Gandara]

Mark Hindess wrote:
On 17 May 2006 at 12:30, "Daniel Gandara" <[EMAIL PROTECTED]> 
wrote:

Mark Hindess wrote:
>
> Daniel,
>
> I've just contributed a JIRA,
>  http://issues.apache.org/jira/browse/HARMONY-471
> that integrates the ITC rmi implementation as modules/rmi.  (The jsr14
> version.  Only the code at the moment, I creating the scripts/patches
> for the tests next.)

   We've been working on improvements to the rmi test suite,
I've contributed that at http://issues.apache.org/jira/browse/HARMONY-473
(I created a new JIRA since previous one HARMONY-211 was closed-)
so please take that test suite.


Thanks for the heads-up.  I just saw the JIRA messages.  (I notice it
includes all the code again and is classified as a contribution.  But
I assume this is just a derivative work of the previous contribution
rather than a new contribution?  That is we don't need to wait for
another vote.)


you are right, my mistake, it is a derivative work, I should have classified
it as classlib or something like that.  I'll try to change that...


Integrating the tests was proving interesting.  Have you been following
the discussion of the test naming/layout conventions?  The latest
proposal is here:


http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html

I was having a little difficulty in (quickly) figuring out which tests
are implementation-independent (api) tests.  Or indeed which tests will
run stand-alone without any infrastructure being configured.  Perhaps
you could help?  I don't really like the idea of integrating code
without at least some tests that everyone can run.


rmi is kinda complex at this point.   rmi is distributed "in nature" so
some infraestructure setup is needed to run meaningful tests involving
at least a client and a server; furthermore a given process must be
done to export objects, register them and then get clients use them.
Only JUnit test will run stand-alone; which in the case of rmi
do not say too much about the package... but anyway, unit tests
are there so lets put them toghether with the code.
Junits from on our suite are those named:
- ar.org.fitc.test.rmi
- ar.org.fitc.test.rmi.activation
- ar.org.fitc.test.rmi.server
- ar.org.fitc.test.rmi.registry
- ar.org.fitc.test.rmi.dgc



In the meantime, I'll take a look at the new JIRA.


Daniel Gandara
BTW: we are a bunch of Daniels here at Cordoba :)))


;-)

Regards,
-Mark.


regards,

Daniel



>
> On 17 May 2006 at 11:19, "Daniel Fridlender" <[EMAIL PROTECTED]>
> wrote:
>> Hi,
>>
>> After a discussion we had a few weeks ago in this forum on the
>> different implementations of java.math donated to Harmony
>> (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
>> the task of integrating them into a single implementation which would
>> benefit from the best features of Harmony-39, 380 and 199.
>>
>> We will consider comparing on a method-by-method level but also on
>> ideas level so that the new implementation will probably require
>> re-programming good ideas from the existing implementations.  In the
>> case of BigInteger we will also compare the benefits of the different
>> internal representations.
>>
>> Right now we are analysing the two implementations.  Once we are done
>> with this analysis we will make it public and propose a way to proceed
>> towards an integration.
>>
>> BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
>> to erase non-existing lines.  Did we miss something?  Is there any
>> other intermediate patch that we have missed?
>>
>> Regards,
>>
>> Daniel Fridlender
>> ITC




-
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: [rmi] package comparison

[Daniel Gandara]

Vasily,

   We've reviewed and improved (code and documentation) our test suite
for rmi, I've created a new JIRA 
http://issues.apache.org/jira/browse/HARMONY-473

with the latest version of it.
   There you will find 3 diferent types of tests:
   - Unit Test
   - Http Tunneling test
   - Distributed Integration Test

   toghether with a PDF with explanations and instructions to run them.

Hope this helps,

Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, May 05, 2006 3:33 PM
Subject: RE: [rmi] package comparison


Daniel,

I was going to run your tests against our implementation, and it looks
like there's a lot of tests in the package, but I found no documentation
on how to run them. Could you please instruct me on how your test suite
works and how can I run it?

Thank you!

Vasily


-----Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Monday, April 
17, 2006 7:38 PM

To: harmony-dev@incubator.apache.org
Subject: [rmi] package comparison (was Re: Contribution of RMI
framework)

Vasily,
   a couple of things about package comparison:

a) java 5.0 vs 1.4.2
Our rmi package was developed according to 5.0 rmi spec, and
it takes full advantage of 5.0 new features (like java.util.concurrent)
Since Harmony classlib and VMs are still in 1.4.2 we deployed
a 1.4.2 version of our package in which we removed the 5.0
dependencies.There is obviously a performance penalty
paid by the 1.4.2 release of the package.
You can find both versions of the packages at 
http://issues.apache.org/jira/browse/HARMONY-211


b) compatibility with reference implementation
  within our contribution you will find a complete set of test cases
(source code and documentation for each).   We run these test cases
against our package before contributing it, so I guess one way to
move further is to cross run test cases (you run ours and we run
yours).   What do you think?

c) performance analysis and comparison
   I believe the first step here is to get along about which is the
workload or set of applications that represent a "real" use of rmi
package.   I see a big challenge here...

I'll wait for your comments,

Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

Vasily


-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED]
Sent: Friday, April 14, 2006 7:53 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>:

Vasily,
   good to know that there is someone out there who has also
been working on rmi; I believe we'll have a lot to share and discuss
 about it.

Thanks,

Daniel

- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM (was
tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java

1.4

specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarificat

Re: towards a new implementation of java.math

[Daniel Gandara]

Mark Hindess wrote:


Daniel,

I've just contributed a JIRA,
 http://issues.apache.org/jira/browse/HARMONY-471
that integrates the ITC rmi implementation as modules/rmi.  (The jsr14
version.  Only the code at the moment, I creating the scripts/patches
for the tests next.)


  We've been working on improvements to the rmi test suite,
I've contributed that at http://issues.apache.org/jira/browse/HARMONY-473
(I created a new JIRA since previous one HARMONY-211 was closed-)
so please take that test suite.


In this JIRA, I modified the build ant files to support a property,
'hy.rmi.module', which defaults to 'rmi'.  I did this so that, if we
integrate the Intel implementationas modules/rmi-intel, developers can
easily build/test the different implementation just by overriding the
property on the ant command line.  For example:

 ant -f make/build.xml -Dhy.rmi.module=rmi-intel

It would be quite trivial to do the same for the math implementations
(and crypto I suppose).  If we were to do this, perhaps the process of
analysis and creation of a combined implementation could be done within
the project?  In public and with more potential contributions.

What do you think?


looks like a good and easy solution to handle packages with multiple
contributions; I'll let Daniel (Fridlender) to answer since he is the one
leading math :)



Regards,
Mark.


Thanks,

Daniel Gandara
BTW: we are a bunch of Daniels here at Cordoba :)))



On 17 May 2006 at 11:19, "Daniel Fridlender" <[EMAIL PROTECTED]> 
wrote:

Hi,

After a discussion we had a few weeks ago in this forum on the
different implementations of java.math donated to Harmony
(Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for
the task of integrating them into a single implementation which would
benefit from the best features of Harmony-39, 380 and 199.

We will consider comparing on a method-by-method level but also on
ideas level so that the new implementation will probably require
re-programming good ideas from the existing implementations.  In the
case of BigInteger we will also compare the benefits of the different
internal representations.

Right now we are analysing the two implementations.  Once we are done
with this analysis we will make it public and propose a way to proceed
towards an integration.

BTW, we had problems patching Harmony-380 over Harmony-39, it attempts
to erase non-existing lines.  Did we miss something?  Is there any
other intermediate patch that we have missed?

Regards,

Daniel Fridlender
ITC

-
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: [rmi] package comparison

[Daniel Gandara]

Vasily, 


   sorry for the delay; we are reviewing the test cases taking note
of any specific instruction needed to run them.  
   I'll send the notes as soon as we get them done.


Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, May 05, 2006 3:33 PM
Subject: RE: [rmi] package comparison


Daniel,

I was going to run your tests against our implementation, and it looks
like there's a lot of tests in the package, but I found no documentation
on how to run them. Could you please instruct me on how your test suite
works and how can I run it?

Thank you!

Vasily


-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 17, 2006 7:38 PM

To: harmony-dev@incubator.apache.org
Subject: [rmi] package comparison (was Re: Contribution of RMI
framework)

Vasily,
   a couple of things about package comparison:

a) java 5.0 vs 1.4.2
Our rmi package was developed according to 5.0 rmi spec, and
it takes full advantage of 5.0 new features (like java.util.concurrent)
Since Harmony classlib and VMs are still in 1.4.2 we deployed
a 1.4.2 version of our package in which we removed the 5.0
dependencies.There is obviously a performance penalty
paid by the 1.4.2 release of the package.
You can find both versions of the packages at 
http://issues.apache.org/jira/browse/HARMONY-211


b) compatibility with reference implementation
  within our contribution you will find a complete set of test cases
(source code and documentation for each).   We run these test cases
against our package before contributing it, so I guess one way to
move further is to cross run test cases (you run ours and we run
yours).   What do you think?

c) performance analysis and comparison
   I believe the first step here is to get along about which is the
workload or set of applications that represent a "real" use of rmi
package.   I see a big challenge here...

I'll wait for your comments,

Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

Vasily


-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED]
Sent: Friday, April 14, 2006 7:53 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>:

Vasily,
   good to know that there is someone out there who has also
been working on rmi; I believe we'll have a lot to share and discuss
 about it.

Thanks,

Daniel

- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM (was
tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java

1.4

specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarifications

are

needed, feel free to contact me. I will be happy to answer all

questions

about this contribution and to participate in its further
development/maintenance and integration into Harmony.

Vasily Zakharov
Intel Middleware Produ

Re: [rmi] package comparison (was Re: Contribution of RMI framework)

[Daniel Gandara]

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 

Re: [rmi] package comparison (was Re: Contribution of RMI framework)

[Daniel Gandara]

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 bet

Re: [rmi] package comparison (was Re: Contribution of RMI framework)

[Daniel Gandara]

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 acomplished with further
wire protocol information.


Regretfully, I can't agree with this approach. Our target is providing
the end users out there with a free open source Java implementation
they can really use in their applications.


I completelly agree with you on the ultimate goal; but now I believe we
should compare, comparable things... it is clear that "interoperability"
is a feature you have worked and acomplished, in the other hand we
have worked and acomplished on 5.0; so we should now move on
comparing what is comparable between the packages: its functionality.


And users generally don't care about quality of specifications
what they need is the tool they can take and use, and that will work
and satisfy their needs. That's why I think it's very important to not let
the poor quality of the specification stop us from giving the community
an effective and compatible implementation.


I see two different issues here, so I'll comment each:
a) end users

" And users generally don't care about quality of specifications
 what they need is the tool they can take and use ..."

That is true, but black-box inspecting method is not good enough,
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?

b) the spec

"... not let the poor quality of the specification stop us from giving the
  community an effective and compatible implementation ..."

Standards and specifications are what interoperability is all about!
there is no way in which you can provide compatibility if there is no
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.  If that be the
case then we should no longer talk about "specification" for rmi, instead
we should talk about rmi as a "product" we try to emulate...


Needeless to say, I'm aware of the critical impact interoperability
has and we are currently working on that.



By the way, one of the very important interoperability issues is the
1.1 protocol version. It's really obsolete, and there's a great
temptation to give up on implementing it, but the reference implementation
strictly adhers to 1.1 protocol in Distributed Garbage Collection, so
we must have 1.1 protocol operational in order to be practically
compatible with reference implementation.


Yes that's true and there is a big challenge to be 100% compatible
supporting different reference implementation's evolutions.

BTW: it will be great if you contribute what you have conclude about
the protocol.

Daniel



Vasily Zakharov
Intel Middleware Products Division





-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 20, 2006 1:17 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [rmi] package comparison (was Re: Contribution of RMI
framework)

Vasily,

   You are not missing anything, our package does not allow
interoperability simply because you cannot derive it from the
spec.  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 kn

Re: Contribution of RMI framework

[Daniel Gandara]

Vasily, 

I was not looking for public "general" designs of RMI, I do 
know them very well :)   thanks anyway...
I asked about specific design docs of your implementation 
and the architecture behind it; I'm sure you did it in order to 
"design" the package before coding it, but its ok if you do 
not have them handy.


Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, April 20, 2006 10:46 AM
Subject: RE: Contribution of RMI framework


Daniel,

Regretfully, we have no specific top level design documentation.
However, the general design of the RMI package is described rather
well in public sources.

For example, you could check the "Java RMI: Remote Method Invocation"
book by Troy Bryan Downing or Sun's jGuru RMI course at
http://java.sun.com/developer/onlineTraining/rmi/RMI.html

Vasily


-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 20, 2006 1:17 AM

To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

Vasily, 


   I'm reviewing your implementation, I believe there is a lot to learn

about other's solution to the same problem :)  and I'm wondering 
if you can send me some top level design documentation about your 
package.


Thanks,

Daniel

PS: if you happen to need it you can find more info about our design
here http://www.itc.unc.edu.ar/javadev/rmi/architecture.html

- Original Message - 
From: "Daniel Gandara" <[EMAIL PROTECTED]>

To: 
Sent: Monday, April 17, 2006 12:05 PM
Subject: Re: Contribution of RMI framework


I completelly agree with Vasily, doing test and performance analysis 
on RMI is not a trivial task; I'll coordinate with him the best way to



compare the packages.

Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

Vasily


-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 14, 2006 7:53 AM

To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>:

Vasily,
   good to know that there is someone out there who has also
been working on rmi; I believe we'll have a lot to share and discuss
 about it.

Thanks,

Daniel

- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony

project

on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM

(was

tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java

1.4

specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarifications

are

needed, feel free to contact me. I will be happy to answer all

questions

about this contribution and to participate in its further
development/maintenance and integration into Harmony.

Vasily Zakharov
Intel Middleware Product Division



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, 

Re: [rmi] package comparison (was Re: Contribution of RMI framework)

[Daniel Gandara]

... 7 more


Server.java:

import java.rmi.Remote;
import java.rmi.RemoteException;
import java.rmi.RMISecurityManager;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
import java.rmi.server.UnicastRemoteObject;

interface TestRemoteInterface extends Remote {
   public String test() throws RemoteException;
}

class TestRemoteObject implements TestRemoteInterface {
   public String test() throws RemoteException {
   System.out.println("TestRemoteObject.test() run");
   return "SUCCESS";
   }
}

public class Server {
   public static void main(String[] args) {
   TestRemoteObject obj = null;

   try {
   System.out.println("Setting security manager");
   System.setSecurityManager(new RMISecurityManager());
   System.err.println("Creating registry");
   Registry registry = LocateRegistry.createRegistry(1099);
   System.out.println("Creating remote object");
   obj = new TestRemoteObject();
   System.out.println("Exporting remote object");
   UnicastRemoteObject.exportObject(obj, );
   System.out.println("Binding object to registry");
   registry.rebind("TestRemoteObject", obj);
   System.out.println("Sleeping 10 seconds");
   Thread.sleep(1);
   } catch (Throwable e) {
   e.printStackTrace();
   System.err.println("ERROR");
   } finally {
   if (obj != null) {
   System.out.println("Unexporting remote object");

   try {
   if (UnicastRemoteObject.unexportObject(obj, false))
{
   System.out.println("Unexport FALSE");
   } else {
   if (UnicastRemoteObject.unexportObject(obj,
true)) {
   System.out.println("Unexport TRUE");
   } else {
   System.out.println("Unexport FAILED");
   System.err.println("ERROR");
   System.exit(-1);
   }
   }
   } catch (Throwable e) {
   e.printStackTrace();
   System.err.println("ERROR");
   System.exit(-1);
   }
   }
   }
   }
}


Client.java:

import java.rmi.RMISecurityManager;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;

public class Client {
   public static void main(String[] args) {
   try {
   System.out.println("Setting security manager");
   System.setSecurityManager(new RMISecurityManager());
   System.err.println("Locating registry");
   Registry registry = LocateRegistry.getRegistry();
   System.err.println("Looking for object");
   TestRemoteInterface obj = (TestRemoteInterface)
   registry.lookup("TestRemoteObject");
   System.err.println("Object found: " + obj);
   System.err.println("Calling method");
   Object ret = obj.test();
   System.err.println("Object returned: " + ret);
   System.err.println("SUCCESS");
   } catch (Throwable e) {
   e.printStackTrace();
   System.err.println("FAIL");
   }
   }
}


all.policy:

grant{
   permission java.security.AllPermission;
};


-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED]
Sent: Monday, April 17, 2006 7:38 PM
To: harmony-dev@incubator.apache.org
Subject: [rmi] package comparison (was Re: Contribution of RMI
framework)

Vasily,
   a couple of things about package comparison:

a) java 5.0 vs 1.4.2
Our rmi package was developed according to 5.0 rmi spec, and
it takes full advantage of 5.0 new features (like java.util.concurrent)
Since Harmony classlib and VMs are still in 1.4.2 we deployed
a 1.4.2 version of our package in which we removed the 5.0
dependencies.There is obviously a performance penalty
paid by the 1.4.2 release of the package.
You can find both versions of the packages at
http://issues.apache.org/jira/browse/HARMONY-211

b) compatibility with reference implementation
  within our contribution you will find a complete set of test cases
(source code and documentation for each).   We run these test cases
against our package before contributing it, so I guess one way to
move further is to cross run test cases (you run ours and we run
yours).   What do you think?

c) performance analysis and comparison
   I believe the first step here is to get along about which is the
workload or set of applications that represent a "real" use of rmi
package.   I see a big challenge here...

I'll wait for your comments,

Daniel

Re: Contribution of RMI framework

[Daniel Gandara]

Vasily, 

   I'm reviewing your implementation, I believe there is a lot to learn 
about other's solution to the same problem :)  and I'm wondering 
if you can send me some top level design documentation about your 
package.


Thanks,

Daniel

PS: if you happen to need it you can find more info about our design
here http://www.itc.unc.edu.ar/javadev/rmi/architecture.html

- Original Message - 
From: "Daniel Gandara" <[EMAIL PROTECTED]>

To: 
Sent: Monday, April 17, 2006 12:05 PM
Subject: Re: Contribution of RMI framework


I completelly agree with Vasily, doing test and performance analysis 
on RMI is not a trivial task; I'll coordinate with him the best way to 
compare the packages.


Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

Vasily


-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 14, 2006 7:53 AM

To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>:

Vasily,
   good to know that there is someone out there who has also
been working on rmi; I believe we'll have a lot to share and discuss
 about it.

Thanks,

Daniel

- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM (was
tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java

1.4

specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarifications

are

needed, feel free to contact me. I will be happy to answer all

questions

about this contribution and to participate in its further
development/maintenance and integration into Harmony.

Vasily Zakharov
Intel Middleware Product 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]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[rmi] spec issues (was Re: Contribution of RMI framework)

[Daniel Gandara]

Hi Vasily, 

   There is one thing I would like to discuss with you and it is 
about the experience you had dealing with rmi's spec.
We found it -the spec- to be "very" vague and unclear; in many 
cases it seem to be written backwards (I mean they documented 
what the code does but do not follow a clear design criteria);

there are some "expected" behaviors that cannot be accomplished
with current spec, for example mixing RMI providers (having one 
provider on the client and another on the server) since JRMP 
protocol is not well defined and you cannot provide compatibility 
at this level just from the spec.
   We have taken note of the main issues we found 
(see http://www.itc.unc.edu.ar/javadev/rmi/specissues.html);

and I'm wondering if this is enough to go to JCP and made a JSR
for rmi to get a better revised design/spec...

   I'll wait for your comments.

Thanks, 

Daniel 



- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 4:38 AM
Subject: RE: Contribution of RMI framework


Daniel,

Yeah, I'm also looking forward to a good discussion on that.
And I do believe we'd have a great Harmony RMI at the end.

Thanks to you also! :)

Vasily


-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 14, 2006 4:34 AM

To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

Vasily, 
   good to know that there is someone out there who has also 
been working on rmi; I believe we'll have a lot to share and discuss
about it.   

Thanks, 

Daniel 

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM (was
tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java 1.4
specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarifications are
needed, feel free to contact me. I will be happy to answer all questions
about this contribution and to participate in its further
development/maintenance and integration into Harmony.

Vasily Zakharov
Intel Middleware Product 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]

[rmi] package comparison (was Re: Contribution of RMI framework)

[Daniel Gandara]

Vasily,
   a couple of things about package comparison:

a) java 5.0 vs 1.4.2
Our rmi package was developed according to 5.0 rmi spec, and
it takes full advantage of 5.0 new features (like java.util.concurrent)
Since Harmony classlib and VMs are still in 1.4.2 we deployed
a 1.4.2 version of our package in which we removed the 5.0
dependencies.There is obviously a performance penalty
paid by the 1.4.2 release of the package.
You can find both versions of the packages at 
http://issues.apache.org/jira/browse/HARMONY-211


b) compatibility with reference implementation
  within our contribution you will find a complete set of test cases
(source code and documentation for each).   We run these test cases
against our package before contributing it, so I guess one way to
move further is to cross run test cases (you run ours and we run
yours).   What do you think?

c) performance analysis and comparison
   I believe the first step here is to get along about which is the
workload or set of applications that represent a "real" use of rmi
package.   I see a big challenge here...

I'll wait for your comments,

Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

Vasily


-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED]
Sent: Friday, April 14, 2006 7:53 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>:

Vasily,
   good to know that there is someone out there who has also
been working on rmi; I believe we'll have a lot to share and discuss
 about it.

Thanks,

Daniel

- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM (was
tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java

1.4

specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarifications

are

needed, feel free to contact me. I will be happy to answer all

questions

about this contribution and to participate in its further
development/maintenance and integration into Harmony.

Vasily Zakharov
Intel Middleware Product 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: Contribution of RMI framework

[Daniel Gandara]

I completelly agree with Vasily, doing test and performance analysis 
on RMI is not a trivial task; I'll coordinate with him the best way to 
compare the packages.


Daniel

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>

To: 
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

Vasily


-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 14, 2006 7:53 AM

To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>:

Vasily,
   good to know that there is someone out there who has also
been working on rmi; I believe we'll have a lot to share and discuss
 about it.

Thanks,

Daniel

- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM (was
tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java

1.4

specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarifications

are

needed, feel free to contact me. I will be happy to answer all

questions

about this contribution and to participate in its further
development/maintenance and integration into Harmony.

Vasily Zakharov
Intel Middleware Product 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: Contribution of RMI framework

[Daniel Gandara]

Vasily, 
good to know that there is someone out there who has also 
been working on rmi; I believe we'll have a lot to share and discuss
 about it.   

Thanks, 

Daniel 

- Original Message - 
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, April 12, 2006 9:53 PM
Subject: Contribution of RMI framework


Hi, all,

I would like to announce the next code contribution to Harmony project
on
behalf of Intel corporation. This contribution contains the
implementation
of RMI framework.

The archive with this contribution can be found at:

http://issues.apache.org/jira/browse/HARMONY-337

The Remote Method Invocation (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 please see the documentation contained in the
bundle.

The code is a result of efforts of Intel Middleware Product Division
team.
One should be able to run this code with a 1.4+ compatible JRE/VM (was
tested using commercial VMs). No classes require special support from
the VM.
All code is pure Java. The implementation is done according to Java 1.4
specification of RMI.

The archive contains the README file that explains the building and
running
process for this code. If any additional comments or clarifications are
needed, feel free to contact me. I will be happy to answer all questions
about this contribution and to participate in its further
development/maintenance and integration into Harmony.

Vasily Zakharov
Intel Middleware Product 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: [rmi] getting 1.4 bytecode

[Daniel Gandara]

I have uploaded java.rmi  -modified for getting 1.4 bytecode- to JIRA 
HARMONY-211


Daniel

- Original Message - 
From: "Daniel Gandara (JIRA)" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 11, 2006 2:52 PM
Subject: [jira] Updated: (HARMONY-211) Contribution of java.rmi



[ http://issues.apache.org/jira/browse/HARMONY-211?page=all ]

Daniel Gandara updated HARMONY-211:
---

   Attachment: antRMI-142.tar.bz2

This is a modified version of java.rmi to generate 1.4 bytecode 
(using -target jsr14 option); the file is prepared to be compiled using 
ant.
Under "[rmi] getting 1.4 bytecode" thread I have explained the changes 
made to the original 5.0 version of the code




- Original Message - 
From: "Daniel Gandara" <[EMAIL PROTECTED]>

To: 
Sent: Monday, April 10, 2006 4:11 PM
Subject: Re: [rmi] getting 1.4 bytecode



Oliver Deakin wrote:

Daniel Gandara wrote:
Hi,As discussed with Oliver, I built the rmi code with the -target 
jsr14 option and I got a 1.4 bytecode for the package.I run our test 
suit against the package and it seems to work ok.


That's great news!


This is a sum up of the experience:
1) -target jsr14 option only worked with Sun's compiler, Icould not 
make it work on Eclipse...


Tim described in [1] that the Eclipse batch compiler unfortunately does 
not support this kind of 1.5 to 1.4 compilation. There has been further 
discussion in that thread as to which solution is best for us - Sun 
compiler using -target jsr14, and/or Eclipse compiler at 1.5 level and 
then use a tool called Retroweaver to alter the bytecodes to work on 1.4.


yes I read the thread, I believe the goal is to find the way to automate
the use of Retroweaver within Eclipse... anyway I see no big deal
using the compiler with options to get 1.4 bytecode since this should
be done for a short time while harmony gets 1.5

2) I had to make changes to the code, basically I had tochange enums 
and change/remove java.util.concurrentclasses we use 
(ConcurrentHashMap andThreadPoolExecutor)


I got some enum examples working by just adding a basic Enumeration class 
to the java.lang package in luni, but I only trialled fairly simple 
cases. What kind of alterations did you need to make? It will be 
interesting to know some of the limits of this compiler option.



From my POV the limits of using this compiler option is basically to
classes or methods which do not exist on 1.4, and cases like enums
which are also new on 5.0.
One problem we did found is getting errors at runtime, since the code
compiles ok, but at run time there is a call to a method that is
not on 1.4, then you and had to go back and change to give 1.4
compatibility.

Here is a complete list of the changes made to the code:
a) Changing enum with classes, there was just one enum, and
   was changed by classes with static attributes (we had enum
   HttpHeaders and we changed it for class HttpHeaders holding
   a HashSet)
b) Call to method Timer(String, boolean) was replaced by
   Timer(boolean)
c) Call to method Timer.purge()  was commented
d) Call to method System.currentTimeMillis() was replaced by
   new Long(System.currentTimeMillis())
e) ThreadPoolExectutor was removed, so we always launch
   new threads
f) ConcurrentHashMap was replaced by a HashTable
g) Call to method Thread.getId() was replaced by
   Thread.hashcode()


note: there is obviously a performance penalty due to 2).

The question I have now is if I should send this modified code to be 
used in Harmony during this transitional phase or not.  What do you 
think?


I think it's probably a good thing to get the code out there so we can 
start to use it, even if this means making some temporary modifications.


I agree with you, I believe I willl upload the 1.4 jar to the JIRA
HARMONY-211 issue so the java.rmi package can go through the
process of acceptance and be used.

Regards,
Daniel



Regards,
Oliver

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED]




I'll be waitting for comments,
Daniel


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-

Re: [rmi] getting 1.4 bytecode

[Daniel Gandara]

Oliver Deakin wrote:

Daniel Gandara wrote:
Hi,As discussed with Oliver, I built the rmi code with the -target 
jsr14 option and I got a 1.4 bytecode for the package.I run our test 
suit against the package and it seems to work ok.


That's great news!


This is a sum up of the experience:
1) -target jsr14 option only worked with Sun's compiler, Icould not 
make it work on Eclipse...


Tim described in [1] that the Eclipse batch compiler unfortunately does 
not support this kind of 1.5 to 1.4 compilation. There has been further 
discussion in that thread as to which solution is best for us - Sun 
compiler using -target jsr14, and/or Eclipse compiler at 1.5 level and 
then use a tool called Retroweaver to alter the bytecodes to work on 1.4.


yes I read the thread, I believe the goal is to find the way to automate
the use of Retroweaver within Eclipse... anyway I see no big deal
using the compiler with options to get 1.4 bytecode since this should
be done for a short time while harmony gets 1.5

2) I had to make changes to the code, basically I had tochange enums 
and change/remove java.util.concurrentclasses we use 
(ConcurrentHashMap andThreadPoolExecutor)


I got some enum examples working by just adding a basic Enumeration class 
to the java.lang package in luni, but I only trialled fairly simple cases. 
What kind of alterations did you need to make? It will be interesting to 
know some of the limits of this compiler option.


From my POV the limits of using this compiler option is basically to

classes or methods which do not exist on 1.4, and cases like enums
which are also new on 5.0.
One problem we did found is getting errors at runtime, since the code
compiles ok, but at run time there is a call to a method that is
not on 1.4, then you and had to go back and change to give 1.4
compatibility.

Here is a complete list of the changes made to the code:
a) Changing enum with classes, there was just one enum, and
   was changed by classes with static attributes (we had enum
   HttpHeaders and we changed it for class HttpHeaders holding
   a HashSet)
b) Call to method Timer(String, boolean) was replaced by
   Timer(boolean)
c) Call to method Timer.purge()  was commented
d) Call to method System.currentTimeMillis() was replaced by
   new Long(System.currentTimeMillis())
e) ThreadPoolExectutor was removed, so we always launch
   new threads
f) ConcurrentHashMap was replaced by a HashTable
g) Call to method Thread.getId() was replaced by
   Thread.hashcode()


note: there is obviously a performance penalty due to 2).

The question I have now is if I should send this modified code to be used 
in Harmony during this transitional phase or not.  What do you think?


I think it's probably a good thing to get the code out there so we can 
start to use it, even if this means making some temporary modifications.


I agree with you, I believe I willl upload the 1.4 jar to the JIRA
HARMONY-211 issue so the java.rmi package can go through the
process of acceptance and be used.

Regards,
Daniel



Regards,
Oliver

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED]




I'll be waitting for comments,
Daniel


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[rmi] getting 1.4 bytecode

[Daniel Gandara]

Hi, 
   As discussed with Oliver, I built the rmi code with the 
-target jsr14 option and I got a 1.4 bytecode for the package.
I run our test suit against the package and it seems to work ok.   


This is a sum up of the experience:
1) -target jsr14 option only worked with Sun's compiler, I 
   could not make it work on Eclipse...
2) I had to make changes to the code, basically I had to 
   change enums and change/remove java.util.concurrent 
   classes we use (ConcurrentHashMap and 
   ThreadPoolExecutor)


note: there is obviously a performance penalty due to 2).

The question I have now is if I should send this modified code 
to be used in Harmony during this transitional phase or not.  
What do you think?


I'll be waitting for comments, 

Daniel 




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New IBM VME

[Daniel Gandara]

Oliver Deakin wrote:

ok, I'll ask there about removing 1.5 dependencies from java.rmi and
compile it to get 1.4 bytecode...


I hope that you would not have to remove too much when compiling to 1.4 
bytecodes - I guess this is something we still need to investigate. Have 
you tried building the rmi code with the -target jsr14 option? Id (amongst 
others, Im sure) be interested to hear what results you get, and whether 
any alterations are necessary.


I'll try building the code with -target jsr14 and see how much has to be
removed; I'll create a new thread with the results;  ok?




My hope is that in the not too distant future we may see one or two of 
the Harmony VMs stepping up to 1.5 level, and we can begin to use them 
with our classlib :)


hope so too.

Thanks,

Daniel



Regards,
Oliver

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED]



Daniel Gandara wrote:

Oliver,
   pleased to hear good news from you!!  I believe this is great for 
the project.
I have one question regarding the version of the VME, is it 1.5?   I'm 
asking this
because we have received contributions of some packages (for example: 
java.math
and java.rmi packages) which are 1.5 (compliant and dependant) but 
cannot be

used with current VM.

Thanks,

Daniel

- Original Message - From: "Oliver Deakin" 
<[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 04, 2006 1:26 PM
Subject: New IBM VME



Hi all,

I'm pleased to announce that a new IBM VME will be made available soon 
at:

  http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html

The new VME downloads are named Harmony-vme-win.IA32-v2.zip and 
Harmony-vme-linux.IA32-v2.tar.gz. I would like to stress that if you 
download these packages now, they will *not* work with the class 
library code currently in Harmony Subversion. This VME has been 
created looking forward to changes that have been discussed on the 
list, but have not yet been carried out. They are:
- completion of renaming of com.ibm packages, especially in LUNI 
module. The new VME expects only org.apache.harmony package names.
- removal of String from the kernel, and addition of an intern(String) 
method to the org.apache.harmony.kernel.vm.VM class. The new VME does 
*not* contain String in its kernel jars. It does, however, provide an 
intern(String) method in the VM class, as was suggested in [1]. The 
String.intern() method in Harmony will just redirect the call to 
VM.intern(String).


Once these changes are made in the Harmony repository, the new version 
of the VME will be required to run with Harmony classlib. I will send 
out a further mail when this is done confirming that the new VME is 
available and ready to use.


A link to the VME v1 will still be available in the same place, and 
this should still be used until the above changes are made.


Regards,
Oliver


[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.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]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New IBM VME

[Daniel Gandara]

Oliver Deakin wrote:

Daniel,
The new VME is still at the 1.4 level, but with updated VM and kernel 
classes. As I have mentioned, two of the main reasons for this VME update 
was to allow for package renaming to go ahead, and also to allow String to 
be removed from the kernel, making kernel implementation easier for other 
VM providers. If there is a necessity in the future for a 1.5 VME, then 
one could be created, but currently classlib only requires 1.4.


agreed, but it is hard to think of a "current" classlib requiring 1.5 when
the available VMs are 1.4   for example: we have contributed two
packages: java.math and java.rmi which are 1.5 compliant and dependent
but they are waiting at the JIRA

I believe that while we are in a transitional phase from 1.4 to 1.5, a 1.4 
VME will suffice, and the solution that is being discussed in the 
"[classlib] Switching to a 5.0 compiler" [1] is the way to go ahead for 
the moment.


ok, I'll ask there about removing 1.5 dependencies from java.rmi and
compile it to get 1.4 bytecode...

My hope is that in the not too distant future we may see one or two of the 
Harmony VMs stepping up to 1.5 level, and we can begin to use them with 
our classlib :)


hope so too.

Thanks,

Daniel



Regards,
Oliver

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED]



Daniel Gandara wrote:

Oliver,
   pleased to hear good news from you!!  I believe this is great for the 
project.
I have one question regarding the version of the VME, is it 1.5?   I'm 
asking this
because we have received contributions of some packages (for example: 
java.math
and java.rmi packages) which are 1.5 (compliant and dependant) but cannot 
be

used with current VM.

Thanks,

Daniel

- Original Message - From: "Oliver Deakin" 
<[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 04, 2006 1:26 PM
Subject: New IBM VME



Hi all,

I'm pleased to announce that a new IBM VME will be made available soon 
at:

  http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html

The new VME downloads are named Harmony-vme-win.IA32-v2.zip and 
Harmony-vme-linux.IA32-v2.tar.gz. I would like to stress that if you 
download these packages now, they will *not* work with the class library 
code currently in Harmony Subversion. This VME has been created looking 
forward to changes that have been discussed on the list, but have not 
yet been carried out. They are:
- completion of renaming of com.ibm packages, especially in LUNI module. 
The new VME expects only org.apache.harmony package names.
- removal of String from the kernel, and addition of an intern(String) 
method to the org.apache.harmony.kernel.vm.VM class. The new VME does 
*not* contain String in its kernel jars. It does, however, provide an 
intern(String) method in the VM class, as was suggested in [1]. The 
String.intern() method in Harmony will just redirect the call to 
VM.intern(String).


Once these changes are made in the Harmony repository, the new version 
of the VME will be required to run with Harmony classlib. I will send 
out a further mail when this is done confirming that the new VME is 
available and ready to use.


A link to the VME v1 will still be available in the same place, and this 
should still be used until the above changes are made.


Regards,
Oliver


[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.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]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New IBM VME

[Daniel Gandara]

Oliver,
   pleased to hear good news from you!!  I believe this is great for the 
project.
I have one question regarding the version of the VME, is it 1.5?   I'm 
asking this
because we have received contributions of some packages (for example: 
java.math

and java.rmi packages) which are 1.5 (compliant and dependant) but cannot be
used with current VM.

Thanks,

Daniel

- Original Message - 
From: "Oliver Deakin" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, April 04, 2006 1:26 PM
Subject: New IBM VME



Hi all,

I'm pleased to announce that a new IBM VME will be made available soon at:
  http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html

The new VME downloads are named Harmony-vme-win.IA32-v2.zip and 
Harmony-vme-linux.IA32-v2.tar.gz. I would like to stress that if you 
download these packages now, they will *not* work with the class library 
code currently in Harmony Subversion. This VME has been created looking 
forward to changes that have been discussed on the list, but have not yet 
been carried out. They are:
- completion of renaming of com.ibm packages, especially in LUNI module. 
The new VME expects only org.apache.harmony package names.
- removal of String from the kernel, and addition of an intern(String) 
method to the org.apache.harmony.kernel.vm.VM class. The new VME does 
*not* contain String in its kernel jars. It does, however, provide an 
intern(String) method in the VM class, as was suggested in [1]. The 
String.intern() method in Harmony will just redirect the call to 
VM.intern(String).


Once these changes are made in the Harmony repository, the new version of 
the VME will be required to run with Harmony classlib. I will send out a 
further mail when this is done confirming that the new VME is available 
and ready to use.


A link to the VME v1 will still be available in the same place, and this 
should still be used until the above changes are made.


Regards,
Oliver


[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.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]





-
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: Contribution of java.rmi

[Daniel Gandara]

FaeLLe wrote

Yes i figured it was Birelli's reference counting algorithm.


yes, remember that we followed Sun's spec, and it says on section 3.3:
"RMI uses a referencecounting garbage collection algorithm similar to
Modula-3's Network Objects.  (See "Network Objects" by Birrell, Nelson,
and Owicki)"


Our university research group has currently identified faults with that
speific algorithm and I am working on an implementation of the revised
version.


yes, we are aware of some of the faults, like creating a circular reference.
BTW: Sun's implementation has the same problem.


However I was wondering if you could point me towards some
literature/material that discusses these specific features that are imposed
by RMI's dgc api spec ? These would be very beneficial.


Unfortunatelly we did not have any document describing these specific
features;  we worked based on Birrel algorithm and we implemented the
API, while doing that we found some non-solved issues, and we created
our own solution for them.
What we did document were some issues we found on the spec.
(follow this links for further info:
http://www.itc.unc.edu.ar/javadev/rmi/knownissues.html#10
http://www.itc.unc.edu.ar/javadev/rmi/specissues.html#8 )

Daniel


On 3/23/06, Daniel Gandara <[EMAIL PROTECTED]> wrote:


We use a "reference counting" algorithm based on the Modula3,
plus specific features  imposed by the rmi dgc's api spec.

Daniel


- Original Message -
From: "FaeLLe" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, March 22, 2006 4:34 PM
Subject: Re: ITC: Contribution of java.rmi


Hello Daniel,

Can you please tell us which algorithm you made use of for the Distributed
Garbage Collector ?

I am currently researching in this field and details would benifit me.

Regards,

- Vikram

On 3/22/06, Daniel Gandara <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> We are thinking in making a release of java.rmi package compatible with
> harmony's VM and classlib code (1.4.2),  using the compiler options that
> allow partial 5.0 language features, and removing all j.u.c classes we
> use.
> We know that we will loose performance, but it looks like it is worth a
> try.
> What do you think?
>
> Daniel
>
> PS: Faxes have been re-sent, please let me know if there is any further
> problem.
>
> - Original Message -
> From: "Geir Magnusson Jr" <[EMAIL PROTECTED]>
> To: 
> Sent: Sunday, March 19, 2006 10:45 AM
> Subject: Re: ITC: Contribution of java.rmi
>
>
> > Thanks - this is great.
> >
> > Please not that every faxed document that both I and Jim, the ASF
> > Secretary, received was unreadable.
> >
> > I can't know if it was the original copy, or the fax machine, but we
> need
> > to have everything resent again.
> >
> > THanks
> >
> > geir
> >
> >
> > [EMAIL PROTECTED] wrote:
> >>   As announced before we are contributing java.rmi package on behalf
of
> >> ITC
> >> (Cordoba Institute of Technology).
> >>
> >> Below is a short description of the contribution.
> >>
> >> Daniel Gandara
> >>
> >> --
> >>
> >> Package name  java.rmi
> >>
> >> Package Description
> >>
> >>  Clean room implementation of java.rmi following J2SE 1.5 spec
> >>  www.fitc.unc.edu.ar/javadev/rmi/index.html
> >>
> >>
> >> Current Status
> >>  Currently our package contains implementation for:
> >>  - java.rmi
> >>  - java.rmi.dgc
> >>  - java.rmi.registry
> >>  - java.rmi.server
> >>
> >>  package java.rmi.activation and deprecated method/classes
> >> have not been implemented. Activation have been designed but
> >> has not been implemented yet.
> >>
> >>  Tools like rmic and rmiregistry have not been implemented.
> >>
> >>
> >> Architectural Design
> >>  Package has been architected following a layered design, which
> >> seem to be the most appropriate model for the RMI implementation
> >> in accordance with the specification.
> >>  For further details check
> >> www.fitc.unc.edu.ar/javadev/rmi/architecture.html
> >>
> >>
> >> Javadoc
> >>
> >> Javadoc of the package can be reached here
> >> www.fitc.unc.edu.ar/javadev/rmi/javadocRMI/index.html
> >>
> >> Testing
> >>   Unit and integration tests (and their documentation) are
> >> provided with the code.
> >>
> >>
> >> Implementation Notes
> >>  The code uses J2SE 5.0 features, such as generics, so it
> >> requires 5.0 VM and libraries (i.e.: java.util.concurrent).
> >> It has been tested against Sun SDK, removing the original
> >> java.rmi.* and replacing it by ours.
> >> www.fitc.unc.edu.ar/javadev/rmi/ideas_uro.html
> >>
> >>
> >> Known Issues
> >> www.fitc.unc.edu.ar/javadev/rmi/knownissues.html
> >>
> >> Specification Issues
> >> www.fitc.unc.edu.ar/javadev/rmi/specissues.html
> >>
> >>
> >>
> >>
> >>
>
>


--
www.FaeLLe.com
www.VikramMohan.com






--
www.FaeLLe.com
www.VikramMohan.com

Re: ITC: Contribution of java.rmi

[Daniel Gandara]

We use a "reference counting" algorithm based on the Modula3,
plus specific features  imposed by the rmi dgc's api spec.

Daniel


- Original Message - 
From: "FaeLLe" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, March 22, 2006 4:34 PM
Subject: Re: ITC: Contribution of java.rmi


Hello Daniel,

Can you please tell us which algorithm you made use of for the Distributed
Garbage Collector ?

I am currently researching in this field and details would benifit me.

Regards,

- Vikram

On 3/22/06, Daniel Gandara <[EMAIL PROTECTED]> wrote:


Hi,

We are thinking in making a release of java.rmi package compatible with
harmony's VM and classlib code (1.4.2),  using the compiler options that
allow partial 5.0 language features, and removing all j.u.c classes we
use.
We know that we will loose performance, but it looks like it is worth a
try.
What do you think?

Daniel

PS: Faxes have been re-sent, please let me know if there is any further
problem.

- Original Message -
From: "Geir Magnusson Jr" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, March 19, 2006 10:45 AM
Subject: Re: ITC: Contribution of java.rmi


> Thanks - this is great.
>
> Please not that every faxed document that both I and Jim, the ASF
> Secretary, received was unreadable.
>
> I can't know if it was the original copy, or the fax machine, but we
need
> to have everything resent again.
>
> THanks
>
> geir
>
>
> [EMAIL PROTECTED] wrote:
>>   As announced before we are contributing java.rmi package on behalf of
>> ITC
>> (Cordoba Institute of Technology).
>>
>> Below is a short description of the contribution.
>>
>> Daniel Gandara
>>
>> --
>>
>> Package name  java.rmi
>>
>> Package Description
>>
>>  Clean room implementation of java.rmi following J2SE 1.5 spec
>>  www.fitc.unc.edu.ar/javadev/rmi/index.html
>>
>>
>> Current Status
>>  Currently our package contains implementation for:
>>  - java.rmi
>>  - java.rmi.dgc
>>  - java.rmi.registry
>>  - java.rmi.server
>>
>>  package java.rmi.activation and deprecated method/classes
>> have not been implemented. Activation have been designed but
>> has not been implemented yet.
>>
>>  Tools like rmic and rmiregistry have not been implemented.
>>
>>
>> Architectural Design
>>  Package has been architected following a layered design, which
>> seem to be the most appropriate model for the RMI implementation
>> in accordance with the specification.
>>  For further details check
>> www.fitc.unc.edu.ar/javadev/rmi/architecture.html
>>
>>
>> Javadoc
>>
>> Javadoc of the package can be reached here
>> www.fitc.unc.edu.ar/javadev/rmi/javadocRMI/index.html
>>
>> Testing
>>   Unit and integration tests (and their documentation) are
>> provided with the code.
>>
>>
>> Implementation Notes
>>  The code uses J2SE 5.0 features, such as generics, so it
>> requires 5.0 VM and libraries (i.e.: java.util.concurrent).
>> It has been tested against Sun SDK, removing the original
>> java.rmi.* and replacing it by ours.
>> www.fitc.unc.edu.ar/javadev/rmi/ideas_uro.html
>>
>>
>> Known Issues
>> www.fitc.unc.edu.ar/javadev/rmi/knownissues.html
>>
>> Specification Issues
>> www.fitc.unc.edu.ar/javadev/rmi/specissues.html
>>
>>
>>
>>
>>





--
www.FaeLLe.com
www.VikramMohan.com

Re: ITC: Contribution of java.rmi

[Daniel Gandara]

Hi,

We are thinking in making a release of java.rmi package compatible with 
harmony's VM and classlib code (1.4.2),  using the compiler options that 
allow partial 5.0 language features, and removing all j.u.c classes we use. 
We know that we will loose performance, but it looks like it is worth a try. 
What do you think?


Daniel

PS: Faxes have been re-sent, please let me know if there is any further 
problem.


- Original Message - 
From: "Geir Magnusson Jr" <[EMAIL PROTECTED]>

To: 
Sent: Sunday, March 19, 2006 10:45 AM
Subject: Re: ITC: Contribution of java.rmi



Thanks - this is great.

Please not that every faxed document that both I and Jim, the ASF 
Secretary, received was unreadable.


I can't know if it was the original copy, or the fax machine, but we need 
to have everything resent again.


THanks

geir


[EMAIL PROTECTED] wrote:
  As announced before we are contributing java.rmi package on behalf of 
ITC

(Cordoba Institute of Technology).

Below is a short description of the contribution.

Daniel Gandara

--

Package name  java.rmi

Package Description

 Clean room implementation of java.rmi following J2SE 1.5 spec
 www.fitc.unc.edu.ar/javadev/rmi/index.html


Current Status
 Currently our package contains implementation for:
 - java.rmi
 - java.rmi.dgc
 - java.rmi.registry
 - java.rmi.server

 package java.rmi.activation and deprecated method/classes
have not been implemented. Activation have been designed but
has not been implemented yet.

 Tools like rmic and rmiregistry have not been implemented.


Architectural Design
 Package has been architected following a layered design, which
seem to be the most appropriate model for the RMI implementation
in accordance with the specification.
 For further details check 
www.fitc.unc.edu.ar/javadev/rmi/architecture.html



Javadoc

Javadoc of the package can be reached here
www.fitc.unc.edu.ar/javadev/rmi/javadocRMI/index.html

Testing
  Unit and integration tests (and their documentation) are
provided with the code.


Implementation Notes
 The code uses J2SE 5.0 features, such as generics, so it
requires 5.0 VM and libraries (i.e.: java.util.concurrent).
It has been tested against Sun SDK, removing the original
java.rmi.* and replacing it by ours.
www.fitc.unc.edu.ar/javadev/rmi/ideas_uro.html


Known Issues
www.fitc.unc.edu.ar/javadev/rmi/knownissues.html

Specification Issues
www.fitc.unc.edu.ar/javadev/rmi/specissues.html

Re: ITC's Contribution

[Daniel Gandara]

I found that j.u.c backport is based -in part- on sources from the 
JCP JSR 166 CVS repository so the source code is somehow under 
JRL/JDL and that -I believe- makes the code unacceptable for 
Harmony.  

Daniel


> Daniel Gandara wrote:
> What about the j.u.c backport to 1.4 
> (http://dcl.mathcs.emory.edu/util/backport-util-concurrent/index.php)
> it may be a good starting point, on their page they say:
> 
> "The code can be used for any purpose, modified, and redistributed
> without acknowledgment. No warranty is provided, either express or
> implied.
> Note: versions prior to 2.1 had dependencies on proprietary code.
> As of 2.1, any such dependencies have been removed."
> 
> what do you think?
> 
> 
> 
> Daniel
> 
> -Original Message-
> From: Daniel Gandara [mailto:[EMAIL PROTECTED]
> Sent: Wed Mar 08 12:26:18 2006
> To: harmony-dev@incubator.apache.org
> Subject: Re: ITC's Contribution
> 
>>> Tim Ellison wrote:
>>> i.e. have you tried running it with the original code (EDU.oswego.cs.dl)
>>> from Doug's website or only the concurrent utils in 5.0 (JSR166)?
>>>
>> Daniel Gandara wrote:
>> we have only tried with the concurrent utils in 5.0, but we will try with
>> Doug's and see how it behaves, I'll let you know.
> 
> As promised, we've checked EDU.oswego.cs.dl.util.concurrent package (
> http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html)
> and while it works beautifully, it seems to not be compliant with the specs
> for
> java.util.concurrent (e.g. it is missing some pieces, such as
> ThreadPoolExecutor,
> etc). Therefore, I am hesitant of adapting our harmony-compliant package to
> it,
> as it may not be acceptable by Harmony once we are done. What do you think?
> 
> As stated above, we've checked with JSR166
> (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html )
> and we are ok with it, since it complies with the spec. However, I am not
> sure
> we can use this as part of Harmony, can we?
> 
> Daniel
> 
>

Re: ITC's Contribution

[Daniel Gandara]

"Magnusson, Geir" wrote
I don't think that you can do full j.u.c w/o support from the vm.


I agree on that.


Are you saying that what is there works w/ the oswego code?


No, our (java.rmi) code does not work with it; the oswego code
does not support generics and it is not compliant with the spec for
j.u.c.; what I said is that we may adapt our code to work with
oswego but that will move us away from Harmony's goal.


It ok if its not complete...  We can continue w it once we get
a v5 vm.


What about the j.u.c backport to 1.4 
(http://dcl.mathcs.emory.edu/util/backport-util-concurrent/index.php)

it may be a good starting point, on their page they say:

"The code can be used for any purpose, modified, and redistributed
without acknowledgment. No warranty is provided, either express or
implied.
Note: versions prior to 2.1 had dependencies on proprietary code.
As of 2.1, any such dependencies have been removed."

what do you think?



Daniel

-----Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED]
Sent: Wed Mar 08 12:26:18 2006
To: harmony-dev@incubator.apache.org
Subject: Re: ITC's Contribution


Tim Ellison wrote:
i.e. have you tried running it with the original code (EDU.oswego.cs.dl)
from Doug's website or only the concurrent utils in 5.0 (JSR166)?


Daniel Gandara wrote:
we have only tried with the concurrent utils in 5.0, but we will try with
Doug's and see how it behaves, I'll let you know.


As promised, we've checked EDU.oswego.cs.dl.util.concurrent package (
http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html)
and while it works beautifully, it seems to not be compliant with the specs
for
java.util.concurrent (e.g. it is missing some pieces, such as
ThreadPoolExecutor,
etc). Therefore, I am hesitant of adapting our harmony-compliant package to
it,
as it may not be acceptable by Harmony once we are done. What do you think?

As stated above, we've checked with JSR166
(http://gee.cs.oswego.edu/dl/concurrency-interest/index.html )
and we are ok with it, since it complies with the spec. However, I am not
sure
we can use this as part of Harmony, can we?

Daniel

Re: ITC's Contribution

[Daniel Gandara]

Tim Ellison wrote:
i.e. have you tried running it with the original code (EDU.oswego.cs.dl)
from Doug's website or only the concurrent utils in 5.0 (JSR166)?


Daniel Gandara wrote:
we have only tried with the concurrent utils in 5.0, but we will try with
Doug's and see how it behaves, I'll let you know.


As promised, we've checked EDU.oswego.cs.dl.util.concurrent package ( 
http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html)
and while it works beautifully, it seems to not be compliant with the specs 
for
java.util.concurrent (e.g. it is missing some pieces, such as 
ThreadPoolExecutor,
etc). Therefore, I am hesitant of adapting our harmony-compliant package to 
it,

as it may not be acceptable by Harmony once we are done. What do you think?

As stated above, we've checked with JSR166 
(http://gee.cs.oswego.edu/dl/concurrency-interest/index.html )
and we are ok with it, since it complies with the spec. However, I am not 
sure

we can use this as part of Harmony, can we?

Daniel 

Re: ITC's Contribution

[Daniel Gandara]

> Daniel Gandara wrote:
> >>> c) Some still missing components...
> >>> we have checked some pre-conditions before making this announcement
and
> >>> we  found that there are some components we need (i.e.: concurrent)
> >>> which
> >>> are  not on Harmony yet.  Is someone working on those missing
> >>> components?
> >
> >> I'm not sure.  We were thinking about using Doug Lea's to start.
> >>
> >> Are you working on that now?
> >>
> >
> > No, we are not working on concurrent component.  We use concurrent at
> > java.rmi package, so it is one of the missing requisite for our
> > implementation to work; the other big one is 1.5 :)
>
> I expect that Geir meant, "does your code work with Doug Lea's
> concurrent utils now" (and if he didn't I'll ask the question anyway!)

ok.   Geir: sorry if I missunderstood you :)
>
> i.e. have you tried running it with the original code (EDU.oswego.cs.dl)
> from Doug's website or only the concurrent utils in 5.0 (JSR166)?
>

we have only tried with the concurrent utils in 5.0, but we will try with
Doug's
and see how it behaves, I'll let you know.

Regards,

Daniel

Re: ITC's Contribution

[Daniel Gandara]

c) Some still missing components...
we have checked some pre-conditions before making this announcement and
we  found that there are some components we need (i.e.: concurrent) which
are  not on Harmony yet.  Is someone working on those missing components?



I'm not sure.  We were thinking about using Doug Lea's to start.

Are you working on that now?



No, we are not working on concurrent component.  We use concurrent at 
java.rmi package, so it is one of the missing requisite for our 
implementation to work; the other big one is 1.5 :)


Daniel Gandara