Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Programming Science

JADE Project Reborn As Javolution And jScience 20

dautelle writes "Because of trademark issues we had to rename our Java Addition to Default Environment (JADE) project. We did a little more than that, we created two new projects with additional features and capabilities: Javolution (javolution.org) and jScience (jscience.org). Java developers, please update your bookmarks. You may also read the 'Top 10 reasons' why you should consider using Javolution in your current Java project or how you can take part in this immense undertaking that the jScience project represents."
This discussion has been archived. No new comments can be posted.

JADE Project Reborn As Javolution And jScience

Comments Filter:
  • Yet again... (Score:2, Insightful)

    by Anonymous Coward on Sunday October 24, 2004 @06:34PM (#10616237)

    You may also read the 'Top 10 reasons' why you should consider using Javolution in your current Java project

    If you want us to use it, how about telling us WTF it is first?

  • by cakoose ( 460295 ) on Monday October 25, 2004 @02:52PM (#10623185) Homepage

    The object pooling is neat, but it's still too inconvenient for normal use. It's not too inconvenient for people who need the performance, though. It's also not too inconvenient for those who think they need the performance and are already doing some sort of custom object pooling. I wont be using it though.

    We need language-level support for more efficient memory use. We need to be able to more precisely declare how we're going to use an object and let the VM handle the optimizations automatically. The FAQ suggests that the 'new' allocator should be overridable but even that is at too low a level. I want to be able to declare parameters with the "no-escape" attribute to give the VM the freedom to put it on the stack. Of course, since Sun is Sun, we'll never see either feature.

    Does anyone know how it guarantees stack allocation? I couldn't find any native code in there so I wonder how it does it. I suppose you could code it in such a way that it's easy for the JVM to infer that certain objects don't "escape" from the stack, but that would be somewhat unreliable. Or are they just calling the zero-cost allocation "stack allocation" to get the attention of people (like me) who get all excited when they hear that term associated with memory-managed languages? :)

"Ninety percent of baseball is half mental." -- Yogi Berra

Working...