velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <>
Subject Re: Problems with Overloaded Methods
Date Fri, 06 May 2005 17:23:34 GMT
Hi Tim,

I'm not familiar with this specific issue, but it sounds like a possible 
bug.  To answer your question, I don't think there's a good writeup.

Would you mind posting this in Bugzilla?



----- Original Message ----- 
From: "Tim Diggins" <>
To: "Velocity Users List" <>
Sent: Friday, May 06, 2005 4:13 AM
Subject: Problems with Overloaded Methods

> Hi -
> I'm having problems when calling overloaded methods from a vm template. 
> Typically this is a $util.makeHref($thing), where makeHref has several 
> overloads. If there is in an exact match between the method class and the 
> runtime classe of $thing, then there isn't a problem. But if $thing is a 
> subtype of one of the overloads (implementation or extension) then 
> velocity seems not to find it (just prints $util.makeHref($thing). (And 
> once (I can't repeat it) I got a null pointer error within the velocity 
> classes (no reference to my code at all in the traceback) - this may have 
> been my error, but I __think__ it was actually some kind of introspection 
> problem with a complicated set of overloaded methods).
> I noticed that Attila Szegedi (from 2002 - see 
> was offering to change the (then) current velocity mechanism for 
> introspecting the correct overload so it matched the JLS mechanism... Did 
> this ever happen?
> More importantly (I think) is there any write-up of the current mechanism 
> (heuristic) that velocity uses?
> (Apologies if I ought to have put this on the dev list, but I feel it is 
> really a user question, so ought to check the user list first.)
> many thanks
> Tim Diggins
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message