Well, deprecated doesn't mean gone. So, if it was undeprecated in 1.5 then I wouldn't consider it deprecated in earlier versions any more. I would just consider it a goofy warning to deal with. At least that is the way I would look at that. Then, I also don't look at deprecated to mean don't "ever" use. As in this case, it didn't make sense for it to go away as it is something which is needed, and was probably undeprecated for the same reason other desktop integration as added such as OS taskbar icons and menus in 1.6, and other times this has occurred in different APIs yet the API lags on because there is no good alternative. Just as in the NetBeans APIs there are some APIs which have been deprecated yet no new APIs are under way yet, so they won't be going away any time soon, so until they are replaced the deprecated ones have to be used.
Wade --- Oliver Heger <[EMAIL PROTECTED]> wrote: > Wade Chandler wrote: > > Sure, but not from a configuration perspective. > For > > instance, if daemon used configuration for a > > configuration file it could be easier to use. > Provide > > multiple configuration files with your > distribution > > which allows users to more easily install and > > uninstall services and operate on them without > > remembering command line switches etc. launcher > could > > even use configuration (which is smaller than ANT) > yet > > also allow ANT and not have as many runtime > > requirements. Then of course other applications > can > > just use a single configuration entry point and > use > > configuration information and reference > environment > > variables without having to hard code them into > their > > sources...makes it configurable. > > > > > > Wade > > > > --- Mark Fortner <[EMAIL PROTECTED]> wrote: > > > >> Isn't this already handled by System.getenv? > > System.getenv() has long been deprecated and is now > available again > since 1.5. [configuration] still has 1.3 as minimum > required JDK; I > don't know when we switch to 1.5 (there will > probably be another version > that requires 1.4). > > My problem with this issue is that it will probably > take a high effort > to implement it correctly for earlier JDKs, while we > get it for free in > 1.5. This seem counter-productive. > > Oliver > > >> > >> On 7/23/07, Wade Chandler > >> <[EMAIL PROTECTED]> wrote: > >>> Personally, I think this type thing comes in > very > >>> handy in different situations. It would even be > >> handy > >>> in daemon and launcher. Look how many times > >> scripts > >>> have to be written for every OS to get different > >>> things like JAVA_HOME and ANT_HOME or similar > into > >> an > >>> application. It has been deprecated for a long > >> time, > >>> but I doubt it will ever be removed. It seems to > >> be > >>> quite needed in situations. > >>> > >>> Wade > >>> > >>> --- Oliver Heger <[EMAIL PROTECTED]> > >> wrote: > >>>> Hi all, > >>>> > >>>> for [configuration] we have a feature request > >> for > >>>> supporting environment > >>>> variables [1]. I searched the archives and > found > >>>> that this topic has > >>>> been discussed before [2]. > >>>> > >>>> I was wondering whether situation has changed > >> since > >>>> then. My personal > >>>> opinion is expressed in the Jira ticket in [1]. > >> What > >>>> do others think? > >>>> > >>>> Please note that the ticket contains an > >> attachment > >>>> with a simple > >>>> implementation for accessing environment > >> variables. > >>>> Thanks > >>>> Oliver > >>>> > >>>> [1] > >>>> > > > http://issues.apache.org/jira/browse/CONFIGURATION-284 > >>>> [2] > >>>> > > > http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325 > >>>> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
