Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

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?

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.

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

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.

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 ?

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

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