王在祥 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]
