Slashdot Mirror

← Back to Stories (view on slashdot.org)

JADE Project Reborn As Javolution And jScience

Posted by timothy on 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."

20 comments

  1. Re:Java? LOL by Anonymous Coward · · Score: 0

    Memory management, standardized, speed, cross-platform...

  2. Yet again... by Anonymous Coward · · Score: 2, Insightful

    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?

    1. Re:Yet again... by lars-o-matic · · Score: 1

      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...

      --
      je ne suis pas un fou
    2. Re:Yet again... by spot35 · · Score: 1

      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 services (webstart) for scientific calculations and visualizations.

      Of course, for more details, actually click the link!

  3. What about the other JADE? by Axiom_D · · Score: 2, Informative

    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?

    1. Re:What about the other JADE? by jkauzlar · · Score: 2, Informative

      Not to mention the Jade Docbook processor and Jade text editor...

  4. Implementations by ttfkam · · Score: 2, Interesting

    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...

    --

    - I don't need to go outside, my CRT tan'll do me just fine.
    1. Re:Implementations by Anonymous Coward · · Score: 0

      All utility classes are now public domain (version 1.0.7). Now nothing prevents Sun from including the amazingly "fast" Text/TextBuilder classes to the standard Java distribution.
      They might also be interested by the Struct/Union classes, also public domain (very useful when interfacing with C/C++ code).

    2. Re:Implementations by ttfkam · · Score: 1

      I doubt they would add Text and TextBuilder as they are. More likely, I could see them replacing the implementations of String and StringBuffer. Why add more classes when you can make the classes that people are already using much faster? What I'm wondering though is if there are technical reasons why this could not be done. Thread safety? Context in other classes?

      As for Struct and Union, since Sun historically hasn't given a rat's ass about making interaction between Java and C or C++ (have you seen JNI?), I would be EXTREMELY surprised if they found their way into the standard libraries.

      --

      - I don't need to go outside, my CRT tan'll do me just fine.
  5. Summary of these technologies by BlueGecko · · Score: 4, Informative

    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.

  6. experiences with j2me and javolution? by gl4ss · · Score: 1

    Anyone with experiences to share?

    I'd be very intrested(hell, i'm tempted to give it a spin right now..).

    --
    world was created 5 seconds before this post as it is.
    1. Re:experiences with j2me and javolution? by j3110 · · Score: 1

      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.

      --
      Karma Clown
  7. Re:Java? LOL by Anonymous Coward · · Score: 0

    Oh, please.

    Post a feature set, not a TO-DO list.

  8. Examples, examples, examples! by jarpak · · Score: 1

    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

    1. Re:Examples, examples, examples! by dautelle · · Score: 2, Informative

      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).

  9. Need language support. by cakoose · · Score: 2, Insightful

    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? :)

    1. Re:Need language support. by iwadasn · · Score: 1


      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 don't escape are stripped of synchronization (since they are incontestable), and then allocated on the stack so they don't need to be GCed. It's not too hard to do escape analysis, and there are prototype systems that hack it into java already. It's a small step from that to a full feldged implementation.

      Object inlining is similar. It detects objects that don't escape from their parent object (lots of strings are like this, completely contained within another object), and then it inlines their data into the parent object rather than a reference. This reduces the number of actual objects to be handled by the GC by 1. In addition, it allows whole new classes of method inlining between the parent and child methods, and elimination of a large number of dead fields within the child if they aren't ever accessed from the parent, it just depends on how much code you want to recompile to allow these advanced optimizations.

      Sun should put these in, but it's understandable that they haven't put them in yet. In most (but not all) java programs, GC is not a significant part of the overhead now due to good garbage collectors. I'll be a little upset if they don't start including it in version 1.6 though, as it looks like they cleaned house with 1.5, and these sorts of optimizations should now be pretty much on the top of the list.

    2. Re:Need language support. by cakoose · · Score: 1
      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. The problem could be mitigated by good heuristics. I believe that they already do some "unvirtualization" of method calls, which would also help.

      I suppose it could be a bad thing to allow "no-escape" annotations on virtual method parameters -- the performance benefit may not be worth the added difficulty -- but I can think of one real-world example where they'd help: java.awt.Component's setSize(...) method. Then again, maybe we just need to make more things immutable.

    3. Re:Need language support. by iwadasn · · Score: 1


      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 than 99% of the work, if I had to guess. This is what has made VMs competitive, the relative cost of compilation and analysis has been shrinking relative to the cost of actually performing the calculations. Now VMs can just use normal (damn the cost) compilers, it just doesn't really matter anymore. Even a huge app can compile fairly quickly, especially when you're only compiling 10% of the code.