RE: RE: [classlib][suncompat] created
>-Original Message- >From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] >Sent: Friday, August 11, 2006 2:32 PM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: [classlib][suncompat] created > >Another solution is to create stubs which will throw exceptions with >detailed message. Then users will get neccessary information but >functionality won't be enabled by default. Good point! It's even better :) Regards, Alexey. > >On 8/11/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote: >> I agree with Alex, we should *not* have this by default. Having it >> enabled by default will not give a hint something's wrong with the code. >> I believe no one will ever look in the sources if everything works just >> fine, and therefore no one will see the deprecation. >> At least, the new code won't reference these classes. However we'll >> provide a workaround to keep legacy applications running on Harmony in >> cases where the code can't be updated properly. >> >> When suncompat.jar is removed from the default distribution, people will >> be frustrated as well. >> >> Regards, >> -- >> Alexey A. Ivanov >> Intel Middleware Product Division >> >> >> >-----Original Message----- >> >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >> >Sent: Friday, August 11, 2006 12:06 PM >> >To: harmony-dev@incubator.apache.org >> >Subject: Re: RE: [classlib][suncompat] created >> > >> >I think the @deprecated is a good idea, but I strongly believe that we >> >should *not* have this as a default. There's an easy workaround for >> >the subset of applications that need it (e.g. enable it in the >> >.properties file) whilst still preventing new code from being able to >> >reference it. A simple FAQ should be enough to help people do this. >> > >> >Mind you, I seem to be in the minority on this view on this list :-) >> > >> >Alex. >> > >> >On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: >> >> I agree, let's just enable it by default. I would suggest that we tag >> all >> >of >> >> these classes as @Deprecated with a nice message saying you really >> >shouldn't >> >> be using this. >> >> >> >> -Nathan >> >> >> >> > -Original Message- >> >> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> >> > Sent: Thursday, August 10, 2006 11:13 AM >> >> > To: harmony-dev@incubator.apache.org >> >> > Subject: Re: [classlib][suncompat] created >> >> > >> >> > Oh - definitely only add as needed, and yes, we need to have good >> >> > documentation to assist users. >> >> > >> >> > And I'm very +1 about including this by default for now. See other >> >> > threads as for why. >> >> > >> >> > geir >> >> > >> >> > Alex Blewitt wrote: >> >> > > Sounds like a FAQ in the making :-) >> >> > > >> >> > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> > >> Alex Blewitt wrote: >> >> > >> > OK. What's the plan with regards to adding items in here e.g. >> >Base64 >> >> > >> > or tools like JavaC? Or do we just add them organically as we >> find >> >> > >> > problems? >> >> > >> >> >> > >> Let's try and keep this JAR as small as possible, only adding >> types >> >> > >> after a debate on the list concludes that it is a 'necessity'. >> >> > >> >> >> > >> Regards, >> >> > >> Tim >> >> > >> >> >> > >> -- >> >> > >> >> >> > >> Tim Ellison ([EMAIL PROTECTED]) >> >> > >> IBM Java technology centre, UK. >> >> > >> >> >> > >> >> >> >- >> >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> > >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> > >> For additional commands, e-mail: harmony-dev- >> >[EMAIL PROTECTED] >> >> > >> >> >> > >> >> >> > > >> >> > > >> ---
Re: RE: [classlib][suncompat] created
Another solution is to create stubs which will throw exceptions with detailed message. Then users will get neccessary information but functionality won't be enabled by default. On 8/11/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote: I agree with Alex, we should *not* have this by default. Having it enabled by default will not give a hint something's wrong with the code. I believe no one will ever look in the sources if everything works just fine, and therefore no one will see the deprecation. At least, the new code won't reference these classes. However we'll provide a workaround to keep legacy applications running on Harmony in cases where the code can't be updated properly. When suncompat.jar is removed from the default distribution, people will be frustrated as well. Regards, -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >Sent: Friday, August 11, 2006 12:06 PM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: [classlib][suncompat] created > >I think the @deprecated is a good idea, but I strongly believe that we >should *not* have this as a default. There's an easy workaround for >the subset of applications that need it (e.g. enable it in the >.properties file) whilst still preventing new code from being able to >reference it. A simple FAQ should be enough to help people do this. > >Mind you, I seem to be in the minority on this view on this list :-) > >Alex. > >On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: >> I agree, let's just enable it by default. I would suggest that we tag all >of >> these classes as @Deprecated with a nice message saying you really >shouldn't >> be using this. >> >> -Nathan >> >> > -Original Message- >> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> > Sent: Thursday, August 10, 2006 11:13 AM >> > To: harmony-dev@incubator.apache.org >> > Subject: Re: [classlib][suncompat] created >> > >> > Oh - definitely only add as needed, and yes, we need to have good >> > documentation to assist users. >> > >> > And I'm very +1 about including this by default for now. See other >> > threads as for why. >> > >> > geir >> > >> > Alex Blewitt wrote: >> > > Sounds like a FAQ in the making :-) >> > > >> > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > >> Alex Blewitt wrote: >> > >> > OK. What's the plan with regards to adding items in here e.g. >Base64 >> > >> > or tools like JavaC? Or do we just add them organically as we find >> > >> > problems? >> > >> >> > >> Let's try and keep this JAR as small as possible, only adding types >> > >> after a debate on the list concludes that it is a 'necessity'. >> > >> >> > >> Regards, >> > >> Tim >> > >> >> > >> -- >> > >> >> > >> Tim Ellison ([EMAIL PROTECTED]) >> > >> IBM Java technology centre, UK. >> > >> >> > >> >- >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> > >> For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > >> >> > >> >> > > >> > > - >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > > >> > > >> > > >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: [classlib][suncompat] created
I agree with Alex, we should *not* have this by default. Having it enabled by default will not give a hint something's wrong with the code. I believe no one will ever look in the sources if everything works just fine, and therefore no one will see the deprecation. At least, the new code won't reference these classes. However we'll provide a workaround to keep legacy applications running on Harmony in cases where the code can't be updated properly. When suncompat.jar is removed from the default distribution, people will be frustrated as well. Regards, -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >Sent: Friday, August 11, 2006 12:06 PM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: [classlib][suncompat] created > >I think the @deprecated is a good idea, but I strongly believe that we >should *not* have this as a default. There's an easy workaround for >the subset of applications that need it (e.g. enable it in the >.properties file) whilst still preventing new code from being able to >reference it. A simple FAQ should be enough to help people do this. > >Mind you, I seem to be in the minority on this view on this list :-) > >Alex. > >On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: >> I agree, let's just enable it by default. I would suggest that we tag all >of >> these classes as @Deprecated with a nice message saying you really >shouldn't >> be using this. >> >> -Nathan >> >> > -Original Message- >> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> > Sent: Thursday, August 10, 2006 11:13 AM >> > To: harmony-dev@incubator.apache.org >> > Subject: Re: [classlib][suncompat] created >> > >> > Oh - definitely only add as needed, and yes, we need to have good >> > documentation to assist users. >> > >> > And I'm very +1 about including this by default for now. See other >> > threads as for why. >> > >> > geir >> > >> > Alex Blewitt wrote: >> > > Sounds like a FAQ in the making :-) >> > > >> > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > >> Alex Blewitt wrote: >> > >> > OK. What's the plan with regards to adding items in here e.g. >Base64 >> > >> > or tools like JavaC? Or do we just add them organically as we find >> > >> > problems? >> > >> >> > >> Let's try and keep this JAR as small as possible, only adding types >> > >> after a debate on the list concludes that it is a 'necessity'. >> > >> >> > >> Regards, >> > >> Tim >> > >> >> > >> -- >> > >> >> > >> Tim Ellison ([EMAIL PROTECTED]) >> > >> IBM Java technology centre, UK. >> > >> >> > >> >- >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> > >> For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > >> >> > >> >> > > >> > > - >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > > >> > > >> > > >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: [classlib][suncompat] created
I think the @deprecated is a good idea, but I strongly believe that we should *not* have this as a default. There's an easy workaround for the subset of applications that need it (e.g. enable it in the .properties file) whilst still preventing new code from being able to reference it. A simple FAQ should be enough to help people do this. Mind you, I seem to be in the minority on this view on this list :-) Alex. On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 10, 2006 11:13 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [classlib][suncompat] created > > Oh - definitely only add as needed, and yes, we need to have good > documentation to assist users. > > And I'm very +1 about including this by default for now. See other > threads as for why. > > geir > > Alex Blewitt wrote: > > Sounds like a FAQ in the making :-) > > > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> Alex Blewitt wrote: > >> > OK. What's the plan with regards to adding items in here e.g. Base64 > >> > or tools like JavaC? Or do we just add them organically as we find > >> > problems? > >> > >> Let's try and keep this JAR as small as possible, only adding types > >> after a debate on the list concludes that it is a 'necessity'. > >> > >> Regards, > >> Tim > >> > >> -- > >> > >> Tim Ellison ([EMAIL PROTECTED]) > >> IBM Java technology centre, UK. > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib][suncompat] created
Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Alex Blewitt wrote: > OK. What's the plan with regards to adding items in here e.g. Base64 > or tools like JavaC? Or do we just add them organically as we find > problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
