Return-Path: Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org Received: (qmail 28402 invoked from network); 2 Dec 2010 15:22:31 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Dec 2010 15:22:31 -0000 Received: (qmail 40550 invoked by uid 500); 2 Dec 2010 15:22:29 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 40229 invoked by uid 500); 2 Dec 2010 15:22:29 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 39397 invoked by uid 99); 2 Dec 2010 15:22:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Dec 2010 15:22:28 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of cgfulton@gmail.com designates 209.85.213.175 as permitted sender) Received: from [209.85.213.175] (HELO mail-yx0-f175.google.com) (209.85.213.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Dec 2010 15:22:21 +0000 Received: by yxd5 with SMTP id 5so4249269yxd.6 for ; Thu, 02 Dec 2010 07:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=uw17Lutq0+MFMqy2uVWLKvfWjZHlS7KVI6k1HkALDpI=; b=unGzI5EdB61IqqG7Y6RwaPQ4U03T8w0kTMu6Wq0vaQaF7TVVVKEbVNkTDf1HjVd07C E5gZNBZPtUyiYAq2FcwRCrPkpCn4apUkXuc4zimc6KKnSSXL+jHm6dhJFgLQ3qHksfEy 714WzU1sPGO5ZXir2Sm710WXM0IOvqI+ulD9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ft+xpeXbz+DPVtRk+qEEGXm6Xd8PHzRX5Qk7zTTtoKN1Ne6qeAg5ne9+dDyZIHBWE0 2EyZFPOVqJlDZ7xcATpprln/GbwghobfetZ2Rqmf8CN1NwI2MxRXQuxwEnfqE0nEtcRD lYhKJdQ5ZXD2Zh4hAD0VpsvzDXBxN5GrcyGp4= MIME-Version: 1.0 Received: by 10.151.101.10 with SMTP id d10mr1594974ybm.431.1291303320619; Thu, 02 Dec 2010 07:22:00 -0800 (PST) Received: by 10.150.196.19 with HTTP; Thu, 2 Dec 2010 07:22:00 -0800 (PST) In-Reply-To: <4CF7B534.2010705@qcg.nl> References: <862502422.8331290517859184.JavaMail.hudson@aegis> <112459958.8391290520715806.JavaMail.hudson@aegis> <4CEBDFC0.90506@qcg.nl> <4CEBE8B0.2020806@qcg.nl> <4CEBED3F.3080504@acm.org> <77F1E32F67C8D5479858C0C7E93EB46503E19BB8@WAL-MAIL.global.avidww.com> <4CEC61DA.3030702@zeus.net.au> <4CECC1A5.7070804@qcg.nl> <4CED1D08.3030101@acm.org> <4CED23EA.1020208@qcg.nl> <4CF6688A.7070201@wonderly.org> <4CF685DA.3080000@acm.org> <4CF6D8B8.6090006@zeus.net.au> <4CF6E337.4050402@acm.org> <4CF6F077.7030704@acm.org> <84380CFD-746A-4F3C-9F53-E1B2493CF71F@topiatechnology.com> <1291266017.16266.3373.camel@cameron> <75124B2C-1116-4A35-A186-FDA769E0BC52@topiatechnology.com> <4CF7B534.2010705@qcg.nl> Date: Thu, 2 Dec 2010 07:22:00 -0800 Message-ID: Subject: Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3 From: Gerard Fulton To: river-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=001517511460b90bd404966efb33 X-Virus-Checked: Checked by ClamAV on apache.org --001517511460b90bd404966efb33 Content-Type: text/plain; charset=UTF-8 I think that Peter correct. River can potentially support both Java 1.5 and 1.6 in the future by implementing a modular build environment and using a profile/API approach. In my opinion the fact that the Jini community refused to address this issue was a serious black eye for the project. Gerard On Thu, Dec 2, 2010 at 7:03 AM, Sim IJskes - QCG wrote: > On 02-12-10 15:58, MICHAEL MCGRADY wrote: > >> There are no RT requirements for River. There is only the requirement >> that, if River wants to be compatible with Java RT that it not go to Java >> 1.6 but stick at Java 1.5. >> > > No matter what the outcome is of the version debate, i would like to > see/explained a way/method to verify the compatibility. > > You cannot ask a developer to run on anything less then JDK6 nowadays. You > can ask a developer to keep to certain compatibility conventions. In order > to guard against mistakes, we need a (preferably) automated method of > verifying if the code produced is still compatible. > > When we argue for a certain version, shall we include the verification > solution with it? > > Gr. Sim > > -- > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 > --001517511460b90bd404966efb33--