On 18 May 2000, Stefan Bodewig wrote:
> >>>>> "VS" == Vitaly Stulsky <[EMAIL PROTECTED]> writes:
>
> >> There have been idl2java tasks (two of them IIRC) sent to this
> >> list during the last two weeks but I recall them to be vendor
> >> specific.
>
> VS> It is possible to combine all tasks for different vendors into
> VS> one task.
I disagree on the practicality of this, but more on that later...
> This is what I wanted to hear 8^).
>
> What needs to be thought about is how to handle options that are only
> available in specific implementations.
>
> I see several ways to work with them
>
> 1. Neglect all options not available in the "standard" which would
> probably be the idl2java from Sun's SDK. Those using other vendors
> tools won't like this.
Choosing your 'standard' tool is not going to be easy. Sun's version is,
IMHO, a bad choice, because it is nothing like compliant with the CORBA
standard, particularly not the current standard. About the only product I
know of which is compliant with the current standard is Visibroker 4.
This, however, is almost completely incompatible with Sun's version and
previous versions of Visibroker, since it now implements the CORBA 2.3
spec, complete with POAs and TIEs, and ditching BOAs. You may still use
BOAs, but what I'm trying to get at is that the command-line syntax is
pretty much entirely different between different versions of one product,
let alone different products, so I don't think this is a feasible
approach, since it will reduce the functionality of every other idl2java
to naught.
> 2. Add all options possibly there. A maintenance nightmare.
I agree. Doing this is bad news.
> 4. Have only one option at all - for the command line.
Possible, but not elegant.
> 5. Invent magic properties to trigger some options. This is what the
> current jikes implementation does to get additional warnings or error
> messages in emacs compatible format. I would rather not use properties
> at all.
Again, doable, and similar to an approach I will propose below, but I'm
not really happy with either of them.
> 6. Have individual attributes for all common options and a single
> attribute (additionaloptions or so) to be parsed (or ignored) by the
> specific implementation.
Again, doable, but the common options are so few and far between that this
option just reduces to being identical to option 4.
> As it stands I prefer number 6 but maybe others can come up with a
> better solution. If we could find consensus on this, I'd love to see
> the javac task to use the same mechanism.
This is one of the better ways of doing it, but let me put up a number 7.
Please remember, as you read this, that I'm not happy about it, but that
it is, I think, a way of dealing with a proliferation of products.
There are many CORBA implementations, all of which have tools with
different command-line syntax, none of which (to my knowledge) are
interoperable (despite the idealism of the standard) and most of which use
different Java mappings of the IDL language. I think, for these reasons,
that, although these products all fall into the general enterprise
infrastructure domain, they are not really all the same technology. They
all have similarities, but they are not readlly compliant to a standard,
certainly not compliant to the same version of that standard (and minor
revisions of this standard are incompatible), and therefore are not the
same technology. It seems to me, then, that there is not a good reason to
have a Task derivative which attempts to provide an interface to all of
them. There is nothing to be gained by such an attempt, excepting that it
reduces the overall complexity of the build tool. It does, however, have
the potential to make one class incredibly more complex, if an attempt is
made to deal with the features of every product. For these reasons, I
propose a task for each idl2java implementation someone happens to want to
use (ie. when you want to use it, you write it and hopefully contribute it
back to the project) and it goes in some optional package.
Like I said, I'm not happy with the proliferation of code this generates,
but I think it's a way of dealing with the mass of incompatible tools out
there.
Sorry 'bout the essay...
--
Tom Cook - Software Engineer
"The brain is a wonderful organ. It starts functioning the moment you get
up in the morning, and does not stop until you get into the office."
- Robert Frost
LISAcorp - www.lisa.com.au
--------------------------------------------------
38 Greenhill Rd. Level 3, 228 Pitt Street
Wayville, SA, 5034 Sydney, NSW, 2000
Phone: +61 8 8272 1555 Phone: +61 2 9283 0877
Fax: +61 8 8271 1199 Fax: +61 2 9283 0866
--------------------------------------------------
