createComponent() / javaProxy() etc

andrew · April 18, 2015, 5:46pm

Answer on the ticket:

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - MemberOn 18 April 2015 at 18:37, Adam Cameron <@Adam_Cameron> wrote:

On Saturday, 18 April 2015 18:20:26 UTC+1, Andrew Dixon wrote:

Couple of things:

The web service is the HTTP address: the object one creates here is a

proxy to that.

Emm, this is used to connect to SOAP (Simple Object Access Protocol) web
services, so I’m sorry it doesn’t return a proxy it returns an object, the
give away is in the second word of the name of the protocol!!!

You need to keep reading all the way to the end of the name of the
protocol <---- that’s the very word there.

It’s a protocol to connect to (remote) objects. On the CFML end you have a
proxy for that object. You’re not calling methods on the remote object
directly - one would need to do that via an HTTP call, or natively on the
remote computer - you’re calling methods on the proxy which then translates
that into an HTTP request (and a bunch of other tedious crap), and sends
it, and handles the response converting it back into CFML.

So it’s… err… a proxy for the actual object.

:-p

And thanks regarding the other stuff.

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/b4402173-edc5-4088-94b5-bfe94d8b99c0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/b4402173-edc5-4088-94b5-bfe94d8b99c0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Adam_Cameron2 · April 18, 2015, 8:36pm

“from a CFML perspective what is returned is a Java object”

That is the reason I have used the word proxy in the first place, because
this is wrong and most people use this functionality wrong what leads to
overhead in their code.

No.

What the function is intended to do is return an instance of a Java object.

In that I can go createObject(“java”, “java.lang.String”) and then use that
object anywhere Java expects a string demonstrates this to be the case. And
before you start citing String as a bad example, it was just an example.

If under the hood you need to horse around with proxies and all other
sorts of magic to make it work is simply irrelevant as far as CFML goes.
It’s a Java object in the context of CFML.

You do make a point that you do some clever stuff (or at least emulate the
clever stuff Adobe had already done, let’s be honest) it exposing static
methods via the same function. But if anything this is where the
shortfall in createObject() lies. If to leverage a static method one needs
to use createOBJECT(), then - yes - that’s wrong. But in general, for
instantiatable (!) objects, what it’s doing is creating an object. But that
aside, CFML doesn’t make the distinction between the two cases, and this is
fine.

If there are performance issues with this approach to creating Java
objects, then this is your issue to fix, and is - again - irrelevant to
CFML.

You not longer seem to be able to see where your implementation of CFML
stops and actual CFML starts. The mere fact you need to do [something] in
Java to provide CFML functionality doesn’t mean you need to explain it at
CFML level in the naming of the CFML constructs. You’ve lost touch of what
CFML is.On Saturday, 18 April 2015 20:32:38 UTC+1, Micha wrote:

–
Adam

Adam_Cameron2 · April 18, 2015, 5:37pm

Couple of things:

The web service is the HTTP address: the object one creates here is a

proxy to that.

Emm, this is used to connect to SOAP (Simple Object Access Protocol) web
services, so I’m sorry it doesn’t return a proxy it returns an object, the
give away is in the second word of the name of the protocol!!!

You need to keep reading all the way to the end of the name of the
protocol <---- that’s the very word there.

It’s a protocol to connect to (remote) objects. On the CFML end you have a
proxy for that object. You’re not calling methods on the remote object
directly - one would need to do that via an HTTP call, or natively on the
remote computer - you’re calling methods on the proxy which then translates
that into an HTTP request (and a bunch of other tedious crap), and sends
it, and handles the response converting it back into CFML.

So it’s… err… a proxy for the actual object.

:-p

And thanks regarding the other stuff.On Saturday, 18 April 2015 18:20:26 UTC+1, Andrew Dixon wrote:

–
Adam

Adam_Cameron2 · April 18, 2015, 9:28pm

I didn’t even read all that (well: yeah I did, but only once, which is a
coupla times fewer than I usually read posts here).

You’re demonstrating my point: the quibbles you are having are all about
how you need to do stuff under the hood. No-one cares mate. Sorry.

In CFML one calls createObject(“java”) to get a Java object (or access to
static methods of a Java class, yeah, we get it). That’s it. All the rest
if it is relevant to the underlying code, but not to CFML.

I’m not trivialising CFML devs when I say this, or molly-coddling them
etc, but the language doesn’t make these distinctions that you happen to
know exist within your implementation.

Like I said: you’ve lost track of where your implementation code ends and
where CFML begins.–
Adam

On 18 April 2015 at 22:20, Michael Offner <@Michael_Offner> wrote:

No that is a good example let me extend it a little bit:
str=createObject(“java”, “java.lang.String”).valueOf(true);
Again no object from type String was produced with createobject, it only
produces a proxy objects to a class

But if I do this:
String=createObject(“java”, “java.lang.String”);
String.length();

It produces an instance of string in the second line and then it calls an
instance method, problem in every future call to this instance that is
inside the proxy has to go through the proxy object that is still around
it, it is like a door keeper that always check if we have a static call or
not.
we cannot change that fact, then you can still do this as well:
str=String.init();// create I a instance from the proxy

So the best is to use it as follows:
String=createObject(“java”, “java.lang.String”);
empty=String.init();
str=String.init(“Susi”);

Only use it to call static method or the create instances.
And if you need only one instance you do:
str=createObject(“java”, “java.lang.String”).init();

So technically there is no question, createObject-Java does not produce a
object from the class requested. The only question is, is this relevant for
the users using this function.
To be honest I was undecided from beginning about this, I think for
someone heavily relay on this it is relevenat, but for most users it is not.
So I think there is no right or wrong here, so I decided to rename the
function to JavaNew, not javaProxyNew or javaObjectNew.
I have not given the name JavaObjectNew for 2 reasons.

Again, it is not producing a object and I try to avoid to
actievely make this misconception.

The function JavaCast is not named cast2JavaObject, it also not speaks
from objects.

Micha

Am Samstag, 18. April 2015 schrieb Adam Cameron :

On Saturday, 18 April 2015 20:32:38 UTC+1, Micha wrote:

“from a CFML perspective what is returned is a Java object”

That is the reason I have used the word proxy in the first place,
because this is wrong and most people use this functionality wrong what
leads to overhead in their code.

No.

What the function is intended to do is return an instance of a Java
object.

In that I can go createObject(“java”, “java.lang.String”) and then use
that object anywhere Java expects a string demonstrates this to be the
case. And before you start citing String as a bad example, it was just
an example.

If under the hood you need to horse around with proxies and all other
sorts of magic to make it work is simply irrelevant as far as CFML
goes. It’s a Java object in the context of CFML.

You do make a point that you do some clever stuff (or at least emulate
the clever stuff Adobe had already done, let’s be honest) it exposing
static methods via the same function. But if anything this is where
the shortfall in createObject() lies. If to leverage a static method one
needs to use createOBJECT(), then - yes - that’s wrong. But in general, for
instantiatable (!) objects, what it’s doing is creating an object. But that
aside, CFML doesn’t make the distinction between the two cases, and this is
fine.

If there are performance issues with this approach to creating Java
objects, then this is your issue to fix, and is - again - irrelevant to
CFML.

You not longer seem to be able to see where your implementation of CFML
stops and actual CFML starts. The mere fact you need to do [something]
in Java to provide CFML functionality doesn’t mean you need to explain it
at CFML level in the naming of the CFML constructs. You’ve lost touch of
what CFML is.

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1f9740b4-677f-432c-9527-e72910034e8b%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1f9740b4-677f-432c-9527-e72910034e8b%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzNFXtZ6sZqrKL%3D3PwE5iAJv7i4kvAEYYuB0vNUFJHZOg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzNFXtZ6sZqrKL%3D3PwE5iAJv7i4kvAEYYuB0vNUFJHZOg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

micstriit · April 18, 2015, 10:12pm

I did CFML long before I have started Railo and I always have made this
distinction, so if you speak for CFML devs you are not speaking for me and
everyone I have reached this
If you read to the end you will see that I already agreed with you that
this distinction doesn’t matter…

MichaAm Samstag, 18. April 2015 schrieb Adam Cameron :

I didn’t even read all that (well: yeah I did, but only once, which is a
coupla times fewer than I usually read posts here).

You’re demonstrating my point: the quibbles you are having are all about
how you need to do stuff under the hood. No-one cares mate. Sorry.

In CFML one calls createObject(“java”) to get a Java object (or access to
static methods of a Java class, yeah, we get it). That’s it. All the rest
if it is relevant to the underlying code, but not to CFML.

I’m not trivialising CFML devs when I say this, or molly-coddling them
etc, but the language doesn’t make these distinctions that you happen
to know exist within your implementation.

Like I said: you’ve lost track of where your implementation code ends and
where CFML begins.

–
Adam

On 18 April 2015 at 22:20, Michael Offner <@Michael_Offner> wrote:

No that is a good example let me extend it a little bit:
str=createObject(“java”, “java.lang.String”).valueOf(true);
Again no object from type String was produced with createobject, it only
produces a proxy objects to a class

But if I do this:
String=createObject(“java”, “java.lang.String”);
String.length();

It produces an instance of string in the second line and then it calls an
instance method, problem in every future call to this instance that is
inside the proxy has to go through the proxy object that is still around
it, it is like a door keeper that always check if we have a static call or
not.
we cannot change that fact, then you can still do this as well:
str=String.init();// create I a instance from the proxy

So the best is to use it as follows:
String=createObject(“java”, “java.lang.String”);
empty=String.init();
str=String.init(“Susi”);

Only use it to call static method or the create instances.
And if you need only one instance you do:
str=createObject(“java”, “java.lang.String”).init();

So technically there is no question, createObject-Java does not produce a
object from the class requested. The only question is, is this relevant for
the users using this function.
To be honest I was undecided from beginning about this, I think for
someone heavily relay on this it is relevenat, but for most users it is not.
So I think there is no right or wrong here, so I decided to rename the
function to JavaNew, not javaProxyNew or javaObjectNew.
I have not given the name JavaObjectNew for 2 reasons.

Again, it is not producing a object and I try to avoid to
actievely make this misconception.

The function JavaCast is not named cast2JavaObject, it also not speaks
from objects.

Micha

Am Samstag, 18. April 2015 schrieb Adam Cameron :

On Saturday, 18 April 2015 20:32:38 UTC+1, Micha wrote:

“from a CFML perspective what is returned is a Java object”

That is the reason I have used the word proxy in the first place,
because this is wrong and most people use this functionality wrong what
leads to overhead in their code.

No.

What the function is intended to do is return an instance of a Java
object.

In that I can go createObject(“java”, “java.lang.String”) and then use
that object anywhere Java expects a string demonstrates this to be the
case. And before you start citing String as a bad example, it was just
an example.

If under the hood you need to horse around with proxies and all other
sorts of magic to make it work is simply irrelevant as far as CFML
goes. It’s a Java object in the context of CFML.

You do make a point that you do some clever stuff (or at least emulate
the clever stuff Adobe had already done, let’s be honest) it exposing
static methods via the same function. But if anything this is where
the shortfall in createObject() lies. If to leverage a static method one
needs to use createOBJECT(), then - yes - that’s wrong. But in general, for
instantiatable (!) objects, what it’s doing is creating an object. But that
aside, CFML doesn’t make the distinction between the two cases, and this is
fine.

If there are performance issues with this approach to creating Java
objects, then this is your issue to fix, and is - again - irrelevant to
CFML.

You not longer seem to be able to see where your implementation of CFML
stops and actual CFML starts. The mere fact you need to do
[something] in Java to provide CFML functionality doesn’t mean you need to
explain it at CFML level in the naming of the CFML constructs. You’ve lost
touch of what CFML is.

–
Adam

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1f9740b4-677f-432c-9527-e72910034e8b%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1f9740b4-677f-432c-9527-e72910034e8b%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzNFXtZ6sZqrKL%3D3PwE5iAJv7i4kvAEYYuB0vNUFJHZOg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzNFXtZ6sZqrKL%3D3PwE5iAJv7i4kvAEYYuB0vNUFJHZOg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAOPrabVwiWFOoET8oKtt_B5kzP%2BFSCEcVNnqT_Um0XgcOYr8CA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAOPrabVwiWFOoET8oKtt_B5kzP%2BFSCEcVNnqT_Um0XgcOYr8CA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Kai_Koenig · April 18, 2015, 11:38pm

Ok people, can everyone please calm down for a moment and take their hands off the keyboard.

I was following this thread very closely and both sides have a bunch of good arguments.

Micha’s technical arguments about how createObject works in various scenarios are absolutely correct. It’s weird and in some instances inconsistent when you look at it from a Java developer’s point of view.

Now, the question is — would this warrant a change in Lucee’s interperation of CFML? I don’t think so, to be honest. And this leads into:

Adam’s points are valid, too — the vast majority of CFML developers don’t give a damn crap about what happens below the CFML language level. All they care about is: CreateObject(“java”,…) gives some thing that they can use to call Java functions. That’s the reality and I think a good point of “language design” is to take this history into account.

Changes like the one discussed here can totally be done in the .lucee version of the language, go for it. But don’t break a lot of existing CFML code that exists out there.

The reality is: If I want to write proper OO- and Java-code, I actually use Java. If I want to or need to use a functional language, I use Clojure. Don’t try to bend CFML into something it isn’t and most likely never will be - it doesn’t create an incentive for people to use it at all imho.

On another, more general note:

The Lucee Foundation urgently needs a language advisory board. Micha, as much as I love and respect your work and ideas, I don’t think the way forward should be that a lot of language spec decisions are being made by 1 or 2 people behind the scenes. However the Lucee Foundation wants to implement this is not up to me to decide. Certainly your big-$-paying-members should have some votes/access to that, if you make it available to solely them though, you’ll risk alienate the “community” of people using it beyond the likes of those 5-6 companies.

Cheers
Kai> On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:

I did CFML long before I have started Railo and I always have made this distinction, so if you speak for CFML devs you are not speaking for me and everyone I have reached this

Really Micha?

You and your pals back whenever were wringing your hands and going “but it’s not a Java object, it’s merely a proxy to a Java object. And don’t get me started on static methods”.

Fuck off. Of course you weren’t.

If you read to the end you will see that I already agreed with you that this distinction doesn’t matter…

Yep, read it now. Missed it first time.

So you identified it as a non-issue, but you still decided to meddle with it? What’s wrong with you, man? Seriously. Actually seriously: why are you making CFML language decisions on this project?

–
Adam

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adam_Cameron2 · April 18, 2015, 10:20pm

I did CFML long before I have started Railo and I always have made this
distinction, so if you speak for CFML devs you are not speaking for me and
everyone I have reached this

Really Micha?

You and your pals back whenever were wringing your hands and going “but
it’s not a Java object, it’s merely a proxy to a Java object. And don’t
get me started on static methods”.

Fuck off. Of course you weren’t.

If you read to the end you will see that I already agreed with you that
this distinction doesn’t matter…

Yep, read it now. Missed it first time.

So you identified it as a non-issue, but you still decided to meddle with
it? What’s wrong with you, man? Seriously. Actually seriously: why are
you making CFML language decisions on this project?On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:

–
Adam

Steven_Neiland · April 18, 2015, 11:48pm

+1 To everything Kai said. In particular the urgent need for a language
advisory board.On Saturday, April 18, 2015 at 7:39:16 PM UTC-4, Kai Koenig wrote:

Ok people, can everyone please calm down for a moment and take their hands
off the keyboard.

I was following this thread very closely and both sides have a bunch of
good arguments.

Micha’s technical arguments about how createObject works in various
scenarios are absolutely correct. It’s weird and in some instances
inconsistent when you look at it from a Java developer’s point of view.

Now, the question is — would this warrant a change in Lucee’s
interperation of CFML? I don’t think so, to be honest. And this leads into:

Adam’s points are valid, too — the vast majority of CFML developers
don’t give a damn crap about what happens below the CFML language level.
All they care about is: CreateObject(“java”,…) gives some thing that they
can use to call Java functions. That’s the reality and I think a good point
of “language design” is to take this history into account.

Changes like the one discussed here can totally be done in the .lucee
version of the language, go for it. But don’t break a lot of existing
CFML code that exists out there.

The reality is: If I want to write proper OO- and Java-code, I actually
use Java. If I want to or need to use a functional language, I use Clojure.
Don’t try to bend CFML into something it isn’t and most likely never will
be - it doesn’t create an incentive for people to use it at all imho.

On another, more general note:

The Lucee Foundation urgently needs a language advisory board. Micha, as
much as I love and respect your work and ideas, I don’t think the way
forward should be that a lot of language spec decisions are being made by 1
or 2 people behind the scenes. However the Lucee Foundation wants to
implement this is not up to me to decide. Certainly your
big-$-paying-members should have some votes/access to that, if you make it
available to solely them though, you’ll risk alienate the “community” of
people using it beyond the likes of those 5-6 companies.

Cheers
Kai

On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:

I did CFML long before I have started Railo and I always have made this
distinction, so if you speak for CFML devs you are not speaking for me and
everyone I have reached this

Really Micha?

You and your pals back whenever were wringing your hands and going “but
it’s not a Java object, it’s merely a proxy to a Java object. And don’t
get me started on static methods”.

Fuck off. Of course you weren’t.

If you read to the end you will see that I already agreed with you that
this distinction doesn’t matter…

Yep, read it now. Missed it first time.

So you identified it as a non-issue, but you still decided to meddle with
it? What’s wrong with you, man? Seriously. Actually seriously: why are
you making CFML language decisions on this project?

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

denstar · April 18, 2015, 10:39pm

I didn’t even read all that (well: yeah I did, but only once, which is a
coupla times fewer than I usually read posts here).

I think we’d get further if you tried to understand what Micha is
saying, instead of being so focused on what you see the issue to be, to
the exclusion of salient bits of information.

This is about the “under the hood” as much as it is about what is “above
the hood” – it’s sorta like an intake which pokes through the hood.

At least for the java ↔ cf stuff, AFAICT.

In CFML one calls createObject(“java”) to get a Java object (or access
to static methods of a Java class, yeah, we get it). That’s it. All the
rest if it is relevant to the underlying code, but not to CFML.

I don’t get it. Are you talking about createObject or the new (heh)
functions?

I’m not trivialising CFML /devs/ when I say this, or molly-coddling them
etc, but the language doesn’t make these distinctions that you happen
to know exist within your implementation.

I think in general you’re right, but if we’re talking about cf/java the
distinctions do matter. At least a little. Moreso for people that use
it more-- so I like the idea of clear naming with the new functions.

Like I said: you’ve lost track of where your implementation code ends
and where CFML begins.

I lost track between createComponent and createObject.

-DenOn 4/18/15 3:28 PM, Adam Cameron wrote:

denstar · April 18, 2015, 11:14pm

I did CFML long before I have started Railo and I always have made
this distinction, so if you speak for CFML devs you are not speaking
for me and everyone I have reached this ;-)

Really Micha?

Dude-- Chill. Out.

You and your pals back whenever were wringing your hands and going “but
it’s not a Java object, it’s merely a /proxy/ to a Java object. And
don’t get me started on /static methods/”.

Fuck /off/. Of course you weren’t.

If anybody was… I mean the guy wrote a CFML interpreter.

When MX came out I was all up in there-- way way more* than most. It’s
OK if you weren’t, but enough with the attitude already.

*holy crap did digging into the underlying JasperReports implementation
teach me a bunch. And I’m still learning new stuff, years later! Wow!

If you read to the end you will see that I already agreed with you
that this distinction doesn't matter...
Yep, read it now. Missed it first time.

So you identified it as a non-issue, but you still decided to meddle
with it? What’s wrong with you, man? Seriously. Actually /seriously/:
why are you making CFML language decisions on this project?

What’s wrong with you, man? Srsly. Did you forget who yer talking to?

Please stop with the holier than thou, armchair-uber-coder nonsense.

You. Have. The. Power. (POIDH == Pull-request or it didn’t happen)

-Den “the power of Grayskull” UnoOn 4/18/15 4:20 PM, Adam Cameron wrote:

On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:

micstriit · April 18, 2015, 7:32pm

“from a CFML perspective what is returned is a Java object”

That is the reason I have used the word proxy in the first place, because
this is wrong and most people use this functionality wrong what leads to
overhead in their code.
Sean did a perfect explanation in a comment in your blog (
Adam Cameron's Dev Blog: Survey results: A quick OO terminology survey)
what
is going on with this function I will not repeat that.

CreateObject(“Java”,…) is a very smart implementation then in Java you
cannot produce objects from all classes, for example when the constructors
are private you can’t* (back at the Singelton example and why createObject
is bad, but that is an other story ).
Take this example:
System=createObject(“Java”,“java.lang.System”);
Dump(System.nanoTime());

This code never produces a object from type “java.lang.System”, this is
only a proxy for the “System” class. In fact you cannot* produce a object
from the class “System”.

Micha

*in Java you can modifie access modifiers at runtime what makes it possible
to invoke methods/constructors that are normally not accessible from the
current location, as long the security setting allow this.Am Samstag, 18. April 2015 schrieb Adam Cameron :

On Wednesday, 15 April 2015 21:53:35 UTC+1, Andrew Dixon wrote:

No idea what the word “proxy” is meant to mean in the context of these
function calls. To me you are not proxying anything, you are creating a
object of a class (Java) or a web service (SOAP).

I’ve been mulling this over. Andrew you are dead right. Including the word
“proxy” in these function names is incorrect. Under the hood Lucee needs to
do proxying stuff to expose the Java object to CFML, but from a CFML
perspective what is returned is a Java object. The under-the-hood
implementation details should not bleed out into the language here.

So: createJavaObject().

Now… one must separate my next comment from any recollection of my
current undertaking to get loadComponent() pushed back into
createObject()…

The more I think about the undertakings here, the more I think actually
the best solution FOR CFML would be to get rid of this function (the
Java one) and push the functionality back into createObject().
createObject() is the best name for all this functionality, as from a CFML
perspective that’s what the function is doing.

createWebsServiceProxy() makes sense to me though. Because from a CFML
perspective, that’s what you’re getting. The web service is the HTTP
address: the object one creates here is a proxy to that.

But what is CFML really gaining from this exercise? Nothing. It’s not
gaining anything. We’re just moving stuff around. Indeed it’s actually
a net loss for CFML developers because Micha is suggesting deprecating the
createObject() functionality, which really means ideally we have to update
our code to not use it (which comes with a not insubstantial cost!), as
well as retrain our brains. For no gain. This is not a win. Oh, and it
stops being ColdFusion compatible.

This is basically an exercise which is purely for Micha’s benefit, not the
CFML community’s. How about Micha does what he likes in .lucee files, where
the slate is clean, and just leaves well-enough alone in CFML? Even I
wouldn’t complain about retasking createObject() in .lucee files because
there’s no precedent to preserve. That said, the function names would still
need work, because the same shortfalls would still apply there as it does
in the current situation. But I’d have no problem with createObject()
always calling init(), createJavaObject() being specific for Java objects,
and createWebServiceProxy() being specific for web services. That makes
sense. And doesn’t the .lucee concept exists specifically for this sort
of thing? Are we making a mistake making any of these changes in the
CFML language here? Hmmm…

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1102ffc9-419e-423a-be9b-f89277b96b18%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1102ffc9-419e-423a-be9b-f89277b96b18%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Adam_Cameron2 · April 18, 2015, 5:06pm

No idea what the word “proxy” is meant to mean in the context of these
function calls. To me you are not proxying anything, you are creating a
object of a class (Java) or a web service (SOAP).

I’ve been mulling this over. Andrew you are dead right. Including the word
“proxy” in these function names is incorrect. Under the hood Lucee needs to
do proxying stuff to expose the Java object to CFML, but from a CFML
perspective what is returned is a Java object. The under-the-hood
implementation details should not bleed out into the language here.

So: createJavaObject().

Now… one must separate my next comment from any recollection of my
current undertaking to get loadComponent() pushed back into
createObject()…

The more I think about the undertakings here, the more I think actually the
best solution FOR CFML would be to get rid of this function (the Java
one) and push the functionality back into createObject(). createObject() is
the best name for all this functionality, as from a CFML perspective
that’s what the function is doing.

createWebsServiceProxy() makes sense to me though. Because from a CFML
perspective, that’s what you’re getting. The web service is the HTTP
address: the object one creates here is a proxy to that.

But what is CFML really gaining from this exercise? Nothing. It’s not
gaining anything. We’re just moving stuff around. Indeed it’s actually a
net loss for CFML developers because Micha is suggesting deprecating the
createObject() functionality, which really means ideally we have to update
our code to not use it (which comes with a not insubstantial cost!), as
well as retrain our brains. For no gain. This is not a win. Oh, and it
stops being ColdFusion compatible.

This is basically an exercise which is purely for Micha’s benefit, not the
CFML community’s. How about Micha does what he likes in .lucee files, where
the slate is clean, and just leaves well-enough alone in CFML? Even I
wouldn’t complain about retasking createObject() in .lucee files because
there’s no precedent to preserve. That said, the function names would still
need work, because the same shortfalls would still apply there as it does
in the current situation. But I’d have no problem with createObject()
always calling init(), createJavaObject() being specific for Java objects,
and createWebServiceProxy() being specific for web services. That makes
sense. And doesn’t the .lucee concept exists specifically for this sort of
thing? Are we making a mistake making any of these changes in the CFML
language here? Hmmm…On Wednesday, 15 April 2015 21:53:35 UTC+1, Andrew Dixon wrote:

–
Adam

micstriit · April 18, 2015, 9:20pm

No that is a good example let me extend it a little bit:
str=createObject(“java”, “java.lang.String”).valueOf(true);
Again no object from type String was produced with createobject, it only
produces a proxy objects to a class

But if I do this:
String=createObject(“java”, “java.lang.String”);
String.length();

It produces an instance of string in the second line and then it calls an
instance method, problem in every future call to this instance that is
inside the proxy has to go through the proxy object that is still around
it, it is like a door keeper that always check if we have a static call or
not.
we cannot change that fact, then you can still do this as well:
str=String.init();// create I a instance from the proxy

So the best is to use it as follows:
String=createObject(“java”, “java.lang.String”);
empty=String.init();
str=String.init(“Susi”);

Only use it to call static method or the create instances.
And if you need only one instance you do:
str=createObject(“java”, “java.lang.String”).init();

So technically there is no question, createObject-Java does not produce a
object from the class requested. The only question is, is this relevant for
the users using this function.
To be honest I was undecided from beginning about this, I think for someone
heavily relay on this it is relevenat, but for most users it is not.
So I think there is no right or wrong here, so I decided to rename the
function to JavaNew, not javaProxyNew or javaObjectNew.
I have not given the name JavaObjectNew for 2 reasons.

Again, it is not producing a object and I try to avoid to actievely make
this misconception.
The function JavaCast is not named cast2JavaObject, it also not speaks
from objects.

MichaAm Samstag, 18. April 2015 schrieb Adam Cameron :

On Saturday, 18 April 2015 20:32:38 UTC+1, Micha wrote:

“from a CFML perspective what is returned is a Java object”

That is the reason I have used the word proxy in the first place, because
this is wrong and most people use this functionality wrong what leads to
overhead in their code.

No.

What the function is intended to do is return an instance of a Java object.

In that I can go createObject(“java”, “java.lang.String”) and then use
that object anywhere Java expects a string demonstrates this to be the
case. And before you start citing String as a bad example, it was just
an example.

If under the hood you need to horse around with proxies and all other
sorts of magic to make it work is simply irrelevant as far as CFML
goes. It’s a Java object in the context of CFML.

You do make a point that you do some clever stuff (or at least emulate the
clever stuff Adobe had already done, let’s be honest) it exposing static
methods via the same function. But if anything this is where the
shortfall in createObject() lies. If to leverage a static method one needs
to use createOBJECT(), then - yes - that’s wrong. But in general, for
instantiatable (!) objects, what it’s doing is creating an object. But that
aside, CFML doesn’t make the distinction between the two cases, and this is
fine.

If there are performance issues with this approach to creating Java
objects, then this is your issue to fix, and is - again - irrelevant to
CFML.

You not longer seem to be able to see where your implementation of CFML
stops and actual CFML starts. The mere fact you need to do [something]
in Java to provide CFML functionality doesn’t mean you need to explain it
at CFML level in the naming of the CFML constructs. You’ve lost touch of
what CFML is.

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1f9740b4-677f-432c-9527-e72910034e8b%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1f9740b4-677f-432c-9527-e72910034e8b%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

micstriit · April 18, 2015, 11:08pm

Don’t call me a liar!On Sun, Apr 19, 2015 at 12:20 AM, Adam Cameron <@Adam_Cameron> wrote:

On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:

I did CFML long before I have started Railo and I always have made this
distinction, so if you speak for CFML devs you are not speaking for me and
everyone I have reached this

Really Micha?

You and your pals back whenever were wringing your hands and going “but
it’s not a Java object, it’s merely a proxy to a Java object. And don’t
get me started on static methods”.

Fuck off. Of course you weren’t.

If you read to the end you will see that I already agreed with you that
this distinction doesn’t matter…

Yep, read it now. Missed it first time.

So you identified it as a non-issue, but you still decided to meddle with
it? What’s wrong with you, man? Seriously. Actually seriously: why are
you making CFML language decisions on this project?

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

andrew · April 18, 2015, 5:20pm

Couple of things:

The web service is the HTTP address: the object one creates here is a proxy

to that.

Emm, this is used to connect to SOAP (Simple Object Access Protocol) web
services, so I’m sorry it doesn’t return a proxy it returns an object, the
give away is in the second word of the name of the protocol!!!

Micha is suggesting deprecating the createObject() functionality

I think stuff is getting lost in translation here. English is not Micha’s
first language, and while his English is head and shoulders above my Swiss,
because for me that would be zero, I think sometimes he uses the wrong
words. At least he didn’t say “depreciated”!!!

I will try to get an LAS official position out on this ASAP.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon
mso http://www.mso.net - Lucee http://lucee.org - MemberOn 18 April 2015 at 18:06, Adam Cameron <@Adam_Cameron> wrote:

On Wednesday, 15 April 2015 21:53:35 UTC+1, Andrew Dixon wrote:

No idea what the word “proxy” is meant to mean in the context of these
function calls. To me you are not proxying anything, you are creating a
object of a class (Java) or a web service (SOAP).

I’ve been mulling this over. Andrew you are dead right. Including the word
“proxy” in these function names is incorrect. Under the hood Lucee needs to
do proxying stuff to expose the Java object to CFML, but from a CFML
perspective what is returned is a Java object. The under-the-hood
implementation details should not bleed out into the language here.

So: createJavaObject().

Now… one must separate my next comment from any recollection of my
current undertaking to get loadComponent() pushed back into
createObject()…

The more I think about the undertakings here, the more I think actually
the best solution FOR CFML would be to get rid of this function (the
Java one) and push the functionality back into createObject().
createObject() is the best name for all this functionality, as from a CFML
perspective that’s what the function is doing.

createWebsServiceProxy() makes sense to me though. Because from a CFML
perspective, that’s what you’re getting. The web service is the HTTP
address: the object one creates here is a proxy to that.

But what is CFML really gaining from this exercise? Nothing. It’s not
gaining anything. We’re just moving stuff around. Indeed it’s actually
a net loss for CFML developers because Micha is suggesting deprecating the
createObject() functionality, which really means ideally we have to update
our code to not use it (which comes with a not insubstantial cost!), as
well as retrain our brains. For no gain. This is not a win. Oh, and it
stops being ColdFusion compatible.

This is basically an exercise which is purely for Micha’s benefit, not the
CFML community’s. How about Micha does what he likes in .lucee files, where
the slate is clean, and just leaves well-enough alone in CFML? Even I
wouldn’t complain about retasking createObject() in .lucee files because
there’s no precedent to preserve. That said, the function names would still
need work, because the same shortfalls would still apply there as it does
in the current situation. But I’d have no problem with createObject()
always calling init(), createJavaObject() being specific for Java objects,
and createWebServiceProxy() being specific for web services. That makes
sense. And doesn’t the .lucee concept exists specifically for this sort
of thing? Are we making a mistake making any of these changes in the
CFML language here? Hmmm…

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1102ffc9-419e-423a-be9b-f89277b96b18%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1102ffc9-419e-423a-be9b-f89277b96b18%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Adam_Cameron2 · April 19, 2015, 1:07am

Don’t call me a liar!

Huh?

This:
“but it’s not a Java object, it’s merely a proxy to a Java object. And
don’t get me started on static methods”.

So that is the way the CFML conversation went. Back then.

[boggle]

OK then.On Sunday, 19 April 2015 00:08:14 UTC+1, Micha wrote:

–
Adam

denstar · April 19, 2015, 8:34am

Based on the history of CFML it is a good bet that *createObject()
will never be removed*.
Then do not deprecate it. It sends the wrong message.

Deprecate != some kind of deadline for discontinuation, per se.

It can, but in general, at a bare-minimum, it means “there are better
ways of doing this”. At least in practice. And with precedence, as
Micha mentioned.

The sky is not falling. Things are the same as they have ever been, for
good or for ill (but let’s keep pulling for good, and maybe even
better). I wish I’d been able to keep the momentum going myself –
those installers are needed, and I know how much everyone misses my
witty banter when I don’t post – but Lucee is not doomed due to the
issues that have been raised thus far, and the excitement and lovey
dovey will be back. Things are gonna change (again), I can feel it.

…

Lets not run amok with wild stories of "createObject() will be
removed and break all existing CFML apps".
Requiring library and framework authors to use a deprecated language
feature in order to write portable code is a bad path to go down.

I don’t think this is really about portability.

Modifying createObject, vs. encouraging the use of namesAreHard(), makes
for code that is harder to port-- you’d need a regex grep to find the
difference without a language parser, vs. a simple grep. The error
message would be something harder to grok, for instance (I’ve always
loved the error handling in CFML).

That’s one of the things that gets me about this thread… it’s not that
the ideas are bad, it’s just that the supporting arguments seem to be
more subtext than substance, and there’s plenty of substance we could be
focused on.

-DenOn 4/19/15 12:12 AM, Sean Corfield wrote:

On Sat, Apr 18, 2015 at 10:34 PM, Geoff Bowers wrote:

modius · April 19, 2015, 5:34am

This is a language thing – its pure semantics. I can’t honestly see what
the fuss is.

createObject() or any other element of CFML will never be removed unless
Adobe decides to remove this from the language. Compatibility is a core
focus of the Lucee community – that will never change.

Based on the history of CFML it is a good bet that createObject() will
never be removed.

What @micha is trying to say – i believe – is that Lucee will not attempt
to extend or improve createObject(). And Lucee would prefer if there were
better options than createObject() but there are not, and there will likely
never be while Adobe controls CFML.

In order to improve on createObject() we have no choice but to create a new
set of functions. What these functions are and how they work is something
that should be discussed.

Lets not run amok with wild stories of “createObject() will be removed and
break all existing CFML apps”.

Solution: change it in your new language version .lucee, problem solved.

This is exactly what is being proposed. And if its deemed worthwhile, new
non-ACF functions could be made available in the CFML dialect.

GBOn Sunday, 19 April 2015 14:23:08 UTC+10, Kai Koenig wrote:

But don’t break a lot of existing CFML code that exists out there.
I would never allow that!!!
CreateObject is not touced at all, it is only deprecated (what only has a
small influence on the documentation) , it needs a lot that i remove a
deprecated functionality.
I only remove a deprecated functionality if nearly nobody use it and there
is a possible harm with it.
I was for example considering to remove what was never
supported in Railo/Lucee (it only throws a “not supported exception”) but
it is still in the core (only CFML) because it does no harm.

By deprecating a feature you’re telling the intended audience that this
feature is outdated and the “old” or “bad” way of writing code. It also
might or might not be removed at any time.

Even worse: you’re deprecating the feature for no good reason. Yes,
looking at it with the eyes of a Java developer I’d agree: It’s confusing.
It’s stupid and a collection of probably accidentally created functionality
back from the days in ACF 6.

But: to be frank - if I have to write cross-CFML server code, I don’t want
to deal with the fact that Lucee might at some point get rid of
CreateObject — which works and does its job just fine — just for the sake
of a language cleanup that (in this particular instance/discussion) I think
shouldn’t happen in the CFML version of Lucee in the first place.

Solution: change it in your new language version .lucee, problem solved.

Cheers
Kai

Kai_Koenig · April 19, 2015, 6:28am

100% agree with Sean on all the points below.

Cheers
Kai> On Sat, Apr 18, 2015 at 10:34 PM, Geoff Bowers <@Geoff_Bowers> wrote:

Based on the history of CFML it is a good bet that createObject() will never be removed.

Then do not deprecate it. It sends the wrong message.

What @micha is trying to say – i believe – is that Lucee will not attempt to extend or improve createObject().

He doesn’t need to deprecate the function to take that position. There’s plenty of CFML features that absolutely shouldn’t be extended or improved – but should not be deprecated.

In order to improve on createObject() we have no choice but to create a new set of functions.

BS.

Lets not run amok with wild stories of “createObject() will be removed and break all existing CFML apps”.

Requiring library and framework authors to use a deprecated language feature in order to write portable code is a bad path to go down.

Sean A Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/
World Singles, LLC. – http://worldsingles.com/

“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAD4thx9ASSoMgytSk1FFp%3Dw-0VBMD_Bes5Vcs%2BMJJ2fmJgUx3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

micstriit · April 19, 2015, 12:47am

Ok people, can everyone please calm down for a moment and take their hands
off the keyboard.
Im not sure if i’m now allowed to write or if i have to wait a little bit
…

But don’t break a lot of existing CFML code that exists out there.
I would never allow that!!!
CreateObject is not touced at all, it is only deprecated (what only has a
small influence on the documentation) , it needs a lot that i remove a
deprecated functionality.
I only remove a deprecated functionality if nearly nobody use it and there
is a possible harm with it.
I was for example considering to remove what was never
supported in Railo/Lucee (it only throws a “not supported exception”) but
it is still in the core (only CFML) because it does no harm.

The Lucee Foundation urgently needs a language advisory board. Micha, as
much as I love and respect your work and ideas, I don’t think the way
forward should be that a lot of language spec decisions are being made by 1
or 2 people behind the scenes. However the Lucee Foundation wants to
implement this is not up to me to decide. Certainly your
big-$-paying-members should have some votes/access to that, if you make it
available to solely them though, you’ll risk alienate the “community” of
people using it beyond the likes of those 5-6 companies.
This will come for sure, we simply had no time to get it in motion yet.
Every of our members will have a seat in it as defined in our “member
benefits” and we will also invite community members for the board.

MichaOn Sun, Apr 19, 2015 at 1:38 AM, Kai Koenig <@Kai_Koenig> wrote:

Ok people, can everyone please calm down for a moment and take their hands
off the keyboard.

I was following this thread very closely and both sides have a bunch of
good arguments.

Micha’s technical arguments about how createObject works in various
scenarios are absolutely correct. It’s weird and in some instances
inconsistent when you look at it from a Java developer’s point of view.

Now, the question is — would this warrant a change in Lucee’s
interperation of CFML? I don’t think so, to be honest. And this leads into:

Adam’s points are valid, too — the vast majority of CFML developers
don’t give a damn crap about what happens below the CFML language level.
All they care about is: CreateObject(“java”,…) gives some thing that they
can use to call Java functions. That’s the reality and I think a good point
of “language design” is to take this history into account.

Changes like the one discussed here can totally be done in the .lucee
version of the language, go for it. But don’t break a lot of existing
CFML code that exists out there.

The reality is: If I want to write proper OO- and Java-code, I actually
use Java. If I want to or need to use a functional language, I use Clojure.
Don’t try to bend CFML into something it isn’t and most likely never will
be - it doesn’t create an incentive for people to use it at all imho.

On another, more general note:

The Lucee Foundation urgently needs a language advisory board. Micha, as
much as I love and respect your work and ideas, I don’t think the way
forward should be that a lot of language spec decisions are being made by 1
or 2 people behind the scenes. However the Lucee Foundation wants to
implement this is not up to me to decide. Certainly your
big-$-paying-members should have some votes/access to that, if you make it
available to solely them though, you’ll risk alienate the “community” of
people using it beyond the likes of those 5-6 companies.

Cheers
Kai

On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:

I did CFML long before I have started Railo and I always have made this
distinction, so if you speak for CFML devs you are not speaking for me and
everyone I have reached this

Really Micha?

You and your pals back whenever were wringing your hands and going “but
it’s not a Java object, it’s merely a proxy to a Java object. And don’t
get me started on static methods”.

Fuck off. Of course you weren’t.

If you read to the end you will see that I already agreed with you that
this distinction doesn’t matter…

Yep, read it now. Missed it first time.

So you identified it as a non-issue, but you still decided to meddle with
it? What’s wrong with you, man? Seriously. Actually seriously: why are
you making CFML language decisions on this project?

–
Adam

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com
https://groups.google.com/d/msgid/lucee/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/181A3F2E-66DC-4951-9C60-8352C1D8A534%40gmail.com
https://groups.google.com/d/msgid/lucee/181A3F2E-66DC-4951-9C60-8352C1D8A534%40gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.