Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 52006 invoked from network); 22 Jul 2002 14:38:42 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Jul 2002 14:38:42 -0000 Received: (qmail 20348 invoked by uid 97); 22 Jul 2002 14:38:55 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 20319 invoked by uid 97); 22 Jul 2002 14:38:55 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: 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 20297 invoked by uid 98); 22 Jul 2002 14:38:54 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Reply-To: From: "Berin Loritsch" To: "'Avalon Developers List'" , "'Jakarta Commons Developers List'" Subject: RE: [lang] Avalon.Excalibur.Util.system Date: Mon, 22 Jul 2002 10:38:34 -0400 Message-ID: <004301c2318d$75a87800$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Henri Yandell [mailto:bayard@generationjava.com] > > One of the pieces of Avalon code submitted to Jakarta Commons > was the util.system package of the Excalibur sub-project. > > Simply stated, the system sub-package is hidden behind a > SystemUtil class. It allows extra information about a JVM's > system to be accessed, > currently: > > cpuInfo, architecture name, operating system, os version. Number of CPUs > The static Util class hides a series of os specific plugin > classes [of type CPUParser]. > > It was suggested that the system classes might go into the > Lang project, due to their being effectively additional > functionality to the java.lang.System class. > > I'd like to -1 that for the following reasons: > > 1) The system package is platform dependent, ie) it's only as > good as the platforms it covers. Currently this is Windows > platforms and Linux. OS 9/X and the various Unixes don't > appear to be covered. That can be fixed with the addition of CPUParser implementations for each new platform that needs to be supported. > 2) The functionality it provides is relatively small, more > for display purposes it seems than actual logic, though I > could it being a standardised way in which to have different > logic happen on Linux with KDE, or different threading > strategy if it is known that the machine has 8 cpus. Right. The main purpose is to allow the user to find out how many CPUs exist. The extra formatting is for user feedback if a system needs it. > 3) The occasions when this information would be needed seems > to not be that common. Most of the components in Lang are > applicable in many situations, whereas this would be quite a > speciality piece. > > My suggestion is that this piece might be best placed as a > part of the Util subproject, unless a lot of work on it > happens and it grows in size, in which case it could be its > own sub-project. Where would it go? > So I'm -1 towards System in Lang. > > What is this code used for in Avalon?? It is used for determining the number of processors available on a machine. This allows automatic tuning of the Thread Pools used in the Event package's CommandManager. The CommandManager allows you to use a finite number of background threads to execute processes asyncronously in your system. It is more robust than JDK 1.3+ java.util.Timer in that it can handle exceptions without killing the system. -- To unsubscribe, e-mail: For additional commands, e-mail: