Martin, you wrote: > In article <[EMAIL PROTECTED]>, > Evan Ireland <[EMAIL PROTECTED]> wrote: > >So basically java.util.List and java.util.Collection map to empty valuetypes, > >or valuetypes with methods and no data. > > > >I can't see how a C++ client can ever use that! > > If that all there is, a Java client cannot use that either. GIOP clearly > defines how an empty value type is transmitted: essentially as an empty > octet string (plus some type information). > > I think there is a piece missing: The actual thing returned won't be > just a List, but a LinkedList, or a Vector, or the like. I know nothing > about java2idl, but I guess you'd need valuetypes for the concrete > realizations of the List interface. Are you sure List maps to a valuetype, > and not to an abstract valuetype? The Java to IDL specification is particularly hard to read, since when it refers to "Java class" in several places it is not clear whether that is intended to mean "Java class or interface". Anyway, thanks for pointing out the possibility that the List interface maps to an abstract valuetype. > Consider a specific implementaiton of List, e.g. Vector. AFAICT, it maps > to > > valuetype Vector{ > private long capacityIncrement; > private long elementCount; > private sequence<java::lang::Object> elementData; > }; > > I think it is perfectly clear how to access this in C++, provided you know > what java::lang::Object is. I think the Vector IDL valuetype needs to be related to the abstract valuetype for List. java::lang::Object maps to CORBA IDL 'any', so the C++ client in this case needs to access the first 'elementCount' elements in 'elementData', and extract an object reference from each of them in the case I was referring to. Then of course since the fields are private in the IDL valuetype the corresponding C++ definition will have protected fields, so they can not be directly accessed by a C++ client. Instead they can only be accessed by the implementation of these methods. How many people are going to be forced to reinvent the wheel by attempting non-Java implementations of valuetype operations? Although this would appear to be workable, it relies on the client programmer to know which concrete implementation of the List type has been used by the Java server developer. It is also extremely cumbersome for a client developer to be using extraction of object references from 'any' (or worse, since Vector is surely the most easily mapped collection type) just to deal with the typical case of an entity bean's finder method returning a collection of object references. > It looks like a client of java2idl must be aware of the complete Java type > system. Somehow, this does not surprise me at all. What surprises me is how many people think that this whole valuetype mess is a viable interoperability solution for Java/EJB servers with non-Java clients. What would perhaps be extremely useful is if the OMG would define two simple valuetypes, one for a collection of value types, and one for a collection of object references, and of course require that every language mapping specify the 'implementation' code for the valuetype operations. Then we could promote (in the interests of interoperability) that programmers restrict themselves to using these valuetypes for if they are interested in usable interoperability. ________________________________________________________________________________ Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED] Wellington - New Zealand +64 4 934-5856 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
