Re: Calling static methods, revisited

--000000000000b519e80606fc710d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It looks like this is the same as
https://issues.apache.org/jira/projects/VELOCITY/issues/VELOCITY-952 and is
a much bigger issue.

See also
https://issues.apache.org/jira/projects/VELOCITY/issues/VELOCITY-968

On Wed, Sep 27, 2023 at 6:03=E2=80=AFPM Christopher Schultz <
[email protected]> wrote:

> All,
>
> (This is all in the context of Velocity 1.7, but I'm not sure anything
> has changed through 2.x.)
>
> Sometimes you want to call a static method. Past workarounds are ugly
> but get the job done. For example:
>
> #set($string =3D "")
> $string.format($locale, "format string", args)
>
> I have a case where I've been working around java.util.TimeZone like this=
:
>
> #set($tz =3D $dateIHave.timeZone)
> #set($utc =3D $tx.getTimeZone('UTC'))
> ... use $utc
>
> In recent versions of Java (I'm using Java 17 at the moment), I'm
> getting this error:
>
> Exception: org.apache.velocity.exception.VelocityException:
> ASTMethod.execute() : exception invoking method 'getTimeZone' in class
> sun.util.calendar.ZoneInfo
> Stack Trace:
> org.apache.velocity.exception.VelocityException: ASTMethod.execute() :
> exception invoking method "getTimeZone" in class sun.util.calendar.ZoneIn=
fo
>
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:=
208)
> ...
>
> I'm intending to call java.util.TimeZone.getTimeZone which should be
> fine. But the runtime type of $tz ends up being
> sun.util.calendar.ZoneInfo which, unfortunately, defines its own static
> getTimeZone method whose signature matches that of java.util.TimeZone
> but is not callable due to module.
>
> In this case, is it possible for me to make a call to
> java.util.TimeZone.getTimeZone, or is it time to write a new Tool or
> customize an existing one (e.g. DateTool.getTimeZone(String zoneId)
> would be handy).
>
> Thanks,
> -chris
>

--000000000000b519e80606fc710d--