Re: [jira] [Created] (JEXL-123) Redesign API for stability
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
On 5 December 2011 09:34, henrib hen...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
On 5 December 2011 10:50, henrib hen...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
On 5 December 2011 13:34, henrib hen...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
On 4 December 2011 19:08, Henri Biestro (Created) (JIRA) j...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
On 4 December 2011 19:57, henrib hen...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
