OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Fw: [sca-j] package names



Roberto,
The question for Mary was whether or not there is a constraint from the OASIS perspective on what package names could be used.  I also gave some reasons for why retaining the existing names might be desirable, and examples of some similar (not necessarily identical) previous cases.  There was no intention to imply that the TC has decided yet that it wishes to retain the existing org.osoa names.

Since the justification for using the existing package names is to preserve compatibility, this justification would not apply if incompatible changes were made.  So far this has not happened.  If it were to happen, the TC would need to decide what should happen to the package names.  I agree that if incompatible changes are made, there would be a strong argument for changing the package names.

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Roberto Chinnici <Roberto.Chinnici@Sun.COM>
Sent by: Roberto.Chinnici@Sun.COM

04/03/2008 01:16

To
Simon Nash/UK/IBM@IBMGB
cc
Mary McRae <mary.mcrae@oasis-open.org>, Michael Rowley <mrowley@bea.com>, sca-j@lists.oasis-open.org
Subject
Re: Fw: [sca-j] package names





Simon Nash wrote:
> Mary,
> I am following up on this discussion on behalf of the OpenCSA sca-j
> co-chairs.  There is now a formal issue open for this (JAVA-28), with a
> proposed resolution to leave the Java package names as they are specified
> in the SCA 1.0 input documents submitted to OASIS (i.e., as "org.osoa.sca"
> and "org.osoa.sca.annotations").
>
> [...]
>
> The rationale for leaving the names unchanged is that products are already
> available that implement the current package names, and a growing body of
> applications is being created that uses the current package names.
> Changing the package names would require all implementing products and all
> using applications to make an incompatible change, which would be very
> disruptive.
>  

Doesn't this argument assume that the API standardized at OASIS will be
binary-compatible
(even better, source-compatible) with the OSOA one?

If binary compatibility is not preserved, I'd argue that renaming the
packages would be preferable,
since it would remove any ambiguity on which version of the SCA API an
application requires.

Of course, mandating binary compatibility would severely restrict the
kind of decisions that
the TC can make.

> The JCP has many precedents for how to deal with this situation.  It is
> appropriate to look to the JCP for guidance, as this body has a lot of
> experience in dealing with Java package name issues.  Over the years, the
> JCP has brought many APIs into the JDK that were previously in extension
> packages.  The normal naming convention for APIs in the JDK is to start
> package names with "java." and for APIs in extension packages the
> convention is to start them with "javax."  However, when APIs are brought
> into the JDK from extensions, the existing "javax." names are not changed
> to "java." names but are retained unchanged.  This is because the
> disruptive impact of package renaming on developers would outweigh the
> value of strict naming consistency within the JDK.
>  

Indeed. But those packages are the output of the Java standardization
process (JCP) and
are included in the JDK in unmodified form.
> In addition to package names starting with "java." and "javax.", the JDK
> contains many APIs with other package names such as "org.ietf.",
> "org.omg.", "org.xml.", and "org.w3c.".  These names were previously
> created by other "de jure" or "de facto" standards organizations, and were
> left unchanged when the APIs were brought into the JDK.
>  

APIs defined externally to the JCP are also incorporated in an unchanged
form and
are effectively required to evolve compatibly.

In my opinion, these conditions are appropriate for an API in final
form, but not for one subject
to change as part of a normal standardization process.

--Roberto


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]