commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: [jexl] 3.1 release review
Date Sun, 12 Mar 2017 17:09:29 GMT
BC can be handled a couple ways here besides renaming:

* Are there already abstract classes that implementations are meant to
extend? If so, that limits the possibility of problems here without using
default methods in Java 8.
* If these are truly public interfaces for users to implement, then you can
extend the interface with an extended version which adds new methods. Try
not to name them Options31 if you can help it.

On 12 March 2017 at 05:16, henrib <henrib@apache.org> wrote:

>
> I've reworded the warning about the source compatibility break in the
> release notes:
>
>
>
> If this source compatibility break is not 'permitted' despite its
> improbability, what option should we take:
> - move to another (jexl31) package ?
> - add 'extended' interfaces (Options31, JexlExpression31, Template31) ?
> - add a utility helper class (Jexl31Helper?) to put the 3 methods as
> functions ( boolean isCancellable(JExlEngine.Options opt) ?
>
>
> Comments welcome,
> Thanks
>
>
>
> --
> View this message in context: http://apache-commons.680414.
> n4.nabble.com/jexl-3-1-release-review-tp4691513p4696416.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message