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

 


Forgot your password?
Close
typodupeerror
×
Java Programming Science

JADE Project Reborn As Javolution And jScience 20

Posted by timothy from the phoenix-like dept.
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 More

JADE Project Reborn As Javolution And jScience

Comments Filter:

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

    by Anonymous Coward

    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?

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

      Yes, because AC parent finds clicking the links TOO... MUCH... WORK...

    • Having actually read the links...

      Javalution is the actual JADE project that provides extensions to the base Java API to allow for real time processing. Provides better string manipulation, faster utilities such as FasterMap

      JScience's vision is

      • To provide the most comprehensive JavaTM library for the scientific community.
      • To create synergy between all sciences (e.g. math, physics, sociology, biology, astronomy, economy, etc.) by integrating them into a single architecture.
      • To provide the best on-line ser
  • It seems that there are more than a few JADE projects out there.

    I used JADE Java Agent DEvelopment Framework to perform agent oriented programming. (And I was really worried by the headline at first!) http://jade.tilab.com/
    If anyone is interested in agent oriented programming and design, I suggest you give it a look. It works really well and it is also open-source.

    If there are trademark issues with this other JADE, do you think they might have them as well?

  • Implementations (Score:3, Interesting)

    by ttfkam ( 37064 ) on Sunday October 24, 2004 @05:42PM (#10616269) Homepage Journal
    Looking at Text and TextBuilder, I can't help thinking that the interfaces between them and String and StringBuffer are basically the same. Aside from deprecating StringBuffer.capacity(..) method, anyone out there know why the implementations here couldn't simply be folded into the standard JRE/JDK? I realize the library is LGPL, but nothing in Text or TextBuilder appears to be new tech but rather old techniques applied to a new problem.

    The strengths of Java are not only in platform consistency but in API consistency. Is there guaranteed behavior of StringBuffer that cannot be handled by TextBuilder?

    As for the new interfaces, I wholeheartedly agree with Javalution's moves. Most simply amount to using CharSequence instead of String and this is a change that Sun IMO should have been more aggressive about. It would have broken some code, and I totally understand Sun's historical reluctance to do this, but Java 1.5^H^H^H5.0 did a lot of this anyway with the enum keyword et al. In for a penny, in for a pound.

    Maybe next time...

  • Summary of these technologies (Score:5, Informative)

    by BlueGecko ( 109058 ) <benjamin.pollack@ g m ail.com> on Sunday October 24, 2004 @05:42PM (#10616277) Homepage
    For those wondering: Javolution provides a set of classes that replace some of the core JDK classes with ones that run far faster and more efficiently. It also brings several key Java interfaces (such as Serializable or the Java 5 collection classes) to all available JDKs, even the miniature J2ME 1.1. These classes seem to work with or without garbage collection, as they have a custom object recycler. jScience, meanwhile, provides various common scientific and mathematic capabilities, such as linear equation solvers and efficient matrix operations. Both are open-source under the LGPL.

    Come on, Slashdot. It's not that hard to include this much description in the story.
  • Anyone with experiences to share?

    I'd be very intrested(hell, i'm tempted to give it a spin right now..).
    • It's better for some things, and worse for others. IIRC, JADE consumes more memory but runs pretty consistantly faster. Objects are pooled so they are ready for use. If you have the memory to burn, I would definately check it out.
  • I've had a look at the site now and when it was still the jade procet. What I would love to see is examples. Especially for the xml parser thing. Can it be used with Xalan ? Is it a drop in replacement for Xerces or what ? What to change if it is not ?

    Jari
    • The real-time parser looks and behaves like a SAX2 parser. The only difference is that Strings have been replaced by CharSequence. In other words, they will be some twinking in your code but not much. You can also use the SAX2 wrapper (XmlReaderImpl) in which case you don't have to change anything (but not as fast as String are dynamically allocated during processing).

  • Need language support. (Score:3, Insightful)

    by cakoose ( 460295 ) on Monday October 25, 2004 @01: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? :)


    • Why would a keyword be necessary for stack allocation. Look up a term called "Escape Analysis". It's not too hard for the VM to do this sort of thing automatically, and it would probably do a better job than a human programmer. Another good tactic is "Object Inlining" that can reduce the number of objects by some small factor (perhaps 2-3), also helping garbage collection.

      Basically, escape analysis, is when the compiler (VM) figures out which objects escape from the stack frame and which don't. Any that do

      • Look up a term called "Escape Analysis". It's not too hard for the VM to do this sort of thing automatically, and it would probably do a better job than a human programmer.

        Explicit annotation would help with virtual methods. Since classes can be dynamically loaded, the JIT can never say that "parameter X of virtual method M never escapes the stack." You can improve performance with optimistic approximations, but you're going to have to undo a lot of work if one "bad" method override gets loaded. T


        • I guess it's a grey arrea, but if you start making it complicated, then people won't do it, and we'll be right back to where we started, with more complexity to boot.

          The problem of a "bad" method being loaded doesn't seem so severe. Computers are fast. It turns out that computer performance is growing exponentially, but the size of the critical segments of code isn't really growing at all, maybe it's even shrinking. I think it's well beyond the 90 10 rule in most code now. Probably 1% of the code does more

Slashdot Top Deals

"Pok pok pok, P'kok!" -- Superchicken

Close