Updating the Java language bindings
Rob Ratcliff
I've recently been using JacORB in conjunction with Hibernate to persist
CORBA events to a relational database. The CORBA events are defined as
IDL structs. (not ValueTypes for now.) I've noticed that the generated
Java code for the structs can be a little awkward to use in practice and
does not follow the current best practices for Java.
Here are a few observations:
1.) All fields are public rather than private with Getters/Setters. I
think it'd be preferable if the structs were mapped to the typical
JavaBean convention, including being Serializable. The current public
field mappings forces me to use Hibernate's field level access mode,
which can be more limiting than method level access. Not being
Serializable make it more difficult to create User-defined Hibernate
types since the assemble and disasemble method require Serializable types.
2.) The generated code for the IDL enum are not Java enums, don't have
some of the very useful methods like valueOf(String name) and EnumType[]
values() and don't implement a common interface leading to code like
this for a Hibernate type to support all CORBA enum types:
Class myCorbaEnumClass = Class.forName("MyCorbaEnumClass");
Method fromIntMethod = corbaEnumClass.getMethod("from_int",
new Class[]{int.class});
protected Object convertToObject(String name) {
Object result = null;
for (int i = 0;; i++) {
try {
Object o = fromIntMethod.invoke(myCorbaEnumClass, i);
if (o.toString().equals(name)) {
result = o;
}
} catch (org.omg.CORBA.BAD_PARAM ex) {
break;
} catch (IllegalAccessException ex) {
break;
} catch (InvocationTargetException ex) {
break;
}
}
return result;
}
3.) I had to use XML descriptions of the mappings rather than the new
annotations approach since there isn't a way to include annotations in
the IDL that will transfer to the generated code without writing
additional Wrapper objects. I think it'd be very useful to be able to
include more meta data in the IDL similar to Java annotations that
affect how the final generated code looks. This concept could also be
used to change the mapping of IDL sequences to parameterized types like
List<String> rather than String[] or add additional error checking code,
etc. (I wrote some about this here: http://tinyurl.com/2kg3uv )
Reading articles like this, http://www.orbzone.org/?p=100, gives me no
hope that the major players are going to motivate any significant
language mapping changes in the next decade even though Java and C++
continue to mature with new features and preferred practices change
accordingly (I hope that I'm wrong).
I had the idea that perhaps change could be driven from the
open source community where optional language bindings can be selected
(similar to the current enhanced binding switch that creates the very
convenient toString() methods). The popularity of the new bindings
might organically drive change from the bottom up rather than waiting
for the OMG to create an addendum to the binding specification. (Any
comments from OMG members are appreciated! Is there any significant
movement to update the C++ and Java binding specs in the near term?)
Unlike many of its detractors, I think CORBA is still one of the best of
breed solutions for efficient messaging, especially if the language
bindings were kept current. (There are other standards features I'd like
to see as well like making bidirectional IIOP the norm to deal with
firewall issues and having the option of handling versioning through
dynamic parsing based on reflective interfaces or some other approach
to make CORBA more competitive, but I think improved language bindings
would be a good first step.)
Does anybody have any comments? Would the authors of JaCORB and other
Java ORBs be open to having more language binding options (command line
options for the IDL compiler) available even though they aren't
currently part of the current CORBA standard? I don't really see a down
side, especially for projects where all new code is being generated.
(BTW, there are NEW CORBA projects!)
Thanks,
Rob
p.s. I know some of this can be done with Value Types, but that solution
still requires additional code to be hand written or created via custom
code generators.
ap...@student.open.ac.uk
> Here are a few observations:
> field mappings forces me to use Hibernate's field level access mode,
> which can be more limiting than method level access. Not being
> Serializable make it more difficult to create User-defined Hibernate
> types since the assemble and disasemble method require Serializable types.
>
> 2.) The generated code for the IDL enum are not Java enums
> annotations approach
Hmm. I agree that CORBA language bindings are a problem. I think
things are much better for java though. Years ago I used CORBA with C+
+ where the bindings are truly horrific. They make the points above
seem relatively minor to me. $0.02.
> Reading articles like this, http://www.orbzone.org/?p=100, gives me no
> hope that the major players are going to motivate any significant
> language mapping changes in the next decade even though Java and C++
> continue to mature with new features and preferred practices change
> accordingly (I hope that I'm wrong).
I think you are spot on. I think the OMG is the worst example of
"committee"-itus the world has ever seen :-(
> I had the idea that perhaps change could be driven from the
> open source community where optional language bindings can be selected
What, you mean after there has been some open source work it can be
presented to the OMG in the hope they will change? Fat chance. A while
ago someone developed CORBA mappings for Eiffel which I thouight was
great. That was open source too. It was called MICO/E. See
http://www.math.uni-goettingen.de/micoe for details. IIRC the OMG were
not interested. A commercial company, 2AB picked up the baton instead
(see http://archive.eiffel.com/doc/eiffelworld/backissues/03_2002.html#corner).
> Unlike many of its detractors, I think CORBA is still one of the best of
> breed solutions for efficient messaging
So do I.
> especially if the language
> bindings were kept current.
Here is were our views diverge. I think we have to live with the
bindings as they are, for the limited number of languages that are
supported.
> Does anybody have any comments?
Yes, if you are after more modern language binding, take a look at ICE
(http://www.zeroc.com). This was written by ex-CORBA and ex-OMG people
who got fustrated with the committee-itus of the OMG and wrote a new
product using ideas from CORBA but for more languages and with better
bindings.
> Thanks,
>
> Rob
Regards,
Andrew Marlow
Douglas C. Schmidt
FYI, there's an effort afoot in the OMG to improve the C++ language
bindings for CORBA. I was at the OMG meeting in Brussels last month
where Bob Kukura from PrismTech led a workshop on this topic. There's
a groundswell of support from most of the ORB vendors to fix the
problems with the C++ mapping, so hopefully things will improve.
Take care,
Doug
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203 NET: d.sc...@vanderbilt.edu
Rob Ratcliff
Have you heard about any similar movement for Java?
Thanks,
Rob
Douglas C. Schmidt
>Thanks Doug for the reply.
You are quite welcome. BTW, please see
http://www.dre.vanderbilt.edu/~schmidt/C++-mapping.ppt
for a presenation I gave at the OMG meeting in San Diego about the C++
mapping. This presentation helped to kickoff the current task force
that's working on a new C++ mapping.
>Have you heard about any similar movement for Java?
I'm not aware of anything, but I'm a C++ guy, not a Java guy ;-)
Thanks,
Doug
>Thanks,
>
>Rob
>
>
>Douglas C. Schmidt wrote:
>> Hi Folks,
>>
>> FYI, there's an effort afoot in the OMG to improve the C++ language
>> bindings for CORBA. I was at the OMG meeting in Brussels last month
>> where Bob Kukura from PrismTech led a workshop on this topic. There's
>> a groundswell of support from most of the ORB vendors to fix the
>> problems with the C++ mapping, so hopefully things will improve.
>>
>> Take care,
>>
>>
Rob Ratcliff
> Rob Ratcliff wrote:
>> Here are a few observations:
>> The current public
>> field mappings forces me to use Hibernate's field level access mode,
>> which can be more limiting than method level access. Not being
>> Serializable make it more difficult to create User-defined Hibernate
>> types since the assemble and disasemble method require Serializable types.
>>
>> 2.) The generated code for the IDL enum are not Java enums
>> 3.) I had to use XML descriptions of the mappings rather than the new
>> annotations approach
>
> Hmm. I agree that CORBA language bindings are a problem. I think
> things are much better for java though. Years ago I used CORBA with C+
> + where the bindings are truly horrific. They make the points above
> seem relatively minor to me. $0.02.
They may be better, but they can be improved. If we're not growing and
improving, we're dying. Updating the mappings should be a natural
process that occurs periodically just to keep the spec from going stale
as the languages and best practices become more refined.
>
>> especially if the language
>> bindings were kept current.
>
> Here is were our views diverge. I think we have to live with the
> bindings as they are, for the limited number of languages that are
> supported.
Why? There are standard mechanisms used by the industry (such as Sun
with updates to the JDK library and the Java language) to incrementally
migrate to new and improved versions. What's the big deal!
>> Does anybody have any comments?
>
> Yes, if you are after more modern language binding, take a look at ICE
> (http://www.zeroc.com). This was written by ex-CORBA and ex-OMG people
> who got fustrated with the committee-itus of the OMG and wrote a new
> product using ideas from CORBA but for more languages and with better
> bindings.
Yes, I'm am aware of ICE and refer to it often. It is a very nice
product and a fine example of superb engineering, but unfortunately it
does not interoperate with other ORBs out there since it doesn't use
IIOP or CDR. But, like Doug mentioned in his presentation, valuable
lessons can be learned from ZeroC's fine work! Personally, I think
CORBA's few nose warts can be frozen off rather than resorting to
decapitation.
Douglas C. Schmidt
>> Hmm. I agree that CORBA language bindings are a problem. I think
>> things are much better for java though. Years ago I used CORBA with C+
>> + where the bindings are truly horrific. They make the points above
>> seem relatively minor to me. $0.02.
>
>They may be better, but they can be improved. If we're not growing and
>improving, we're dying. Updating the mappings should be a natural
>process that occurs periodically just to keep the spec from going stale
>as the languages and best practices become more refined.
I totally agree - that's the meaning of the images of dinosaurs in my
presentation at
http://www.dre.vanderbilt.edu/~schmidt/C++-mapping.ppt
>> Here is were our views diverge. I think we have to live with the
>> bindings as they are, for the limited number of languages that are
>> supported.
>
>Why? There are standard mechanisms used by the industry (such as Sun
>with updates to the JDK library and the Java language) to incrementally
>migrate to new and improved versions. What's the big deal!
Exactly, this really shouldn't be a big deal. Hopefully, it will get
resolved this year and we'll be able to implement the new/improved
mapping in TAO (for starters).
>Yes, I'm am aware of ICE and refer to it often. It is a very nice
>product and a fine example of superb engineering, but unfortunately it
>does not interoperate with other ORBs out there since it doesn't use
>IIOP or CDR. But, like Doug mentioned in his presentation, valuable
>lessons can be learned from ZeroC's fine work! Personally, I think
>CORBA's few nose warts can be frozen off rather than resorting to
>decapitation.
I couldn't agree more. Fixing the C++ mapping will go a long way to
making CORBA more useful for today's distributed systems.
Take care,
Doug
Johnny Willemsen
At the Brussels meeting there was also a presentation about the Java mapping
(see http://www.omg.org/docs/mars/07-06-12.pdf). There was also a
presentation about the Ada mapping, we as Remedy IT presented our Ruby
mapping. So, there is a lot of movement within the OMG to address the
various language mappings.
Regards,
Johnny Willemsen
www.theaceorb.nl
"Rob Ratcliff" <rrr...@futuretek.com> wrote in message
news:46BA1583...@futuretek.com...
ap...@student.open.ac.uk
> Hi,
>
> At the Brussels meeting there was also a presentation about the Java mapping
> (see http://www.omg.org/docs/mars/07-06-12.pdf). There was also a
> presentation about the Ada mapping, we as Remedy IT presented our Ruby
> mapping. So, there is a lot of movement within the OMG to address the
> various language mappings.
I don't support Bob or Carol Burt were there from 2AB? (I know they
are OMG members). They have a mapping for Eiffel when they picked up
the contribution from MICO/e. Hopefully the OMG will consider this
binding again.
-Andrew Marlow
Johnny Willemsen
> I don't support Bob or Carol Burt were there from 2AB? (I know they
> are OMG members). They have a mapping for Eiffel when they picked up
> the contribution from MICO/e. Hopefully the OMG will consider this
> binding again.
It is then 2AB that must propose this to the OMG. We as Remedy IT have
presented our Ruby mapping and we are waiting for more feedback from users
and then we as vendor will have to do work to get this standardized.
Johnny
Rob Ratcliff
Thanks for the update. I am VERY GLAD to see that there is movement to
update the bindings. I was starting to think that the OMG had given up
on improving CORBA, but I'm happy to see they haven't. (I really need to
join up at some point.)
Has anybody proposed adding more standardized metadata to IDL (similar
to Java annotations for instance) to allow richer code generation and
cleaner 2-way mappings to WSDL?
Rob
Mark Woyna
> Hi,
>
> I've recently been using JacORB in conjunction with Hibernate to persist
> CORBA events to a relational database. The CORBA events are defined as
> IDL structs. (not ValueTypes for now.) I've noticed that the generated
> Java code for the structs can be a little awkward to use in practice and
> does not follow the current best practices for Java.
>
> Here are a few observations:
>
> 1.) All fields are public rather than private with Getters/Setters. I
> think it'd be preferable if the structs were mapped to the typical
> JavaBean convention, including being Serializable. The current public
> field mappings forces me to use Hibernate's field level access mode,
> which can be more limiting than method level access. Not being
> Serializable make it more difficult to create User-defined Hibernate
> types since the assemble and disasemble method require Serializable types.
I've been saying for years that Structs are *not* objects. They are
messages. As you note, they violate just about every rule of good OO
design. Once the server receives the struct, the data should be moved
from the struct to a proper object, and then discarded.
While this will result in a bit more code, i.e. additional domain
classes, the flexibility is worth it. In your case, your domain
objects can be designed to play nice with Hibernate.
>
> 2.) The generated code for the IDL enum are not Java enums, don't have
> some of the very useful methods like valueOf(String name) and EnumType[]
> values() and don't implement a common interface leading to code like
> this for a Hibernate type to support all CORBA enum types:
>
> Class myCorbaEnumClass = Class.forName("MyCorbaEnumClass");
> Method fromIntMethod = corbaEnumClass.getMethod("from_int",
> new Class[]{int.class});
>
> protected Object convertToObject(String name) {
> Object result = null;
> for (int i = 0;; i++) {
> try {
> Object o = fromIntMethod.invoke(myCorbaEnumClass, i);
> if (o.toString().equals(name)) {
> result = o;
> }
> } catch (org.omg.CORBA.BAD_PARAM ex) {
> break;
> } catch (IllegalAccessException ex) {
> break;
> } catch (InvocationTargetException ex) {
> break;
> }
> }
> return result;
> }
We've never used IDL enums due to their brittleness. One can not
introduce a new value into the enum without breaking existing users of
the enum. In a large enterprise application, this is big no-no, given
that we can't flashcut to a new version of the software.
Instead, we use a typedef to define the type (pseudo-enum), often a
short or long, and a corresponding interface defining the legal
constant (enum) values. Since the typedef in Java maps back to the
base type, we can add new constants over time without breaking the
users, provided that the users code for unexpected (i.e. new) values.
While you don't get the same safety as an enum, it's much more usable
in a production setting.
That said, as in #1 above, I recommend not using the IDL enum in your
domain model. The domain model can use Java enums, and you can map
from the IDL enum to the domain when you're creating the domain object
from the struct. Again, if you treat the struct as a message, you're
simply constructing an appropriate language-specific domain object in
your server.
>
> 3.) I had to use XML descriptions of the mappings rather than the new
> annotations approach since there isn't a way to include annotations in
> the IDL that will transfer to the generated code without writing
> additional Wrapper objects. I think it'd be very useful to be able to
> include more meta data in the IDL similar to Java annotations that
> affect how the final generated code looks. This concept could also be
> used to change the mapping of IDL sequences to parameterized types like
> List<String> rather than String[] or add additional error checking code,
> etc. (I wrote some about this here:http://tinyurl.com/2kg3uv)
IMHO, you're tying your design much too closely to the IDL
representation. If you define a separate domain model, you can use all
the features of the programming language without being held hostage by
the primitive language mapping.
>
> Reading articles like this, http://www.orbzone.org/?p=100, gives me no
> hope that the major players are going to motivate any significant
> language mapping changes in the next decade even though Java and C++
> continue to mature with new features and preferred practices change
> accordingly (I hope that I'm wrong).
>
> I had the idea that perhaps change could be driven from the
> open source community where optional language bindings can be selected
> (similar to the current enhanced binding switch that creates the very
> convenient toString() methods). The popularity of the new bindings
> might organically drive change from the bottom up rather than waiting
> for the OMG to create an addendum to the binding specification. (Any
> comments from OMG members are appreciated! Is there any significant
> movement to update the C++ and Java binding specs in the near term?)
>
> Unlike many of its detractors, I think CORBA is still one of the best of
> breed solutions for efficient messaging, especially if the language
Yup, that's the key. CORBA is *messaging*. You're not passing "real"
objects. You are passing messages to server-side objects. The server
is free to convert the messages into any form, i.e. real object, that
is useful to the server.
> bindings were kept current. (There are other standards features I'd like
> to see as well like making bidirectional IIOP the norm to deal with
> firewall issues and having the option of handling versioning through
> dynamic parsing based on reflective interfaces or some other approach
> to make CORBA more competitive, but I think improved language bindings
> would be a good first step.)
>
> Does anybody have any comments? Would the authors of JaCORB and other
> Java ORBs be open to having more language binding options (command line
> options for the IDL compiler) available even though they aren't
> currently part of the current CORBA standard? I don't really see a down
> side, especially for projects where all new code is being generated.
> (BTW, there are NEW CORBA projects!)
Yes, there are. I'm working for one of the world's largest financial
exchanges, and the entire trading platform, supporting options,
futures, and stocks, is based on a CORBA infrastructure layer. We
process billions of quotes/orders a week. Performance and
interoperability across platforms is a must. There's still no viable
alternative.
Rob Ratcliff
Thanks for your reply!
>>
>> 1.) All fields are public rather than private with Getters/Setters. I
>> think it'd be preferable if the structs were mapped to the typical
>> JavaBean convention, including being Serializable. The current public
>> field mappings forces me to use Hibernate's field level access mode,
>> which can be more limiting than method level access. Not being
>> Serializable make it more difficult to create User-defined Hibernate
>> types since the assemble and disasemble method require Serializable types.
>
> I've been saying for years that Structs are *not* objects. They are
> messages. As you note, they violate just about every rule of good OO
> design. Once the server receives the struct, the data should be moved
> from the struct to a proper object, and then discarded.
>
> While this will result in a bit more code, i.e. additional domain
> classes, the flexibility is worth it. In your case, your domain
> objects can be designed to play nice with Hibernate.
I did consider wrapping the simple struct with richer wrapper objects,
but I'm striving for a single-source/DRY specification of the
data/domain objects. Comparing other approaches, the past EJB
persistence architectures relied on data transfer objects that required
the entity bean data to be copied to the DTO, which was usually hand
generated. The current best practice is to define the persistable data
object (domain model) as a simple POJO (plain old Java object, i.e.
JavaBean), add the persistence mapping as XML or annotations to the
actual object and the just use plain old serialization to transfer the
object over the wire, as well as, serving as the entity bean. This
approach only requires one specification of the object and doesn't
require all the hand-generated code and other claptrap needed by the
former approach. (I'm on a fairly fast moving project that requires lots
of iterative IDL changes and I've used the standard code generators to
do most of the work for me to expedite development.)
I think that IDL with a couple of enhancements could be use to
auto-generate the desired classes without having to resort to custom
code generators or generating wrapper classes by hand. (i.e. I'd like to
have the flexibility of XML/WSDL without the bloat.)
I think there are some good lessons to be gleaned from the evolution of
the EJB persistence spec in terms of simplifying development.
>
> We've never used IDL enums due to their brittleness. One can not
> introduce a new value into the enum without breaking existing users of
> the enum. In a large enterprise application, this is big no-no, given
> that we can't flashcut to a new version of the software.
>
That's why I'm using the string value of the enum rather than the
ordinal constant as much as possible. If the order changes of the enum,
the string value will still be the same. Storing the string value in the
database eliminates the need for a lookup table to decipher the magic
numbers and reduces the brittleness of the design. (Of course, switch
statements may break if new versions of the enum are transferred to
unrecompiled/unsuspecting recipients, but I have the luxury of being
able to recompile all of my code if the IDL changes. Being able to
specify the ordinal value in the IDL spec would help this.)
I've kept the string values of the Java enum and CORBA enum the same in
order to facilitate conversion as well.
Thanks,
Rob
Rob Ratcliff
recently called hyperjaxb2 and hyperjaxb3 that does what I was talking
about for IDL with XML schema.
(Please see https://hyperjaxb2.dev.java.net/ and
https://hyperjaxb3.dev.java.net/ ) In this project, Lexi supports
annotations in the user's schema that are used to add decorations (like
Hibernate or JPA persistence annotations) to the JAXB generated Javabeans.
It seems like a similar approach could be used for IDL as well, where
annotations are added that the IDL compiler would use to generate
enhanced Java objects. A single source definition approach to generating
enhanced value objects all the way through to persistence. I guess the
annotations could be added in the comments of the IDL so that only
annotation-enabled parsers would grok the annotations, but it'd be nice
if the associated meta data was available in the interface repository in
a first class, type safe way.
Anybody have any other opinions on an approach like this?
Rob