From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22195 invoked by alias); 25 Aug 2004 17:52:32 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 22180 invoked by uid 48); 25 Aug 2004 17:52:32 -0000 Date: Wed, 25 Aug 2004 17:52:00 -0000 Message-ID: <20040825175232.22178.qmail@sourceware.org> From: "mckinlay at redhat dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20040516104929.15474.green@redhat.com> References: <20040516104929.15474.green@redhat.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug java/15474] libgcj jar file should always be in classpath at runtime X-Bugzilla-Reason: CC X-SW-Source: 2004-q3/txt/msg00328.txt.bz2 List-Id: ------- Additional Comments From mckinlay at redhat dot com 2004-08-25 17:52 ------- As Mark suggests, the harm is that adding extra things to the classpath will cause these .jar files to be opened and searched for classes. That could slow down runtime start-up and increase memory usage. Even if our classloaders are smart enough to avoid looking in .jar files for classes that are compiled in to libgcj.so, they will still have to look when someone does, for example, a Class.forName() on a non-existant class. This actually happens all the time when loading ResourceBundles, for example, so even a well-written application can't easily avoid it. With well-written classloaders, however, it should be possible to minimize the overhead - so I'm not totally against this idea if it prooves to be useful. We just have to be careful about minimizing the cost. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474