On 14 March 2017 at 03:49, Matt Sicker wrote:
> Using interfaces and implementing them are two entirely separate things.
Good point; sorry I had overlooked the distinction.
If there are no external implementions (yet) then I agree it should be
OK to release with the existing caveat in the RN.
I
Using interfaces and implementing them are two entirely separate things.
For instance, people use Logger instances, but we've added new APIs to that
interface in log4j-api while maintaining backwards compatibility (though we
do that by providing abstract base classes for implementations to use).
O
On 14 March 2017 at 01:38, Matt Sicker wrote:
> If they're not user-implemented interfaces, then changing them isn't really
> a backwards incompatible change.
I agree, but since users asked for the changes to the interfaces that
suggests that the interfaces are being used externally.
> On 13 Mar
If they're not user-implemented interfaces, then changing them isn't really
a backwards incompatible change.
On 13 March 2017 at 17:50, sebb wrote:
> On 13 March 2017 at 20:12, henrib wrote:
> >
> > The interface modifications are fixes to user enhancement requests:
> >
> > JEXL-211: Add callab
On 13 March 2017 at 20:12, henrib wrote:
>
> The interface modifications are fixes to user enhancement requests:
>
> JEXL-211: Add callable method to JexlExpression interface
> JEXL-198: JxltEngine Template deos not expose pragmas
> JEXL-201: Allow Interpreter to use live values from JexlEngine.Op
The interface modifications are fixes to user enhancement requests:
JEXL-211: Add callable method to JexlExpression interface
JEXL-198: JxltEngine Template deos not expose pragmas
JEXL-201: Allow Interpreter to use live values from JexlEngine.Option
interface implemented by JexlContext
Note agai
It's more of an issue for downstream users who implement the interface as
they'd now have an illegally declared class not implementing all abstract
methods.
On 13 March 2017 at 07:13, sebb wrote:
> AFAICT two of the interface changes are not needed:
>
> JexlExpression#Callable can be dropped; AF
AFAICT two of the interface changes are not needed:
JexlExpression#Callable can be dropped; AFAICT no other changes are needed.
JxltEngine$Template#getPragmas() can be dropped if the test is
modified to use TemplateScript and TS drops the @Override marker
It's probably not easy to drop JexlEngine
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
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, Templ
Resurrecting the thread...Hopefully Emmanuel has a few spare cycles. :-)
I've commented JEXL-220 with the 3 Clirr errors that correspond to adding
methods to interfaces that only Jexl is supposed to implement.
I've also added a very clear statements as a waning in the release-notes; it
reads as:
{
Could the breaking changes be documented together in one ticket so we can
review that and provide this ticket as a single point of documentation? An
explanation of why it is OK to break BC would be helpful and reassuring.
2c,
Gary
On Mon, Oct 3, 2016 at 3:05 AM, Emmanuel Bourg wrote:
> Hi all,
Hi all,
JEXL is ready for a new release, before creating the artifacts and
starting the vote I'd like to ensure there is a consensus on the API
changes. The version 3.1 has 3 incompatible changes that shouldn't have
any impact on the users [1].
I plan to start the vote at the end of the week.
Th
13 matches
Mail list logo
