Community
Participate
Working Groups
In our Sirius based application, we want get byte array of diagram export, we use DialectUIManager.INSTANCE.export() to export to a temporary file and read this file to get a byte array. But it will be more direct to have our byte array.
Provide an alternative version of export() which takes an OutputStream instead of an IPath. This way you can provide it a ByteArrayOutputStream if that is really what you want but it is more flexible and does not impose the allocation of potentially huge byte array. Note that GMF's CopyToImageUtil, which we use for this, is hard-coded to only handle IPath/IFile, even though in the end it calls a saveToOutputStream(), but that method is private. This means copying code from GMF to adapt it (and maybe push a patch to their gerrit/bugzilla to support OutputStream more directly). The alternative would be to save into a temporary file and then read its content back as a byte array, but this you can already do with the current APIs.
Yes an OutputStream would be better especially for scalability, i.e. avoid Java heap space with big diagram. In our Sirius based application in which we use also CDO, we use export to store diagram image byte array in a CDO repo, but we have frequently Java heap space because of big diagram export. Using an OutputStream would solve this issue. The good solution would be to patch CopyToImageUtil to avoid thisJava heap space.
(In reply to Pierre-Charles David from comment #1) > Note that GMF's CopyToImageUtil, which we use for this, is hard-coded to > only handle IPath/IFile, even though in the end it calls a > saveToOutputStream(), but that method is private. This means copying code > from GMF to adapt it (and maybe push a patch to their gerrit/bugzilla to > support OutputStream more directly). Note that this part may be easier once https://git.eclipse.org/r/#/c/68358/ is merged, as it seems to duplicate the parts of GMF we would need to expose.
