From owner-freebsd-java Sat Jun 22 2:24: 4 2002 Delivered-To: freebsd-java@freebsd.org Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.190.223.8]) by hub.freebsd.org (Postfix) with ESMTP id CCB6A37B400 for ; Sat, 22 Jun 2002 02:23:58 -0700 (PDT) Received: from andromeda (unknown [81.86.157.246]) by nemesis.systems.pipex.net (Postfix) with ESMTP id 0E15F1600028D for ; Sat, 22 Jun 2002 10:23:57 +0100 (BST) Content-Type: text/plain; charset="iso-8859-1" From: Darren Hobbs Reply-To: darrenh@dsl.pipex.com To: freebsd-java@freebsd.org Subject: Re: Future of Java question.... Date: Sat, 22 Jun 2002 10:23:55 +0100 X-Mailer: KMail [version 1.4] References: <20020621035341.A2383@dogma.freebsd-uk.eu.org> In-Reply-To: <20020621035341.A2383@dogma.freebsd-uk.eu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200206221023.55938.darrenh@dsl.pipex.com> Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a question I frequently consider. Pretty much all my working life is spent doing Java development. It is superbly suited for business systems. The abstractions make it very easy to write systems that embody complex business logic. It also makes hard things (like sockets) almost trivially simple to work with. However there can be no substitute for understanding. The ability to manipulate costly functions (like network or DB IO) easily also means its very easy to write shockingly inefficient code to do so. To a naive developer, establishing a new database connection, using it, then closing it again might seem the ideal approach. Doing it inside a loop in a multithreaded application might mean you are trying to open/close hundreds of connections a second. Your DBA won't find it funny. The issue of bloat sort of depends what you're used to. Yes the JDK is large, but once you have it, you have a huge range of ready-made libraries to use, and the Java classloader mechanism means that only the ones you are using will be loaded into memory. With regard to performance, Java started off as fully interpreted, very slow and clunky. A few months ago I wrote a simple Java application that searched for prime numbers in the dumbest way, and a colleague did the same in C. The Java version ran 10% faster than the C equivalent. Hotspot optimisation (even of really naive code) comes for free with Java, in C you have to optimise by hand. With regard to memory usage, the standard JVM isn't the slimmest thing out there, but again, although automatic garbage collection is great, it can't stop you writing poor code, and if you hold unneccessary object references they eat memory. For example, I was working on some java code to parse several very large XML data files and write out a consolidated dump file. The initial implementation read every data element into a new String object, and the program ate up over 900 meg of ram while it was working. Once it was working ok, I took a closer look at the data and realised a lot of it was repeated, so instead of creating a new String, I checked each one against a hashmap and used the one in the map (or added it if it was new). This had the effect of greatly reducing the number of objects in memory, and the footprint went down to about 250 Meg, of which most was in-memory lookup tables. The application also did in 12 minutes what used to take several hours with a combination of C, perl and shell scripts, at the expense of burning more memory while it was running. So while I know that Java has a finite lifespan, I haven't yet seen the obvious successor. -Darren On Friday 21 June 2002 03:53, j mckitrick wrote: > Hi all, > > I go back and forth between loving Java and hating it. I grew up doing > 6510 ML programming, and more recently, loving the performance Unix > affords. > > Java has amazing ways of making networking, I/O, event handling, and > programming in general so much simpler. But this comes at a price: > memory and CPU. My CPU usage in GKrellM is pegged for every compile and > run. Memory is sucked up by the Java VM. All-in-all, I'm not > sure how I feel about this. > > Maybe I'll decide to learn the Unix API better. But chances are, even > if I do, I'll be back to Java because of its elegance and platform > independence. The question is, are the benefits worth the price? In a > similar vein, does .Net exact the same kind of performance hit? In your > opinion, will Java remain a viable platform for the forseeable future? > Or will it bloat itself into oblivion? > > jm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message