There is fierce debate raging around this topic ever since I've been around OSGi.
I would recommend putting your opinions forth on the public OSGi bugzilla tracker https://osgi.org/bugzilla/ Sincerely, - Ray On Thu, Jul 5, 2018 at 11:00 AM, Lars Vogel <[email protected]> wrote: > Thanks, Todor and Tom. > > @Tom, IMHO obsolete API is sufficient to provide newer API. Tools like > Sonar will flag this usage as an issue. > > Would be nice to have API which does not result in Sonar warnings. > > Maybe no need to deprecate the old OSGI API but also add a comment > that it is obsolete once the new API is available? ;-) > > Best regards, Lars > > > > On Fri, Jun 29, 2018 at 3:43 PM, Thomas Watson <[email protected]> > wrote: > > Dictionary my be documented as obsolete, but it is not deprecated. I > would > > not want to deprecate a spec'ed API method that takes non-deprecated > types. > > Anyway, the discussion is happening now in the expert group. > > > > Tom > > > > > > > > > > ----- Original message ----- > > From: Lars Vogel <[email protected]> > > Sent by: [email protected] > > To: Equinox development mailing list <[email protected]> > > Cc: > > Subject: [equinox-dev] Provide new OSGi service API without obsolete API > > (Dictionary)? > > Date: Fri, Jun 29, 2018 2:35 AM > > > > Hi, > > > > I wanted to give official feedback that my customers are surprised > > that OSGi service API is based on obsolete data types. > > > > From the Javadoc of Dictionary: > > ---- > > NOTE: This class is obsolete. > > ---- > > > > This makes the OSGi service API look outdated for several of the > > customers I discussed this. OSGi ds hides this a bit but sometimes the > > low-level API must be used. > > > > So for those involved in the OSGi spec, maybe you can consider > > deprecating the old methods in BundleContext and providing new ones > > with non-obsolete API, e.g., Map? > > > > I'm aware that this is "just a mailing list" but AFAIK several of the > > subscribed people here are involved in the OSGi specification. > > > > Best regards, Lars > > > > -- > > Eclipse Platform project co-lead > > CEO vogella GmbH > > > > Haindaalwisch 17a, 22395 Hamburg > > Amtsgericht Hamburg: HRB 127058 > > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel > > USt-IdNr.: DE284122352 > > Fax (040) 5247 6322, Email: [email protected], Web: > > http://www.vogella.com > > _______________________________________________ > > equinox-dev mailing list > > [email protected] > > To change your delivery options, retrieve your password, or unsubscribe > from > > this list, visit > > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > > > > > > > _______________________________________________ > > equinox-dev mailing list > > [email protected] > > To change your delivery options, retrieve your password, or unsubscribe > from > > this list, visit > > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > -- > Eclipse Platform project co-lead > CEO vogella GmbH > > Haindaalwisch 17a, 22395 Hamburg > Amtsgericht Hamburg: HRB 127058 > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel > USt-IdNr.: DE284122352 > Fax (040) 5247 6322, Email: [email protected], Web: > http://www.vogella.com > _______________________________________________ > equinox-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
