So what will happen if there's no FileChannel available (for example, in
a servlet)? Will the AFP output stop working?

In additional to what Max wrote (preserving compatibility with output
targets that are not nio-compatible), I'd say that bit of potential
performance improvement is totally irrelevant in the command-line after
all the class loading and JIT. It might help in a server-environment,
though. But did you make any measurements that indicate that the
performance would indeed be considerably better? Or are you just
Steve McConnell's "Code Complete" comes to mind, too.

On 10.11.2008 13:13:03 Adrian Cumiskey wrote:
> Max,
> I understand what you are saying, but I am trying not to change too much code 
> or FOP's API with this 
> change.  Currently the BufferedOutputStream is passed as an OutputStream 
> reference all the way down 
> the calling chain during rendering.
> So although your suggestion would result in a much neater result, changing 
> the OutputStream 
> references to some sort of custom OutputSource would be quite a big change to 
> the FOP API and may 
> break existing FOP integrations.  This is why I was just proposing the 
> subclassing 
> BufferedOutputStream to expose the getChannel() method for the cases where 
> new I/O would be useful.
> Adrian.
> Max Berger wrote:
> > 
> > Adrian,
> > 
> > when doing this you need to be very careful that either the
> > BufferedOutputStream OR the FileChannel methods are used. If you start
> > mixing both you will get very strange effects.  So for safety I would
> > prefer to pass either a stream or a channel to a renderer, but not both.
> > 
> > Also, you need to make sure that the AFP renderer work if just a Stream
> > is available - this could be needed in cases where the output is stdout
> > (although I don't know if this would be a common use case).
> > 
> > Maybe a wrapper class similar to the idea of org.xml.sax.InputSource
> > would do the trick?
> > 
> > Max
> > 
> > Adrian Cumiskey schrieb:
> >> When FOP is started in Main.startFOP() a is
> >> instantiated and wrapped around an instantiated
> >>  By wrapping the initial
> >> with a, FOP is not
> >> able to potentially make use of the nio FileChannel stuff which could
> >> provide more efficient final output writing (using modern operating
> >> system caching) [1].
> >>
> >> This would especially be the case for AFP writing as output is initially
> >> written in two parts for memory saving reasons, one outputstream for
> >> document resources and one for the actual document.  On completion of
> >> rendering the document is appended to the end of the document resources
> >> outputstream.
> >>
> >> So I am proposing the introduction and instantiation of a
> >> FileChannelAccessibleBufferedOutputStream which extends
> >> in Main.startFOP().  It will expose the
> >> getChannel() method of  I have included the
> >> small code changes I am proposing below. Does this sound reasonable and
> >> would this cause any problems for anyone?
> >>
> >> Adrian.
> >>
> >> [1]


Jeremias Maerki

Reply via email to