From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9628 invoked by alias); 20 Dec 2012 15:42:02 -0000 Received: (qmail 9619 invoked by uid 22791); 20 Dec 2012 15:42:01 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Dec 2012 15:41:50 +0000 Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qBKFfnuO018735; Thu, 20 Dec 2012 10:41:49 -0500 Date: Thu, 20 Dec 2012 15:42:00 -0000 From: Andrew Hughes To: Mark Wielaard Cc: classpath-patches@gnu.org, GCJ-patches , Matthias Klose Message-ID: <1403692328.18427553.1356018109688.JavaMail.root@redhat.com> In-Reply-To: <20121219173749.GA22367@toonder.wildebeest.org> Subject: Re: [cp-patches] [patch] let gjavah accept -source 1.[567] MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2012-q4/txt/msg00057.txt.bz2 ----- Original Message ----- > On Wed, Dec 19, 2012 at 02:01:10PM +0100, Matthias Klose wrote: > > Currently gjavah only accepts -source 1.4 and lower, and errors out > > for any > > other value. Would it be reasonable to accept higher versions too? > > I think that should be fine for gjavah, I cannot think of something > in the bytecode that would impact jni/cni header generation. > > But your patch is for gjdoc. There I think there are source > constructs > that might be a problem in newer versions. It should support some of > the new 1.5 source level features, but I am not sure if it handles > everything nor whether it handles any 1.6 and 1.7 extensions. > > > Index: classpath/tools/gnu/classpath/tools/gjdoc/Main.java > > =================================================================== > > --- classpath/tools/gnu/classpath/tools/gjdoc/Main.java (Revision > > 194604) > > +++ classpath/tools/gnu/classpath/tools/gjdoc/Main.java > > (Arbeitskopie) > > @@ -1339,10 +1310,13 @@ > > option_source = args[0]; > > if (!"1.2".equals(option_source) > > && !"1.3".equals(option_source) > > - && !"1.4".equals(option_source)) { > > + && !"1.4".equals(option_source) > > + && !"1.5".equals(option_source) > > + && !"1.6".equals(option_source) > > + && !"1.7".equals(option_source)) { > > If you really meant gjdoc I think it would be OK to try to accept it, > but maybe with a warning message that it is untested? > > Cheers, > > Mark > > > The question would make a lot more sense for gjdoc than gjavah :-) As is, it does support 1.5 to a degree (enough to compile the Classpath docs anyway; we should try OpenJDK at some point). There are no source changes in 1.6 and minimal ones in 1.7 so these should be easy to support, if they aren't already. I'm generally in favour of removing unnecessary version checks as they only mask the real bugs (e.g. when the parser hits a construct it can't handle) and would have to be allowed to actually implement the newer versions anyway. I think this is more a case of neglected code (given there were 1.5 updates) rather than a design choice. Note that I have a JAPI run of gjdoc vs. javadoc's API which points out some of the missing API (mainly, if not all, 1.5 stuff AFAICS) and I intend to look at implementing this soon. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07