dev@glassfish.java.net

Re: AMX (DeploymentMgr)

From: Lloyd L Chambers <Lloyd.Chambers_at_Sun.COM>
Date: Fri, 21 Jul 2006 14:53:19 -0700

Kohsuke,

It's a fact of life that the underlying configuration in domain.xml
uses a String that might not be an Integer. I didn't like this side-
effect of our support for template values, but the team looked at
alternatives, and there were no good ones.

Having to use Integer.parseInt() is not "bad code". It is code that
is based on the reality that the underlying value is multivariate.
If such were the criteria, then a huge portion of the JDK was "bad"
as well prior to the introduction of generics, since "Object"
included any possible value.

Generics could be helpful, but AMX was designed prior to generics,
AND another explicit design choice was the avoidance of all
proprietary types (over the wire) so as to offer maximal
compatibility. To a large degree, the client-side proxies can do the
translation, but inventing numerous new classes that need to be
serialized is a potential nightmare for backward compatibility.

I think it would be worth your time to read the AMX white papers for
perspective.

Lloyd Chambers
Sun AppServer team

On Jul 21, 2006, at 2:42 PM, Kohsuke Kawaguchi wrote:

> Lloyd L Chambers wrote:
>> A get/set operation would destroy the macro if the port were
>> resolved automatically.
>> int port = listener.getPort(); // assume it *was* $
>> {HTTP_LISTENER_PORT}, but resolves to a number automaticallyl
>> listener.setPort( port ); // value is now whacked to fixed value
>
> Yeah, but then, think about how hard it would be to correctly write
> the code that obtains the port number in integer!
>
> I bet people would just write code like this without knowing that:
>
> int port = Integer.parseInt( listener.getPort() );
>
> and it predictably fails. (This is also related to why type-safety
> is a good thing.)
>
> This is bad because API is driving people to the bad code.
>
> I guess you need a few more abstractions. Something like
>
> class Expression<T> {
> Expression(String text);
> T eval();
> String toString();
> }
>
> HTTPListenerConfig {
> Expression<Integer> getPort();
> void setPort(Expression<Integer>);
> }
>
> or something. I don't know. I agree it's hard to get this kind of
> API easier to use.
>
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com