Exadel, Inc., a provider of software, services and support that enable companies to create business applications based on open source and Java technologies, today announced general availability of Exadel Visual Component Platform 1.0, a component framework for the development of business applications based on JavaServer Faces (JSF).

Including a visual library of AJAX components, Exadel Visual Component Platform 1.0 extends JSF development environments by offering three elements: Components, which help companies improve their time and quality to market, AJAX-enabled components, which offer the ability to provide a user experience based on Web 2.0 and Skin-enabled components, which provide a customizable visual environment for building Web applications.

AJAX support with Exadel Visual Component Platform 1.0 includes:

• JSF Components with built-in AJAX support
• Adding AJAX capability to existing JSF components
• Adding AJAX capability without JavaScript code
• Client-side debug panel for tracking AJAX requests
• Full support for JSF lifecycle using AJAX

Exadel Visual Component Platform 1.0 is sold as an annual subscription per developer seat that includes all releases over the period of the subscription. Exadel plans to expand its platform with quarterly additions to the component library and additional functionality including more advanced integration with Exadel Studio, skin-enablement for MyFaces components, Skins designer and a components Debugger/Browser.

For more information, go to http://www.exadel.com/web/portal/press_20060320.

Would be nice to see the comparison in features and technical approaches between Exadel Ajax components and ICEFaces.

Michael! We will appreciate if you will do that kind of research and publish results.
JSF is growing and I, personally, love the combination of JSF 1.2 with Facelets. All things going smoothly and are very helpful. At least as helpful as any technology can be helpful to real world applications.

Best,
Igor Shabalov.

I, personally, love the combination of JSF 1.2 with Facelets.

De gustibus non disputandum est and I hope I won't start any framework war here, but <g>my opinion</g> is that facelets are the response to the lack of an open source visual editing support. Facelets biase the logic of JSF, where rendering should not be hardwired into the page.

Would be nice to see the comparison in features and technical approaches between Exadel Ajax components and ICEFaces.

I haven't had a chance to look at the Exadel stuff yet, but Facelets' next release should really support ICEFaces direct-to-dom features, along with ADF Faces ability to handle partial rendering.

Would be nice to see the comparison in features and technical approaches between Exadel Ajax components and ICEFaces.

I haven't had a chance to look at the Exadel stuff yet, but Facelets' next release should really support ICEFaces direct-to-dom features, along with ADF Faces ability to handle partial rendering.

What do you mean by saying "Facelets' next release should really support ICEFaces direct-to-dom features"? Facelets will have the same features as ICEFaces, or it will somehow support ICEFaces as a product? ICEFaces is a commercial product.

Facelets will be going 'pure' JSF such that all elements within the view, such as inline text, comments, tags, everything, will be written to JSF's ResponseWriter. Many of the solutions with AJAX leverage the pluggable ResponseWriter to receive document events, similar to SAX to determine changes in the view. Unlike most templating languages (velocity, freemarker, jsp), the whole page is executed/buffered in whole where JSF 1.2 and/or Facelets allows you to partially buffer/evaluate the component model. Because Java is pass by reference, Facelets can efficiently provide shared references to content/behavior within the component tree allowing programatic logic/3rd party plugins to later decide what to do with those references, keeping overhead to a minimum for very rich interaction within the UI.

Direct-to-dom or not, partial rendering is just a technical detail of the implementation. Our paradigm is to allow developers to avoid dealing with the underlying stuff, so they can concentrate on the business logic of their applications.
The very first version of Exadel VCP was released with Facelets support already. Strong Facelets support has always been an important part of Exadel's JSF-oriented products, you know.

Direct-to-dom or not, partial rendering is just a technical detail of the implementation. Our paradigm is to allow developers to avoid dealing with the underlying stuff, so they can concentrate on the business logic of their applications.The very first version of Exadel VCP was released with Facelets support already. Strong Facelets support has always been an important part of Exadel's JSF-oriented products, you know.

Yes, from what I've read so far on this component offering, it's very cool-- the way that AJAX *should* work in JSF.

offtopic:

[quote]Java is pass by reference[/quote]

C'mon jackob, I respect you a lot but you know what you just said isn't true. Java isn't pass by reference, but pass by value. The bits and bytes that make up a reference are passed by value. No way I can change what a variable points to for a variable that is passed to a method.

[code]
MyFoo foo = new MyFoo();

myMethod ( foo ); // myMethod can't change what foo references

...

void myMethod( MyFoo element ) {
     element = new MyFoo(); // no effect for our caller
}
[/code]

Java isn't pass by reference, but pass by value.

???

 The bits and bytes that make up a reference are passed by value. No way I can change what a variable points to for a variable that is passed to a method.

It's because that's a copy of the reference that's passed. But copying a ref does not mean pass-by-value at all !
Pass-by-value is the fact of passing a copy of the value, not of a reference to it...

Apparently you are confusing in/out params and by-value/by-reference semantics, which are completely different things.
You don't have "out" params in Java, but it's definitly by-ref everywhere : you can't pass by-value in Java, excepted primitive types.

Have fun,

Remi

It's because that's a copy of the reference that's passed. But copying a ref does not mean pass-by-value at all !

I'm sorry but it seems you're the one who is confused about this matter. Copying a ref IS a pass-by-value. In java, a reference variable does not 'hold' the object in question but rather it contains a bit pattern that is used by the VM to resolve the location to said object.

Now, the semantics of pass-by-value is that it makes a COPY of whatever a variable holds. That is precisely what is happening in Java. The bit pattern that functions as a locator to the object is literally copied. If the called method makes any change to this bit pattern, then this has no effect whatshowever to the caller.

If call-by-reference semantics were used then the called function would be able to access not only the object the reference points to, but also the variable that holds the reference.

Beginners often confuse these concepts since the name "reference" and "call-by-reference" are so simular. Nevertheless these are completely different things. Heck, if I'm not mistaken there's even a question on the Sun SCJP exam about this.

I don't know what you are talking about, but I'm talking about:

List a = new ArrayList();
assert a.size() == 0;
addStuff(a);
assert a.size() == 1;

List b = new ArrayList();
asser b.size() == 0;
addStuff(b);
assert b.size() == 1;

// equal
assert a.equals(b);

// addStuff method using the single instance of Widget
private final Widget widget = new Widget();
public void addStuff(List stuff) {
   stuff.add(widget);
}

I don't know what you are talking about, but I'm talking about: [...]

Jackob, that's USING a reference and has nothing to do with pass-by-reference semantics. You're passing a reference to a method. This happens *by-value*, and surely since you get a copy of the reference in that method, you can use this reference to access your list. As you must know, you never passed the list itself, but merely the reference and again the reference (aka the pointer) is copied.

I'm really suprized people actually start arguing about this.

Look at the following example:

List a = new ArrayList();
a.add( new Widget() );
assert a.size() == 1;
addStuff(a);
// addStuf can manipulate the object a points to, but cannot change
// what a points to.
assert a.size() == 2;

public void addStuff(List stuff) {
     // stuff is a copy of the reference, so OFCOURSE we can access
     // the object the original reference points to.
     stuff.add(widget);
     
     // However, the following assignment does not propagate to the
     // original reference, since we're working with a COPY of the reference
     // itself
     stuff = new ArrayList();
}

For people who still don't get this, think of references as INDEXES or KEYS to objects, not as objects themselves.

Observe the following code:

String[] strings = new String[2];

void foo() {
   int ref0 = 0;
   int ref1 = 1;
   strings[ref0] = new String("java");
   strings[ref1] = new String("jsp");

   changeStuff(ref0);

   // prints servlet, not jsp, ref0 is still 0
   System.out.println( strings[ref0] );
}

void changeStuff( int ref ) {
    // can use ref to access array
    System.out.println( strings[ref] );
    
    // can change things in array
    strings[ref] = new String("servlet");

    // But cannot change original variable
    ref =1; // local change
}

In both examples, the bit pattern of the variable is passed by-value, not by reference. The fact that in the first example the bit pattern can be interpreted as a pointer, does not all of a sudden promote it to pass-by-reference semantics. It's unfortunate that the name "reference" is used for both the pointer variable and the "indirection" semantics of the passing mechanism. I can understand this is confusing for some.

For the second example, everybody would agree the index is passed by-value. Yet, you don't call this pass-by-index, do you?

you're explaining techinical details of the compiler-- would you feel better if i would have said that java is passing new pointers that reference the same objects in memory in order to reduce memory consumption? do you think the average reader would've better understood my point by making such an asinine statement like that?

[quote]you're explaining techinical details of the compiler-- would you feel better if i would have said that java is passing new pointers that reference the same objects in memory in order to reduce memory consumption? [/quote]

You could have just said that in Java you can pass references around. That's even two letters shorter than saying you're passing by reference ;)

I'm really suprized people actually start arguing about this.

No kidding!
<br/>
I think we know what you're getting at - underneath it's pass by value, but the result to the developer is pass by reference. End?

I'm really suprized people actually start arguing about this.

No kidding!


I think we know what you're getting at - underneath it's pass by value, but the result to the developer is pass by reference. End?

Still wrong... It's pass by value ALL THE WAY... there is no compromise. You can't write the traditional swap function in Java, since JAVA DOES NOT HAVE CALL-BY-REFERENCE! Get this idea out of your head... it's not there... doesn't matter how much you wish it to be there, doesn't matter if you're famous from some project... it-simply-is-not-there. See this article for a good explanation: http://javadude.com/articles/passbyvalue.htm?repost JAVA USES CALL-BY-VALUE EXCLUSIVELY End?

Now, the semantics of pass-by-value is that it makes a COPY of whatever a variable holds.
 That is precisely what is happening in Java. The bit pattern that functions as a locator to the object is literally copied.

OK, I get your point : the reference is passed by value :-)

But still what's passed is a reference... don't you agree ?
You manipulate the param object, inside the called method, through its reference, don't you ?
Can you do it another way in a JVM anyway (you cannot "dereference a pointer" like in C to get its value, everything in Java is referenced AFAIK - excepted primitives) ?

So, if everything is reference in the JVM, how can the parameters be passed by value ??? Strange...

I knew param refs were copied, and thought it was for obvious security reasons... but I never thought about it like "passing the ref by value".

It does not really matter, it's just brain masturbation, but I'd be interested in some official material that details what you say, if you have pointers.

Have fun,

Remi

OK, I get your point : the reference is passed by value :-)
But still what's passed is a reference... don't you agree ?

Of course :) You pass *a* reference, but you don't pass *by* reference. That's a subtle but important difference.

Can you do it another way in a JVM anyway (you cannot "dereference a pointer" like in C to get its value, everything in Java is referenced AFAIK - excepted primitives) ?

Good observation Remy, indeed you can't. There's no concept of a "value" or "stack" object in Java like languages as C++ or C# do have. For anyone having a C++ background the difference is rather obvious. Syntax wise Java references may look like C++ stack objects, but they are actually just pointers. In C++ it's immediately clear what's the difference between passing a stack object or passing a pointer and doing any of that either by-value or by-reference (since there's explicit syntax for that).

So, there are atleast 4 possibilities of passing a parameter:

Stack object by value (entire object is copied and passed)
Pointer by value (pointer is copied and passed)
Stack object by reference ( address of variable holding stack object is passed)
Pointer by reference ( address of variable holder pointer is passed)

Each of these has its own behaviour.

In Java there's only 1 possibilty (pointers being passed by value), so a programmer who has only programmed in Java may not really be aware of or focussed on these differences.

We all agree here that there are no stack objects in Java (suprizingly, sometimes people even try to argue with that, saying Java doesn't have pointers so it must have only stack objects). This leaves us with only two options left. As I've been saying before, they key difference between pass-by-value and pass-by-reference is that one can change what the original variable holds (not change the thing it points to, but change *what* it points to). You can't do that in Java, so therefore you don't have call-by-reference semantics ;)

It does not really matter, it's just brain masturbation, but I'd be interested in some official material that details what you say, if you have pointers.

Well, for starters you might just want to read "the dragon book" ( http://www.amazon.com/gp/product/0201100886/104-5987390-6021516?v=glance&amp;n=283155 ). It has lots of details on the various passing mechanisms (more or less language neutral). I've been reading this when I first started building compilers and it greatly enhanced my insight.

More specifically I would like to refer to Sierra & Bates in their SCJP book. It has an entire section devoted to exactly this topic:

I quote:

Does Java use pass-by-value semantics?

If java passes objects by passing the reference variable instead, does that mean Java uses pass-by-reference for object? Not exactly, although you'll often hear and read that it does. Java is actually pass-by-value for all variables running within a single VM. [...]
It makes no difference if you're passing primitive or reference variables, you are always passing a copy of the bits in the variable. [...] if you're passing an object reference variable, you're passing a copy of the bits representing the reference to an object.

This is near official Sun material as Kathy and Bert are among the people who actually create the SCJP exams.

(ps also notice *single VM* being mentioned. When doing RMI, Java can do something like "pass-by-deep-copy" for the special 'remote' objects)

You pass *a* reference, but you don't pass *by* reference. That's a subtle but important difference.
[...]

Crystal clear, dude :-)

Actually I never thought about it like this and assimilated what is a clear by-value pass of the ref as... pass-by-ref of the instance ! Shame on me :-/
Thanks for this clarification !

Just one thing : are you sure that by-value == by-copy ? I don't remember passing copies of anything in C/C++... I'll ask my C++ colleagues at office, but all I remember is passing either values either pointers, but no copies...
Are the 4 cases you describe valid in C++ ?

You say :

Stack object by value (entire object is copied and passed)
Pointer by value (pointer is copied and passed)

What if I do the following :

class MyClass {
  ...

  // default constructor
  MyClass() {
    ...
  }
}

MyObject myObj; // default constructor called

// now call a function and pass myObj to it by value
myFunction(myObj);

Is myObj copied here ???

Are you sure that the copy is not another stuff, not related to by-value/ref ?

It's not that important, I don't do C++ any more and the subtle difference is practically not very important when programming in Java... just curiosity :-)

Have fun,

Remi

Thanks for this clarification !

You're welcome. Glad for being able to clarify :)

Is myObj copied here ???
Are you sure that the copy is not another stuff, not related to by-value/ref ?

Wow, this is getting really offtopic ;), but yes, the object is indeed copied, which is the definition of passing by value. However you should be aware of two pittfalls here. When making the copy, the public ctor does not run. Secondly, C++ defines by default a 'shallow' copy, i.e. a copy much like Java's Object.clone(); So if we had something like:

class Foo { public: int a; SomeObj* bar; };
void testFoo( Foo foo ) {
}
int main() {
Foo test;
test.a = 1;
test.bar = new SomeObj;
testFoo( test );
}

Then what essentially happens is the following:

// allocate memory for object test, don't run ctor e.g. malloc(sizeof(test));
test.a = foo.a;
test.bar = foo.bar;

In this case, we have made a shallow copy since the object test.bar points to is now shared between 2 objects. This behaviour is defined by the default copy constructor. If you want, you can define your own copy constructor and implement your own deep copy, but then you probably also want to define a matching assignment operator. Copy constructors are a concept that doesn't really exists in Java. (clone(), overriding clone(), and the native serialization support are some of the things you *could* use in Java instead)

Made a small typo above:

test.a = foo.a;
test.bar = foo.bar;

should of course be:

foo.a = test.a;
foo.bar = test.bar;

(isn't there an edit function for posts here?)