you'll have to tell me more about what you want to achieve and why you need this.
single ("raw") dex I/O
there is limited support for dex reads from byte array and streams in RawDexIO:
public static DexBackedDexFile readRawDexFile(InputStream inputStream, long expectedSize, Opcodes opcodes) throws IOException
public static DexBackedDexFile readRawDexFile(byte[] buf, int offset, Opcodes opcodes) throws IOException
but there is no corresponding support for dex writes. the reason is: dexlib2 already does this. there is nothing to add, no Opcodes autodetection is applicable, so why replicate this interface? dexlib2 natively writes to streams, so byte arrays should be handled as byte array-backed output streams.
granted, RawDexIO could write to streams, but only as convenience methods to make the API more symmetric.
multi-dex
the focus of multidexlib2 is clearly files. for multidex, it could instead operate on:
lists of byte arrays (for read and write. this is kinda ugly.)
lists of input streams
factories of input streams
factories of output streams
clearly the factories of streams would be the underlying implementation of everything.
so...
the problems with this proposal are:
the already quite big interface would bloat to maybe double its size.
i have no use for these features, and by adding them i run the risk of introducing bugs to the existing code, which i do use.
limited time that i rather use to improve other stuff.
so you need to talk me into doing this by convincing me of why it is important and what there is to gain.
hi,
you'll have to tell me more about what you want to achieve and why you need this.
single ("raw") dex I/O
there is limited support for dex reads from byte array and streams in
RawDexIO:but there is no corresponding support for dex writes. the reason is: dexlib2 already does this. there is nothing to add, no
Opcodesautodetection is applicable, so why replicate this interface? dexlib2 natively writes to streams, so byte arrays should be handled as byte array-backed output streams.granted, RawDexIO could write to streams, but only as convenience methods to make the API more symmetric.
multi-dex
the focus of multidexlib2 is clearly files. for multidex, it could instead operate on:
clearly the factories of streams would be the underlying implementation of everything.
so...
the problems with this proposal are:
so you need to talk me into doing this by convincing me of why it is important and what there is to gain.
thanks!