Re: [dev] Ideas on mapping UNO IDL to Java 5
王在祥 wrote: Attachment is some demo code on mapping IDL to Java5, the mapping is compatible with old version, and require no change of the UNO runtime. All the idea is just provide a more clear API for java to access exists component and write new Components in java. Not sure in how far your example provides a cleaner API to use existing components or to implement new components. Your examples only affect Java classes that are representations of UNO types. Those are classes that are only *used*, but not *written*, when writing code that uses or implements UNO components. In how far your proposed @UnoType annotations are easier to understand than a UNOIDL description is IMO a rather subjective matter. However, since any given UNO type is typically not only used within a Java 5 UNO language binding alone, but within a variety of different UNO language bindings, I think it is best to have a single, language-independent format to express those types. BTW, I think it is better to deploy an Compile-With-Debug-Information version jars and the related build SRC.zip for each jars in the classes directory, which will makes the developer take help from modern IDE such as eclipse. We lost the .java files for UNOIDL types when adding polymorphic struct types to UNO---to have .class files that work with both Java 1.3/1.4 and Java 5, we had to generate them by hand instead of through a javac. There is currently work under way to improve IDE integration for UNO, and specifically to have some means by which Java source code corresponding to a given UNOIDL type can be made available to a user. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Ideas on mapping UNO IDL to Java 5
Hi, thanks for sharing your ideas ... 王在祥 wrote: I am a beginner of OpenOffice and I am learning the SDK document now. Instead, i found the mapping from IDL to java looks missing something: 1. the mapped Java classes contains less information than the IDL, By using the Java 5 annotations will solve this problem, and we can even write no IDL at all, and simply writing the Java classes, and using a tool to generate the IDL if neccessary. We cannot use Java 5 features because we have to be compatible with older versions. 2. the Out/In Out parameter mapping is something strange. I think using a OutHolderT or InOutHolderT will be more clear see above 3. No Service is mapped, this require the queryInterface called frequently. I think a Service can be mapped to an interface which may extends other interface or aggregate optional interface inside. that 's true for old services but not for the new UNO ease of use extensions. See http://udk.openoffice.org/common/man/draft/multinherit.html for more details. And more, i think there should be a util to generate the POJO mapping from exists IDL(Its better to include the documents in Java). i am not sure if I understand you but with the new javamaker tool we generate directly Java class files from the type library. The type library is currently necessary for the UNO runtime to get the necessary type information (Basic, C++). Yes we have thought about a TypeProvider who works on IDL or better on Java class files directly but haven't implement it until now. Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Ideas on mapping UNO IDL to Java 5
王在祥 wrote: I am a beginner of OpenOffice and I am learning the SDK document now. Instead, i found the mapping from IDL to java looks missing something: The Java UNO language binding predates Java 5 by some years. That might explain why some of its features look strange or less than optimal in a Java 5 context. Also, we try hard to keep the Java UNO language binding and Java UNO environment compatible with Java 1.3. 1. the mapped Java classes contains less information than the IDL, By using the Java 5 annotations will solve this problem, and we can even write no IDL at all, and simply writing the Java classes, and using a tool to generate the IDL if neccessary. Only little information is missing (e.g., typedefs), most information is preserved in the form of com.sun.star.lib.uno.typeinfo.TypeInfo arrays. That information should suffice to write such a tool, if you like. 2. the Out/In Out parameter mapping is something strange. I think using a OutHolderT or InOutHolderT will be more clear For Java 1.4 and earlier, using arrays is more type safe (though clumsier) than using some (type-erased) HolderT. 3. No Service is mapped, this require the queryInterface called frequently. I think a Service can be mapped to an interface which may extends other interface or aggregate optional interface inside. New-style services do something very similar. And more, i think there should be a util to generate the POJO mapping from exists IDL(Its better to include the documents in Java). Sorry, no idea what that sentence should mean. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Ideas on mapping UNO IDL to Java 5
The Java UNO language binding predates Java 5 by some years. That might explain why some of its features look strange or less than optimal in a Java 5 context. Also, we try hard to keep the Java UNO language binding and Java UNO environment compatible with Java 1.3. Sure. Is it possible to support both Java 1.3 and Java 5(with new features)? New-style services do something very similar. Sorry, i need to learn it.
Re: [dev] Ideas on mapping UNO IDL to Java 5
王在祥 wrote: The Java UNO language binding predates Java 5 by some years. That might explain why some of its features look strange or less than optimal in a Java 5 context. Also, we try hard to keep the Java UNO language binding and Java UNO environment compatible with Java 1.3. Sure. Is it possible to support both Java 1.3 and Java 5(with new features)? I would like to stick with a single Java language binding for the time being, so things should not be incompatible between 1.3 and 5 (e.g., it is not viable to use T[] for 1.3 out parameters and OutHolderT for 5 out parameters). One place where using 5 features worked well was in adding polymorphic struct types to UNO, which are mapped to generic classes in Java 5 and their type-erased counterparts in Java 1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Ideas on mapping UNO IDL to Java 5
I am a beginner of OpenOffice and I am learning the SDK document now. Instead, i found the mapping from IDL to java looks missing something: 1. the mapped Java classes contains less information than the IDL, By using the Java 5 annotations will solve this problem, and we can even write no IDL at all, and simply writing the Java classes, and using a tool to generate the IDL if neccessary. 2. the Out/In Out parameter mapping is something strange. I think using a OutHolderT or InOutHolderT will be more clear 3. No Service is mapped, this require the queryInterface called frequently. I think a Service can be mapped to an interface which may extends other interface or aggregate optional interface inside. And more, i think there should be a util to generate the POJO mapping from exists IDL(Its better to include the documents in Java).
