Re: [lang] Remove final modifier behaviour in java 12+ (was: Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1)

2019-04-11 Thread Rob Tompkins
That’s what I switched to. -Rob > On Apr 11, 2019, at 2:44 PM, Benedikt Ritter wrote: > > An alternative would be to use SystemUtils.isJavaVersionAtMost the have > behavior depending on the current Java versions. This would preserve the > behavior for users on Java < 12. > > Benedikt > > Am

Re: [lang] Remove final modifier behaviour in java 12+ (was: Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1)

2019-04-11 Thread Benedikt Ritter
An alternative would be to use SystemUtils.isJavaVersionAtMost the have behavior depending on the current Java versions. This would preserve the behavior for users on Java < 12. Benedikt Am Mi., 10. Apr. 2019 um 16:32 Uhr schrieb Rob Tompkins : > I like that. I’ll get that sorted out. > > -Rob

Re: [lang] Remove final modifier behaviour in java 12+ (was: Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1)

2019-04-10 Thread Rob Tompkins
I like that. I’ll get that sorted out. -Rob > On Apr 10, 2019, at 10:28 AM, Gary Gregory wrote: > > I think UnsupportedOperationException with a Java 12 comment, but we should > also add @Deprecated with a comment about it not working at all on Java 12. > > Gary > > On Wed, Apr 10, 2019 at

Re: [lang] Remove final modifier behaviour in java 12+ (was: Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1)

2019-04-10 Thread Gary Gregory
I think UnsupportedOperationException with a Java 12 comment, but we should also add @Deprecated with a comment about it not working at all on Java 12. Gary On Wed, Apr 10, 2019 at 8:55 AM Rob Tompkins wrote: > Looks like we get an exception because the final modifier isn’t removable > in java

[lang] Remove final modifier behaviour in java 12+ (was: Re: [VOTE] Release Apache Commons Lang 3.9 based on RC1)

2019-04-10 Thread Rob Tompkins
Looks like we get an exception because the final modifier isn’t removable in java 12+ and for good reason [1]. So, we probably should throw an exception, but both of the exceptions that arise out of the jvm here