Another alternative would be to freeze one Drools version as "last one for
Java 5", and proceed undauntedly to new shores. But there is also the issue
of suppor - don't know whether you buy a guarantee of unlimited progress
towards new features while standing still at some Java version.
Also: Providing DRL features that are only available with Java 6/7/8... will
make documentation even more of a maze as it is now.
On 20 October 2011 13:49, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
The minimum java version we require (currently java 5)
need not be the same as the maximum java version language features we
For example, drools 6 could require at least java 5 to run, but
- if source>=7 and target>=7 you can use switch(String) and other coin
stuff in DRL functions
- if source>=8 and target>=8 you can use closures in DRL functions
The point is... drools-core source code itself can't use that stuff (unless
it's in the extension module drools-core-jdk7).
Spring 2.0.0 did something similar IIRC: it required at least JDK 1.4, but
if it detected JDK 1.5 you could use annotations too.
Note: despite all that, I still wish we move the minimum java version to 6
Op 20-10-11 13:26, Wolfgang Laun schreef:
Last time Mark asked, there was a huge outcry - some people using some Java
that's standing still at Java 5.
On 20 October 2011 13:21, Toni Rikkola <toni.rikkola(a)gmail.com> wrote:
> I would also like to keep it as close to Java as possible.
> There are few problems here:
> * It could never go beyond Java
> * We are using Java 5 and just considering Java 6, this would be a huge
> leap :-)
> But then again if we don't use the Java way, then what will we do when
> Drools reaches Java 8, support both?
> On Oct 20, 2011, at 11:08 AM, Geoffrey De Smet wrote:
> Interesting stuff.
> This is basically
> "closures" which will be available in JDK 8
> + LHS closure pattern support
> 1) About "closures" which will be available in JDK 8:
> Since functions contain Java code, which is imperative, not declarative, I
> don't consider that DRL turf any more.
> *Our closure syntax should there should be exactly the same as Java 8.*
> Here's their syntax, which looks the same on first sight, but the devil is
> in the details (= unreleased spec):
> Either we wait for JDK 8 to be released to support closures (current
> release date is 2012 according to Mark R.'s "plan B" that released JDK
> or we implement it just like the JDK8 with the exact same syntax (which is
> a LOT of work).
> 2) About LHS closure pattern support.
> This builds on top of 1) to allow usage of closures in the LHS.
> Cool stuff, I like the piping idea.
> Op 19-10-11 23:12, Mauricio Salatino schreef:
> Hi Mario, that document looks great.. I will take some time to read it and
> I will try to give some feedback.
> I was playing with cypher (from neo4j, a graph oriented DB) (total newbie
> on that) but looking at your in line acc functions I think that we can take
> some concepts from cypher and apply them in DRL.
> On Wed, Oct 19, 2011 at 5:59 PM, Mario Fusco <mario.fusco(a)gmail.com>wrote:
>> Hi all,
>> as anticipated by Mark, I put down some ideas on how we could start
>> introducing some functional programming features in the DRL.
>> It's needless to say that the document has to been considered just a
>> draft in its very first stage and any feedback or suggestion to improve or
>> clarify it is welcome.
>> rules-dev mailing list
> - CTO @ http://www.plugtree.com
> - MyJourney @ http://salaboy.wordpress.com
> - Co-Founder @ http://www.jugargentina.org
> - Co-Founder @ http://www.jbug.com.ar
> - Salatino "Salaboy" Mauricio -
> rules-dev mailing
> With kind regards,
> Geoffrey De Smet
> rules-dev mailing list
> rules-dev mailing list
With kind regards,
Geoffrey De Smet
rules-dev mailing list