Daniel, > black-box testing (reverse engineering I would call the complete procedure)
Black-box testing is NOT reverse engineering, as the latter could suggest disassembling the code or something like that, that would violate the clean-room procedures and that we certainly didn't do. What we were doing is checking carefully how our implementation works with reference implementation, and making sure the RI gets what it asks for in the protocol. > is an approach, but, can you be sure you are 100% compatible? No, of course we can't, as we didn't pass the Java TCK. :) But we were testing interoperability extensively, and also tried the real applications. > what about other providers? I don't know, we didn't check any other providers. But if they're compatible with RI, they would most probably be also compatible with our implementation. :) > so we should now move on comparing what is comparable between the packages: its functionality. Yeah, I agree with that. > I mean, you can provide compatibility with reference implementation > (let's say provider A), but what about users working with provider B? > or C? are you assuming all providers do the same black-boxing? and > if so, all of them arrived to the same conclusion about how the wire > protocol behaves? Surely, we can do nothing about this (except improving the spec, which is surely good, but a very long process). If all providers strive to be compatible with reference implementation - they probably would be compatible to each other. If they don't - they would never be compatible. Also, the reference implementation is still most widely used, so being compatible to it is most important. > Standards and specifications are what interoperability is all about! Yes, of course, I fully agree with this. > there is no way in which you can provide compatibility if there is no standard; And this is the thing I can't agree with. Standard greatly helps in achieving compatibility, but that can also be done without a standard. > so I strongly believe that having a better quality spec is the > way we can really benefit the community ... if not, you -and I and > other providers too- will always be one step behind the "reference" > implementation, spending lots of hours and resources finding > out how things are being done inside the black box. Yes, of course, improving the spec is a great goal. But it's a long term goal, and I completely agree with you on this - in long term. But improving the spec would probably take years, and we surely need some short term solution to provide to the community now. > it will be great if you contribute what you have conclude about the protocol. Hmm, we've already done that - it's already in the code. We weren't writing any documentation about the internal details of our implementation, we were only noting things in the doc where our implememtation behaved differently than the RI. Vasily -----Original Message----- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 1:17 AM To: harmony-dev@incubator.apache.org Subject: Re: [rmi] package comparison (was Re: Contribution of RMI framework) Zakharov, Vasily M wrote >Daniel, > >> We started our development as a clean room implementation >> of the package following the spec; and we found it -the spec >> (JRMP included)- to be vague and incomplete making it impossible >> for us to get interoperability without doing "code inspection" >> or "reverse engineering", which was not allowed by the imposed >> clean-room restriction. I believe you faced the same situation, >> and it will be good to know how you tackle it without compromising >> your development. > >Of course, we also followed the clean-room restrictions, but we >struggled to be compatible with reference implementation and used >a lot of black-box testing to find out what goes on in the reference >implementation data exchange. black-box testing (reverse engineering I would call the complete procedure) is an approach, but, can you be sure you are 100% compatible? what about other providers? >> Having said that, I believe comparision between packages should >> be done based on functionality and NOT on interoperability since >> it is -at least- underspecified and it can be 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 know how you tackle it without compromising your development. Our strategic decision at that moment was to move forward on the development being sure about the "cleanliness" and left the reverse engineering of the wire protocol to be done later after the package is complete. This is the main reasons why I sent the "[rmi] spec issues" post presenting the problems we found on the spec; which I believe are strong enough to ask for a JSR or at least a clarification on the spec. For a detailed list of the issues we found on the spec please go to http://www.itc.unc.edu.ar/javadev/rmi/specissues.html . 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. Needeless to say, I'm aware of the critical impact interoperability has and we are currently working on that. Daniel PS: if you do have further information/description of the JRMP protocol please send it ot me, since it will be very usefull. ----- Original Message ----- From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: <harmony-dev@incubator.apache.org> Sent: Tuesday, April 18, 2006 2:57 PM Subject: RE: [rmi] package comparison (was Re: Contribution of RMI framework) Daniel, I've been trying to do some comparisons, as I promised, and I believe I'm missing something. I was testing the interoperability, and when I tried to use an "Intel" RMI client against an "ITC" server, it failed, although it worked against a "Sun" server. Changing client and server produces the same result. Here're the stack traces I get, the test code and the config. Any idea, what I'm doing wrong? Vasily Zakharov Intel Middleware Products Division Stack trace 1 ("ITC" client, "Sun" or "Intel" server): java.rmi.ConnectIOException: I/O exception Creating Connection; nested exception is: java.rmi.MarshalException: Exception marshaling JRMP Header; nested exception is: java.rmi.UnmarshalException: Exception reading the Header response; nested exception is: java.io.EOFException at ar.org.fitc.rmi.transport.ConnectionPool.getClientConnection(Unknown Source) at ar.org.fitc.rmi.transport.TransportManager.invoke(Unknown Source) at ar.org.fitc.rmi.server.UnicastRemoteRefImpl.invoke(Unknown Source) at ar.org.fitc.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) at Client.main(Client.java:14) Caused by: java.rmi.MarshalException: Exception marshaling JRMP Header; nested exception is: java.rmi.UnmarshalException: Exception reading the Header response; nested exception is: java.io.EOFException at ar.org.fitc.rmi.transport.StreamClientConnection.handshake(Unknown Source) at ar.org.fitc.rmi.transport.StreamClientConnection.establishConnection(Unk nown Source) ... 5 more Caused by: java.rmi.UnmarshalException: Exception reading the Header response; nested exception is: java.io.EOFException at ar.org.fitc.rmi.transport.jrmp.ClientProtocolHandler.readHandshakeRespon se(Unknown Source) ... 7 more Caused by: java.io.EOFException at java.io.DataInputStream.readByte(Unknown Source) ... 8 more Stack trace 2 ("Intel" client, "ITC" server): java.rmi.ConnectIOException: Unable to acknowledge protocol with server; nested exception is: java.io.EOFException at org.apache.harmony.rmi.transport.tcp.TcpConnection.serverProtocolAck(Tcp Connection.java:145) at org.apache.harmony.rmi.client.ClientConnection.<init>(ClientConnection.j ava:90) at org.apache.harmony.rmi.transport.tcp.TcpConnection.<init>(TcpConnection. java:73) at org.apache.harmony.rmi.client.ClientConnectionManager.getConnection(Clie ntConnectionManager.java:107) at org.apache.harmony.rmi.remoteref.UnicastRef.newCall(UnicastRef.java:226) at org.apache.harmony.rmi.remoteref.UnicastRef.invoke(UnicastRef.java:127) at org.apache.harmony.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_St ub.java:134) at Client.main(Client.java:14) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(Unknown Source) at org.apache.harmony.rmi.transport.tcp.TcpConnection.serverProtocolAck(Tcp Connection.java:112) ... 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, 5555); System.out.println("Binding object to registry"); registry.rebind("TestRemoteObject", obj); System.out.println("Sleeping 10 seconds"); Thread.sleep(10000); } 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 ----- Original Message ----- From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: <harmony-dev@incubator.apache.org> 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: <harmony-dev@incubator.apache.org> > 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] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
