Patch for support on Android
Generates text that depends on changing data (like dynamic HTML).
Brought to you by:
revusky
Menu
▾
▴
1 Attachments
#94 Patch for support on Android
Hi,
I had a hard time making FreeMarker run on Android. The cause of the issue is that Android lacks some classes in the java.beans and javax.swing packages.
I've worked around this issue by replacing static references to these packages in freemarker.ext.beans.BeanModel and freemarker.ext.beans.BeansWrapper. I've moved the affected methods into separate classes that are loaded via reflection, thus avoiding a static reference. There are two implementations: a standard implemantation using the classes from the java.beans package and an alternative implemantation that usese compatible classes from the com.madrobots.beans package for use on the Android platform.
I've also removed static references to javax.swing from freemarker.core.TemplateElement. I've created separate _TreeNode and _TreePath classes that are copies of the original JDK classes.
With these changes, I was able to run Freemarker on the Android platform. I've attached a patch for my changes in case you want to incorporate them into your code base.
Best Regards,
Oliver
Thanks for submitting your work on this. I will look into the mater as soon as... I get there in my FreeMarker backlog, for which first I have to kill lot of non-FM backlogs... /-:
The swing problem will eventually go away, as FM 2.4 (which is far away though) doesn't have that dependency anymore.
How to address the java.beans thing is trickier. I certainly don't want to duplicate that BeansWrapper method code; maybe this could be addressed in code-generation phase? Like, is the madrobots stuff similar enough so that simply replacing the package in the imports will work?
However, I'm not sure how many other differences will there be. (I remember how many ways did the Google App Engine "Java" break FreeMarker...) Are you working against the latest github version? Did the test suite run successfully? Putting madrobots.beans in to the OSGi import is also scary. Maybe the best would be if this is separate artifact... I don't know yet.
Ticket moved from /p/freemarker/bugs/408/
Ticket moved from /p/fmpp/feature-requests/26/
This is possibly connected to https://sourceforge.net/p/freemarker/feature-requests/105/ and https://sourceforge.net/p/freemarker/feature-requests/92/ in that those have problems with the standard JavaBeans introspector. So maybe sooner or later we should reimplement that our own anyway. Amd then, that will work on Andorid too.