TCCL is not only an accident in most cases. It's a side effect of the Java EE specifications which mandate it's use and further exacerbated by the factory pattern all over the Java EE specifications and implementations.
This caused a cascade into libraries which obviously wanted to work in Java EE. - Ray On Mon, Feb 23, 2015 at 4:35 PM, Christian Schneider < ch...@die-schneider.net> wrote: > Fully agree. If you have control over the API then offer a way for the > user to supply the classloader he wants the classes to be loaded from. > In most cases you might even be able to completely avoid class loading. > > I think the only valid usage of TCCL are implementations of APIs that > unfortunately forgot to offer a way to supply a classloader. > > Christian > > Am 23.02.2015 um 21:07 schrieb chris.g...@kiffer.be: > >> IMO TCCL is BAD, end of story. Just do what you have to do, when you have >> to. >> >> >> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-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)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
