[java-gnome-hackers] Fwd: Considering Trove

[Leonardo <som...@gm...>]

---------- Forwarded message ----------
From: Leonardo <som...@gm...>
Date: 2009/10/23
Subject: Re: [java-gnome-hackers] Considering Trove
To: Andrew Cowie <an...@op...>


No Andrew,

Avoid to add another dependency,

See, java gnome is somewhat stable for some years in the java side,
just adding dependencies in the gtk land.

You will have a finite ammount of widgets, i don't believe that one
could do some nasty and stupid application able to blow the memory
just with buttons, :P

if use primitives for keys still a good idea after fine tests don't
add it as dependency, but extract it directly for java-gnome, and only
that class.

belive me when i say that add another jar is a lot bad.

2009/10/23 Andrew Cowie <an...@op...>:
> I have for some time been very carefully watching the knownProxies
> HashMap in [org.freedesktop.bindings] Plumbing.
>
> This is the heart of java-gnome, mapping between our strong Java object
> Proxy instances, and instantiated GObjects on the native side. Every
> object [Widget, etc] that is created is stored there, in a <long, Proxy>
> map.
>
> Now, of course, Java's general utility collections require boxing of
> keys which means every addition and every query into that table creates
> a Long object wrapping the long [pointer address] as key. Lot of
> allocations for nothing, really, not to mention all the Map.Entry
> objects that get created.
>
> We have had memory pressure there before (which is why we split Proxy
> into Proxy & Pointer, for example). And while it's not the largest
> hotspot we have right now, essentially *every single code path* in
> java-gnome goes through this table.
>
> As a result I have long speculated that we should replace the
> [java.util] HashMap with something a bit smarter, preferably something
> that takes long primitives as keys, not Long objects as keys.
>
> ++
>
> One possibility is the Trove project, a promising set of collections
> that use different algorithms to the [java.util] ones, and which offer
> sets and maps with native keys and/or values.
> http://trove4j.sourceforge.net/
>
> I did some experimentation and came up with a branch that uses their
> TLongObjectHashMap for the knownProxies map. I uploaded it to
> 'hackers/andrew/trove-external' so you can have a play if you're
> interested. It will configure and build if you're on Ubuntu Karmic.
> bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/trove-external/
>
> Works fine; I'm still trying to figure out if it's an improvement [or
> degradation] profiling wise (we need some better tools for this sort of
> thing); doing compartive studies of GUI application performance is
> notoriously hard, of course.
>
> ++
>
> Anyway, there is a bigger question: should we use this, and if we do,
> should we incur the cost of an external dependency?
>
> This is a non-trivial question. Not only would it mean "java-gnome build
> depends on trove4j", but of course *also* would mean requiring people to
> express the location of the trove jar when trying to run a program built
> with java-gnome; ie just to run a demo program I had to go from
>
> java -classpath /home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment
>
> to
>
> java -classpath /usr/share/java/trove-2.0.4.jar:/home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment
>
> {sigh}
>
> [Java's design is so desperately lacking in this regard it's not even
> funny; doing something about it is on my list of itches, but that's not
> something any of us are going to fix overnight]
>
> There is an alternative, and that would be to import the necessary
> [gnu.trove] classes (only) into java-gnome, placing it say in
> lib/dependencies/. I'm *not*a huge fan of this idea; I've spent enough
> time as a Gentoo Java person to know how much effort we usually have to
> spend ripping out embedded junits, jaxens, etc and how horrible static
> linking is, etc.
>
> Indeed, it's time Java people stopped being afraid of depending on each
> other's code, so perhaps I should just bite the bullet, say "too bad"
> and tell people that we now depend on this [or whichever] library. But
> given that it is essentially just one single piece of Trove  that we
> would be depending on, it is almost tempting to just embed it in our
> code base.
>
> ++
>
> Anyway, I'd welcome some discussion on all this, both on the topic of
> the suitability of Trove's [gnu.trove] TLongObjectHashMap as a
> replacement for Sun's [java.util] HashMap, and on the question of other
> Java libraries as dependencies.
>
> I'd like to thank Rob Eden, the current Trove maintainer, for his
> guidance and encouragement.
>
> AfC
> Sydney
>
>
> --
> Andrew Frederick Cowie
>
> Operational Dynamics is an operations and engineering consultancy
> focusing on IT strategy, organizational architecture, systems
> review, and effective procedures for change management: enabling
> successful deployment of mission critical information technology in
> enterprises, worldwide.
>
> http://www.operationaldynamics.com/
>
> Sydney   New York   Toronto   London
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>