From owner-freebsd-java@FreeBSD.ORG Mon Jan 10 14:01:31 2005 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AA2516A4CE for ; Mon, 10 Jan 2005 14:01:31 +0000 (GMT) Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05AF343D4C for ; Mon, 10 Jan 2005 14:01:30 +0000 (GMT) (envelope-from iang@iang.org) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j0AE1D207754; Mon, 10 Jan 2005 14:01:15 GMT X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <41E28BEF.1070604@iang.org> Date: Mon, 10 Jan 2005 14:06:39 +0000 From: Ian G Organization: http://iang.org/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050108) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joris Verschoor References: <41DE4504.5040300@ebs.gr> <2569.216.220.59.169.1105114005.squirrel@216.220.59.169> <41E247F2.2070605@nefli.nl> <20050110102730.GA31285@mongers.org> <41E25A39.9040506@nefli.nl> <41E27513.9030909@iang.org> <41E27800.3030800@nefli.nl> In-Reply-To: <41E27800.3030800@nefli.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: java@freebsd.org Subject: Re: FW: Sun revokes FreeBSD license for Java X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 14:01:31 -0000 Joris Verschoor wrote: > Ian G wrote: > > True, but if you're using a 5.0 compiler, it will use StringBuilder > and other things 1.4 does not have, so although the bytecode is > compatible, 1.4.2 does not have the right libraries / methods :( Actually that's not the case, you can tell the compiler to compile for 1.4 as a target, and it avoids such things. > > I'd be nice, but I won't be using any non-standard stuff.. > >> >> I'd say that doing so was a mixed bag; one problem >> I saw was that the code couldn't then be compiled >> in anyone else's shop. Also, once used extensively, > > > Exactly my problem No responsible manager should ever let such a thing happen... It's just too risky on every level, given the whole environment. But, it doesn't speak kindly of Java; It should be quite routine to use such forward features in non-production code, and even to trial it in limited production, but the way Java is squeezed by so many coralling restrictions, one has to stay on the straight and narrow. I have no idea how big development environments manage to do this with their longer cycles. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/