Re: Dependeny on javax.swing

Monday, December 28, 2009, 4:37:26 PM, Jeremy Chone wrote:

> I have seen that 2.4 faith is uncertain, but this could be a good
> milestone to break backward compatibility. 

You mean we should introduce this BC breaking in what is now called
FreeMarker 2.4? Unfortunately 2.4 is non-BC on several other ways, so
even if it would be ready for release right now, we still had to
address the issue for the 2.3.x users.

> About the contact in Google, I can definitely introduce someone
> from the freemarker team to them, but I do not think I can be an
> effective mediator (given my limited understanding of the
> internals). Let me know if someone wants an introduction. 

Certainly that will be Attila. He is the one who wrote all the
BeansWrapper (reflection) stuff.

> Jeremy,
>
>
> On Mon, Dec 28, 2009 at 4:30 AM, Daniel Dekany <[email protected]> wrote:
> Monday, December 28, 2009, 12:07:31 PM, Guo Du wrote:
>
>> 2009/12/28 Daniel Dekany <[email protected]>:
>>>> javax.swing.tree.*, that'd be a start. As I said, something similar
> [snip]
>>> So can that be worked around in FreeMarker (and of so, with how much
>>
>> I have two concern for work around javax.swing.tree.* package reference.
>
> Note that above I referred to the reflection issue.
>
>> 1. Backword compatibility, we don't want break the stable release
>> stream in 2.3.X. Even NORMAL freemarker usecase won't be involved with
>> the swing.
>
> Since Java language is quite static (which I like in general but these
> are the situations where it clearly backfires), the only
> backward-compatible work-around I can imagine is to create a separate
> release for each FreeMarker version that specifically targets GWE. But
> that's not that easy for the *users* as it may sound, as components
> that were not written specifically for GWE may pull in "plain"
> FreeMarker via automated dependency management (Maven, OSGi, etc.). I
> know, at least ideally that can be overridden, but I guess the way we
> upset the least number of users is by breaking the backward compatibly
> promise in this case, and blame Google.
>
>> 2. The simple/safe way to get away from javax.swing.tree.* is to
>> duplicate the used classes/interface insides freemarker such as
>> freemarker.core.tree. It may have copyright concern to the source
>> code.
>
> I didn't look into this, but most certainly we will have to re-write
> these from scratch, only by looking at the javax.swing Java docs.
>
>> P.S. There are only 4 direct reference in freemarker 2.3.15, so not a
>> big deal to just copy them to freemarker :)
>> ./freemarker/template/Template.java:57:      import javax.swing.tree.TreePath;
>> ./freemarker/core/FreeMarkerTree.java:56:   import javax.swing.JTree;
>> ./freemarker/core/FreeMarkerTree.java:57:   import
>> javax.swing.tree.DefaultTreeModel;
>> ./freemarker/core/TemplateElement.java:57: import javax.swing.tree.TreeNode;
>>
>> -Guo
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> FreeMarker-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>
>
> --
> Best regards,
>  Daniel Dekany

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev