Return-Path: X-Original-To: apmail-ofbiz-dev-archive@www.apache.org Delivered-To: apmail-ofbiz-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 549FC18F2D for ; Wed, 14 Oct 2015 12:26:51 +0000 (UTC) Received: (qmail 17038 invoked by uid 500); 14 Oct 2015 12:26:38 -0000 Delivered-To: apmail-ofbiz-dev-archive@ofbiz.apache.org Received: (qmail 17011 invoked by uid 500); 14 Oct 2015 12:26:38 -0000 Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ofbiz.apache.org Delivered-To: mailing list dev@ofbiz.apache.org Received: (qmail 17000 invoked by uid 99); 14 Oct 2015 12:26:38 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Oct 2015 12:26:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id B0D12C4076 for ; Wed, 14 Oct 2015 12:26:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id qLJetsQanN-O for ; Wed, 14 Oct 2015 12:26:24 +0000 (UTC) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 2A289206E8 for ; Wed, 14 Oct 2015 12:26:23 +0000 (UTC) Received: from filter.sfr.fr (localhost [77.130.221.18]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id B2847700009C for ; Wed, 14 Oct 2015 14:26:17 +0200 (CEST) Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=permerror (cannot check policy: Unable to verify) header.from= jacques.le.roux@les7arts.com Received: from [192.168.1.2] (18.221.130.77.rev.sfr.net [77.130.221.18]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 6450B7000058 for ; Wed, 14 Oct 2015 14:26:17 +0200 (CEST) X-SFR-UUID: 20151014122617410.6450B7000058@msfrf2212.sfr.fr Subject: Re: Java 8 and functional programming in trunk To: dev@ofbiz.apache.org References: <10330279.746.1444817837690.JavaMail.taher@elterro-sam-ultra> From: Jacques Le Roux Organization: Les Arts Informatiques Message-ID: <561E49EE.90000@les7arts.com> Date: Wed, 14 Oct 2015 14:26:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <10330279.746.1444817837690.JavaMail.taher@elterro-sam-ultra> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit You are right there is no need to wait for a frozen branch, we can already put Java 8 new code features in trunk and we will have them in the next frozen branch which will need Java 8. Though we still need to agreed on this, I see not reasons we will not, so yes it seems to me a lazy consensus apply. On the other hand we need to be very careful when backporting to released branches. We shall not introduce Java 8 new code features in them, they are supposed to work with Java 7 only for supported ones (older we no longer backport anyway) Hoo I see https://issues.apache.org/jira/browse/OFBIZ-6458?focusedCommentId=14576325 :D You are a committer, go ahead (maybe wait few days if ever someone is against) BTW Java 8 is great but I believe Jigsaw in Java 9 will have even more impact, notably regarding the recent resurrection of the http://ofbiz.markmail.org/message/25dse4jke2fp64mx thread in the "Moving groovy script files" thread Jacques Le 14/10/2015 12:17, Taher Alkhateeb a écrit : > Hi Jacques, > > I am a bit confused? Why wait for a frozen branch for anything? I thought trunk is your development/unstable bleeding-edge part of the code. This is where you introduce changes without worrying about people's stable systems because they base their systems on release branches. In fact, branches exist only to stabilize trunk at certain points of time. > > Furthermore, if we introduce Java 8 into trunk, what possible logical reason exists for _voting_ to use the new features of the language? Why did you upgrade in the first place if you do not intend to use the newer features? > > Taher Alkhateeb > > ----- Original Message ----- > > From: "Jacques Le Roux" > To: dev@ofbiz.apache.org > Sent: Wednesday, 14 October, 2015 12:23:31 PM > Subject: Re: Java 8 and functional programming in trunk > > I tend to agree. Actually there are 2 points, > 1) use Java 8 to compile > 2) use new Java 8 features > > We can already do 1, but we should maybe wait the next freezed branch to do 2. That should be discussed but does not prevent 1. Of course any commit > with 2 will be rejected as long as an agreement on 2 will not be reached > > Jacques > > Le 11/10/2015 19:09, Ron Wheeler a écrit : >> I am not sure why backwards compatibility is an issue with moving to Java 8. >> >> It works well, >> it is the supported version of Java. >> As far as I have heard, the Java 8 JVM runs code compiled with earlier versions of Java. (My own experience is uniformly positive). >> >> I can see no reason to think that anyone who is developing or using OFBiz would need to compile or run with an older version of Java. >> >> In this day of VM and Docker Containers, it is hard to imagine that someone would be stuck on an older JVM in a production environment and unable to >> come up with a configuration that would allow them to run JVM 8 to support OFBiz. >> >> IMHO, we should just move to requiring the supported version of Java as soon as possible. >> >> Ron >> >> >> On 11/10/2015 4:14 AM, Taher Alkhateeb wrote: >>> Hello Everyone, >>> >>> We created and provided the patches for this issue since June and OFBiz is pretty much ready to move to JDK 8. I'm not sure if lazy consensus is >>> enough or whether a vote is warranted to move this issue forward? >>> >>> Cheers, >>> >>> Taher Alkhateeb >>> >>> ----- Original Message ----- >>> >>> From: "Pierre Smits" >>> To: dev@ofbiz.apache.org >>> Sent: Thursday, 7 May, 2015 10:52:00 AM >>> Subject: Re: Java 8 and functional programming in trunk >>> >>> I don't think that it is a question of using or not using J8. It is more >>> about when to move it into trunk, as from that moment on there will be >>> backward compatibility issues. >>> A helpful solution in this respect could be to designate a specific release >>> branch now (e.g. r15 or r16), create the version in JIRA and setup the dev >>> branch in svn. Doing it that way J8 related issues can get registered, >>> changes can get implemented and assessed (in the dev branch) without >>> breaking current stuff in trunk. >>> >>> But it also ensures that we can create awareness prior to releasing stuff. >>> >>> Best regards, >>> >>> >>> >>> Pierre Smits >>> >>> *ORRTIZ.COM * >>> Services & Solutions for Cloud- >>> Based Manufacturing, Professional >>> Services and Retail & Trade >>> http://www.orrtiz.com >>> >>> On Thu, May 7, 2015 at 9:30 AM, Nicolas Malin >>> wrote: >>> >>>> Ok Thanks Scott and Jacques. >>>> >>>> So Who is against use java 8 and more on trunk ? >>>> >>>> :) >>>> >>>> Nicolas >>>> >>>> >>>> Le 07/05/2015 08:46, Jacques Le Roux a écrit : >>>> >>>>> Yes (lazy) consensus over vote ;) >>>>> >>>>> Jacques >>>>> >>>>> Le 07/05/2015 05:02, Scott Gray a écrit : >>>>> >>>>>> I'm not sure if a vote is necessary, particularly if no one has any >>>>>> objections. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> On 7 May 2015 07:44, "Nicolas Malin" wrote: >>>>>> >>>>>> I'm favorable to use java 8. >>>>>>> I think it's will be pretty fin if you can support oracle jdk8 and >>>>>>> openjdk8 also. >>>>>>> >>>>>>> I propose to organize a vote to validate or not this proposition >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> Le 03/05/2015 11:52, Jacques Le Roux a écrit : >>>>>>> >>>>>>> Hi Taher, >>>>>>>> Yes I think so. For now well known (I hope ;)) security reasons, if >>>>>>>> people want to use Oracle JDK they need to use Java 8. >>>>>>>> So implementing with new Java 8 features now in trunk sounds good to >>>>>>>> me. >>>>>>>> BTW this is only my opinion... >>>>>>>> >>>>>>>> Note that our demos are still using OpenJDK 1.7 I'm not quite sure of >>>>>>>> the >>>>>>>> policy >>>>>>>> >>>>>>>> http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-23642/version_id-138218/Oracle-Openjdk-1.7.0.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 03/05/2015 10:52, Taher Alkhateeb a écrit : >>>>>>>> >>>>>>>> Hi everyone, >>>>>>>>> I would like to work on a few JIRAs and at the same refactor some >>>>>>>>> existing >>>>>>>>> code to utilize Lambdas and Streams utilizing Java 8 features. >>>>>>>>> >>>>>>>>> >>>>>>>>> Is it acceptable to develop with JDK 8 features into trunk? >>>>>>>>> >>>>>>>>> Taher Alkhateeb >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >