You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by "Niclas Hedhman (JIRA)" <ji...@apache.org> on 2016/04/21 02:02:25 UTC

[jira] [Commented] (ZEST-50) Make the bytecode generation 'pluggable'

    [ https://issues.apache.org/jira/browse/ZEST-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250986#comment-15250986 ] 

Niclas Hedhman commented on ZEST-50:
------------------------------------

This is a very rare but perhaps important usecase. There isn't many different bytecode types out there, but Android is a large platform and may become a lot bigger in the future...

SO, instead of making a very explicit support for bytecode generation pluggability, I am adding support for a custom AssemblyHelper, and the default one will have a overrideable instantiateFragmentClassLoader(). This means that the functionality can be added with a little bit of work, but it is encompassed in a wider feature of replacing the entire fragment classloader.

> Make the bytecode generation 'pluggable'
> ----------------------------------------
>
>                 Key: ZEST-50
>                 URL: https://issues.apache.org/jira/browse/ZEST-50
>             Project: Zest
>          Issue Type: New Feature
>            Reporter: Paul Merlin
>              Labels: bytecode, core, extensions
>         Attachments: zest-android-screenshot.png
>
>
> Dalvik VM has a different bytecode set than Java, and it would be nice to allow the byte code generation (now in FragmentClassloader and TransientClassloader) to be fully pluggable to support Android in the future.
> What about ASMDEX or DexMaker ?
> See https://github.com/eskatos/qi4j-android-sample-app



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)