You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2011/12/04 20:21:54 UTC
Re: [jira] [Created] (JEXL-123) Redesign API for stability
On 4 December 2011 19:08, Henri Biestro (Created) (JIRA)
<ji...@apache.org> wrote:
> Redesign API for stability
> --------------------------
>
> Key: JEXL-123
> URL: https://issues.apache.org/jira/browse/JEXL-123
> Project: Commons JEXL
> Issue Type: Improvement
> Reporter: Henri Biestro
> Assignee: Henri Biestro
> Priority: Critical
??
>
>
> 2.1 has shown it was very difficult to evolve the features without compromising stability, i.e. respecting the contract made by the API.
> 3.0 main goal is to make the API stable, making clear where the difference is between "using" Jexl and "customizing/improving" Jexl.
OK, fine.
> Since it is targeted at new projects or at least very active ones, the deployment will require at least Java 1.6.
I don't see how it follows that Java 1.6 is required.
Pool and Math have been extensively reworked recently for similar
reasons and neither was changed to require 1.6.
Now if 1.6 is absolutely required to support certain new features,
that is a different matter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by sebb <se...@gmail.com>.
On 5 December 2011 13:34, henrib <he...@apache.org> wrote:
> JSR-269: custom annotation processing hooks are available in Java6; say
> someones wants to develop an IDE plugin that checks whether usage of a
> class/field/method annotated by @internal is made from the same package and
> issue a warning in that case...
In that case, surely the plugin can target Java 1.6?
> JSR-199: convert a script / or part of a script as a "compiled" class;
> instead of going through ASM et al libraries, generate the Java code - Jexl
> templates - and compile it.
Is that going to be part of JEXL itself?
Again, if it is an add-on, that can require 1.6.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by henrib <he...@apache.org>.
JSR-269: custom annotation processing hooks are available in Java6; say
someones wants to develop an IDE plugin that checks whether usage of a
class/field/method annotated by @internal is made from the same package and
issue a warning in that case...
JSR-199: convert a script / or part of a script as a "compiled" class;
instead of going through ASM et al libraries, generate the Java code - Jexl
templates - and compile it.
The real question is whether a project that seeks (5 years old) "novelty"
has a place within Commons; is there a way to move JEXL (at least from v3
up) somewhere else within Apache where the 1984-release-police is not
tempted to rule the world ?
--
View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4160457.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
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by sebb <se...@gmail.com>.
On 5 December 2011 10:50, henrib <he...@apache.org> wrote:
> Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation
> processing),
JUnit4 relies on annotations, but does not require Java 1.6
> JSR-199 (compiler API).
I think we need a bit more info than that.
What are the new features that will require 1.6?
I'm not saying that the move to 1.6 should not be made; but I'm not
yet convinced that it is strictly necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by henrib <he...@apache.org>.
Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation
processing), JSR-199 (compiler API).
--
View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4160017.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
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by sebb <se...@gmail.com>.
On 5 December 2011 09:34, henrib <he...@apache.org> wrote:
> Sebb;
> Lets not return the pb; Java6 is not downwards compatible with Java 1.5.
Of course not; that's the point.
> There is a cost in maintaining 2 JDKs on 3 boxes, a cost in remembering that
> @Override can not be used on interfaces implementation, that addAll is not
> there, a cost in switching environments before using mvn and publishing,
> etc. All these "little" things that accumulated make it a pain in the a....
That is partly why we have CI systems such as Continuum.
> But, again, the main point is just that it is not useful to maintain Java
> 1.5 which is eol; JEXL3 is a new project API intended for active/new
> projects and thus will be used and deployed on Java 6. Besides, there is
> always JEXL 2.1 - soon to be released I hope - which will cover the Java 1.5
> aficionados needs.
>
> Why do you want to impose an unnecessary compatibility ?
Why do you wish to impose a potentially unnecessary compatibily?
> Is there anything
> in the Commons charter that states that obsolete platforms need to be
> deployment targets?
No, but Commons does strive for compatibility as far as possible.
> And IMHO, it is a disservice to the Java community to
> let them run new APIs on Java 1.5 when Java7 is out.
Irrelevant; they can still run any Commons component that targets 1.4
or 1.5 on Java7.
> Finally, do you really need to challenge any change or evolution even when
> not related to stability or quality ?
No, but I think it's necessary to explain why the change in JVM is
necessary for end-users.
The change between 1.4 and 1.5 was much easier to justify, as there
were huge improvements; not least in the memory model.
There are of course improvements in Java 1.6, but they are not of the
same order.
So unless there is a feature in Java 1.6 that is essential for JEXL 3,
then I don't think it's necessary to make Java 1.6 a requirement.
> Will we have to call votes for everything and anything ?
No, but I think it's necessary to justify the change in JVM.
I have yet to see a technical argument why 1.6 is necessary.
> And then we wonder why people seem to be fed up;
> re-read Simo, JamesC, GaryG recent message in the "[JEXL] Jexl 2.1"
> thread...
Also see response from Joerg Schaible.
In Commons particularly, it is important to strive for compatibilty.
> Regards,
> Henrib
>
>
> --
> View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4159821.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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by henrib <he...@apache.org>.
Sebb;
Lets not return the pb; Java6 is not downwards compatible with Java 1.5.
There is a cost in maintaining 2 JDKs on 3 boxes, a cost in remembering that
@Override can not be used on interfaces implementation, that addAll is not
there, a cost in switching environments before using mvn and publishing,
etc. All these "little" things that accumulated make it a pain in the a....
But, again, the main point is just that it is not useful to maintain Java
1.5 which is eol; JEXL3 is a new project API intended for active/new
projects and thus will be used and deployed on Java 6. Besides, there is
always JEXL 2.1 - soon to be released I hope - which will cover the Java 1.5
aficionados needs.
Why do you want to impose an unnecessary compatibility ? Is there anything
in the Commons charter that states that obsolete platforms need to be
deployment targets? And IMHO, it is a disservice to the Java community to
let them run new APIs on Java 1.5 when Java7 is out.
Finally, do you really need to challenge any change or evolution even when
not related to stability or quality ? Will we have to call votes for
everything and anything ? And then we wonder why people seem to be fed up;
re-read Simo, JamesC, GaryG recent message in the "[JEXL] Jexl 2.1"
thread...
Regards,
Henrib
--
View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4159821.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
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by sebb <se...@gmail.com>.
On 4 December 2011 19:57, henrib <he...@apache.org> wrote:
>
> sebb-2-2 wrote
>>
>>
>>> Since it is targeted at new projects or at least very active ones, the
>>> deployment will require at least Java 1.6.
>>
>> Now if 1.6 is absolutely required to support certain new features,
>> that is a different matter.
>>
>>
> I should have said that 'not useful' too.
No idea what that refers to.
> I believe it is not useful to incur the cost of maintaining knowledge about
> 1.5 and 1.6 differences in this case.
Not sure I understand what the cost is here.
> I also think that if you want to use "new" stuff, it is better to avoid
> putting it on top of unsupported ones (1.5 is eol afaik); instead of
> adapting some code to Jexl3, someone would be doing a better job at
> migrating towards Java 6.
But code that runs on Java 5 will run on Java 6; there's no need to
"migrate" to Java 6.
> Henrib
>
> --
> View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4157896.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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Posted by henrib <he...@apache.org>.
sebb-2-2 wrote
>
>
>> Since it is targeted at new projects or at least very active ones, the
>> deployment will require at least Java 1.6.
>
> Now if 1.6 is absolutely required to support certain new features,
> that is a different matter.
>
>
I should have said that 'not useful' too.
I believe it is not useful to incur the cost of maintaining knowledge about
1.5 and 1.6 differences in this case.
I also think that if you want to use "new" stuff, it is better to avoid
putting it on top of unsupported ones (1.5 is eol afaik); instead of
adapting some code to Jexl3, someone would be doing a better job at
migrating towards Java 6.
Henrib
--
View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4157896.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