Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 12266 invoked from network); 7 Feb 2007 00:01:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2007 00:01:01 -0000 Received: (qmail 51302 invoked by uid 500); 7 Feb 2007 00:01:05 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 51208 invoked by uid 500); 7 Feb 2007 00:01:05 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 51152 invoked by uid 99); 7 Feb 2007 00:01:04 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 16:01:04 -0800 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of listom@bestsolution.at designates 81.16.98.99 as permitted sender) Received: from [81.16.98.99] (HELO mail.bestsolution.at) (81.16.98.99) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 16:00:51 -0800 Received: from localhost (ogmios.bestsolution.at [81.16.98.100]) by mail.bestsolution.at (Postfix) with ESMTP id BC5D2122E40 for ; Wed, 7 Feb 2007 01:00:29 +0100 (CET) X-Virus-Scanned: BestSolution.at amavisd-new at bestsolution.at Received: from mail.bestsolution.at ([81.16.98.97]) by localhost (ogmios.bestsolution.at [81.16.98.100]) (amavisd-new, port 10026) with LMTP id SVe1iCzwRYCd for ; Wed, 7 Feb 2007 01:00:26 +0100 (CET) Received: from [127.0.0.1] (M272P024.adsl.highway.telekom.at [62.47.201.248]) by mail.bestsolution.at (Postfix) with ESMTP id 2BA2B122E65 for ; Wed, 7 Feb 2007 01:00:25 +0100 (CET) Message-ID: <45C916CD.7070304@bestsolution.at> Date: Wed, 07 Feb 2007 01:01:17 +0100 From: "listom@bestsolution.at" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: Initial impressions. References: <420ca0f60702061502i672b20a0s19ebe9f36fe3c866@mail.gmail.com> <31cc37360702061543r3804bea3ub62163ad9a941264@mail.gmail.com> In-Reply-To: <31cc37360702061543r3804bea3ub62163ad9a941264@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000711-0, 06.02.2007), Outbound message X-Antivirus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org Hi, Henri Yandell schrieb: > On 2/6/07, Nelson Carpentier wrote: >> Hello Everybody! >> >> Hopefully, this is more constructive than whiney. I thought I'd share >> my initial impressions with you about trying to contribute... > > Even whining can be good once we've got over the natural defensiveness :) > >> I recently got an inkling to add a cool bit of functionality to the >> EqualsBuilder in the Commons-Lang project. >> >> I went through the documentation and stuff, figured out some of the >> style guidelines and other bits, then went ahead and did a "svn co" of >> the code I wanted to help with... > > Main style guideline for any source is to adhere to the apparent style > of the source you're changing. And not to let the IDE reformat things > in your patches/commits (just spent a while dealing with a 1200 line > patch that was really only 200 lines... grrr). > >> I started up a project in Eclipse and though there were errors showing >> up everywhere, I was able to get to the code I wanted to change. I >> started modifying a bit of the code, and only tried to tackle all the >> errors popping up when I wanted to compile my code and write some >> tests against it... > > Odd that there were errors. Lang's a very simple project in that the > only dependency it has is JUnit and the only source trees you'll need > to hook up are src/java and src/test. There will be lots of style > warnings in Eclipse though. > >> That's when I figured out I was having a JDK versioning problem. I > > Ah, and a bunch of warnings about 'enum'. And probably some deprecated > bits. > >> was on a Mac (to which I am fairly new), and everything was running > > I'm on a Mac too. > >> the default of JDK 1.5. I looked at some more of the documentation >> and found that the JAR should be built with JDK 1.2. I figured out >> how to jump back to JDK 1.4.2 on the Mac, and maybe even to the JDK >> 1.3.X... But no JDK 1.2. > > There is no 1.2 on the Mac, and getting it on Linux is a pain in the > arse (apparantly it was poorly coded and used illegal APIs), so your > choices are to use Windows, use an old Linux install or use a glibc > patch on Linux. Oh - or use Solaris I presume. > > Macs went from 1.1.x on OS 9 to 1.3.x on OS X. > > For the last Lang release I pointed this out and we've moved the JVM > on which we build from 1.2 to 1.3. > >> While on JDK 1.4.2, a lot of things seem to resolve themselves, but >> there are some packages I cannot fix, because they use "enum" which is >> a reserved word in later JDK's. I haven't yet checked this in JDK >> 1.3.X, but I figured "Hey, why not go back to the recommended JDK >> 1.2?" > > The enum stuff is just a warning. Or should be. Are you sure these are > errors and not just lots of warnings? I usually use the command line > for developing Lang, but I go to Eclipse quite often to do the more in > depth debugging. > >> So, I went straight to http://java.sun.com. There in my initial >> research, I found out that they really aren't keen on even giving out >> the 1.2 JDK, and there was even a big ol' warning that 1.3.X was soon >> to be EOL'd (End-of-life'd.). (Nevermind the fact that I am not sure >> I even COULD get 1.2 installed on my Mac even if I found it...) > > Once Lang 2.3 is out, I want to start thinking about 3.0 and > suggesting the shocking idea of moving the support up to 1.5+. > Although moving forward is good most of the times. Such central components like lang should stay behind the current JVM release as long as possible IMHO because other project who are depended on it might not always upgrade to the latest and greatest JVM-Release immediately. I think it is better for these projects to stay at same JVM for a long time and than make a bigger step as proposed by you here. One more thing people might take into consideration (I don't know if applies here) is that java programs are not always running desktop JVMs but also ones for embedded devices, ... and not all classes are available everywhere! Tom --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org