[The Web Maestro]
I don't know how the spec deals with this, but I doubt the
spec cares which algorithm is used. That said, would it be a
good idea to determine which algorithm to use based on
something in userconfig.xml or something? If the Knuth system
is more 'expensive' in terms of
[Luca]
I'm not sure it is always possible to do this: sometimes the
representation of a block depends on the properties of a higher level
block. For example:
outer block
|
-
| |
innerinner
blockblock
12
In order to decide whether there
[Jeremias]
I think there is something fundamentally wrong with the layout dimension
mechanism. I've found two problems, one minor, one very bad:
1. While implementing percentages for background-position-horizontal and
-vertical, I realized that it wasn't so simple to base the calculation
on a
[Simon]
There does not seem to be a need to add
the inherited value later; the property maker already has done so. See
IndentPropertyMaker.compute(PropertyList). It uses
propertyList.getInherited(baseMaker.propId).getNumeric()) to get the
inherited value. Earlier FOP developers understood this
[Jeremias]
would you please check if it is acceptable to put the inherited values
directly into the CommonMarginBlock? It might have been cleaner to
always get the value via the parent FO but I think in this case it helps
simplifying the code in TraitSetter and BlockLayoutManager.
It looks wrong,
[EMAIL PROTECTED] wrote:
Log:
convertValueForProperty didn't have the right signature and
therefore didn't override the superclass implementation.
That was sloppy of me. Thanks for finding and fixing it.
+ListProperty listProperty = (ListProperty)property;
That is a no-no.
Simon Pepping wrote:
On Tue, Dec 28, 2004 at 06:03:13PM -, [EMAIL PROTECTED] wrote:
Index: LengthBase.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datatypes/LengthBase.java,v
retrieving revision 1.8
The loop can be stopped when we temporary run out of FO tree
nodes and restarted again when new nodes has been added. I
suppose that the FO tree can then be viewed as a stream of FO nodes.
[Victor]
This model probably works fine if you never need to look ahead, but there
are numerous examples
The problem with Keirons layout code (with respect to large input
files) is that it works top-down on the LM tree and thus require the
creating of the complete LM tree for the page sequence. To better fit
within SAX event model the layout process should also be event driven,
triggered f.ex by
Hi,
I've been playing around with the knuth line breaking code and made a
slight refactoring of it. The result is 38% faster for START align,
78% faster for CENTER align and 12% for JUSTIFY align.
Meassured using 'time' command, jdk1.4.2_03, -Xmx2 and a rough
edition of Sherlock Holmes
[Peter]
As a completely unintentional side-effect, it gave me the tools to solve
the really critical FOP performance problem on large files. This isn't
going to be solved by micro-efficiencies on FO tree storage.
I'm going to use this as a excuse to outline my thinking for handling
large input
[Simon]
I have just committed a patch which fixes bug 32253. One problem
remains: the text in the marker does not always have the right
properties, e.g. the right size. This is probably due to the fact that
Marker.rebind() does not rebind the whole subtree below a marker.
Your right! It seems that
Hi,
What is the logic behind the INFINITE_DEMERITS = 1E11 ? Having a
threshold of 20 can result in a demerit value of
(1 + 100 * 20 ** 3) ** 2 == 6.400016E11
for the first KnuthNode which is then ignored since it is worse than the
initial demerit value.
I would guess that when we use a
1) What is inactiveList doing. Nodes are added but never used.
[Simon]
It contains all feasible breakpoints except those that are still
active, i.e., are still in scope as the start of a line ending at the
currently considered breakpoint. At the end of the loop the active
list only contains nodes
And why not adjust the spacing within the user specified min/max for
START and END alignment?
[Luca]
Should the user desire adjusted spaces, wouldn't it be better for him to
specify justified alignment? :-)
Seriously, the recommendation (at 7.16.2 letter-spacing and 7.16.8
word-spacing) states
Hi
Some more questions.
1) What is inactiveList doing. Nodes are added but never used.
2) If there is no shrink in a line (the case in START alignment) then
nodes are never removed from activeList until a forced break element is
found. Is that really the intention of the algorithm? It seems
1) What is the purpose of 2 glues for a normal space in END and START
alignment:
new KnuthGlue(0, 3 * wordSpaceIPD.opt, 0, , false));
new KnuthPenalty(0, 0, false, , true));
new KnuthGlue(wordSpaceIPD.opt, - 3 * wordSpaceIPD.opt, 0, , true));
[Luca Furini]
The purpose is to give each line (but
Hi Luca (and others),
I've been trying to get my head around the line breaking code and during
that process some questions has come up. I urge you *not* to take
anything I ask as a sign of criticism or as a request for changes. I
don't have the Knuth paper where the algorithm is described so
[Glen]
2.) Appended EN_ to enumeration constants to
[J.Pietschmann]
Yuk. Having a large number of identifiers in the
same scope with
an identical prefix isn't very good for
autocompletion both in
Emacs and Eclipse.
[Glen]
We've been doing the same with PR_ (properties) and
FO_ (FO's) for quite
[Finn]
It [an INHERIT constant] isn't needed as an enum value
because the 'inherit' keyword takes precedence over
the other enumeration values. See 5.9.11:
The Keyword values take precedence over
EnumerationToken.
where Keyword is 'inherit'. The code to handle
'inherit' is at line 397
[Glen]
This is possibly a question for Finn, but if anyone knows: In our
Constants.java [1], we don't have an property enumeration constant for
inherit. (Go here [2], and search on inherit, you will see it
listed in the Value: section for multiple properties.) Is there any
reason why we
[Glen]
Does anyone have a problem if I worked towards
removing the initialize() method from our
LayoutManager interface?
There is two way of looking at it. The code in initProperties() which
can be moved to the ctor should be. That is no loss at all and will
reduce complexity of the LMs a tiny
[Glen]
Finn, keep in mind--both you and Simon wanted
pluggable LM's, and you even supplied a patch for it a
few months ago. But you have been mostly silent on
the matter ever since (i.e., it looks like you don't
have a need for it ATM.)
Or perhaps I've been working on other things, like
[Peter]
On the topic of exceptions, and now that it's all over...
I was puzzled by this discussion. Would anyone expect that Defoe would
subclass SAXException for document validation errors?
That is your choice. Surely exceptions that occured during SAX event
handling (eg startElement) should
[Chris]
I'm definitely in agreement with you on this one Glen. Lets keep
Layout simple whilst its still unfinished.
Pluggable LMs can be added once we have an
initial release.
[Andreas]
Well... (sigh)... well ('nutha sigh)
What *does* Finn think, in that case? So far, I've yet to hear a single
[Tibor Vyletel]
Hello Fopsters,
I use FOP (dev 1.0) in a bit different scenario as you. My renderer works in
GEF framework. Till now, I have hacked simple change in relevant layout
managers:
BlockLayoutManager.getParentArea(Area childArea) {
...
// this creates connection between fobj and
[Glen]
I'm not clear why you didn't derive
ValidationException from SAXParseException. I know
the locator is already present in FOPException, but
absent the subclass from SAXParseException, it ends up
being a different Locator object, i.e., user code
that would handle a SAXParseException can't
[Andreas]
It seems more about not throwing SAXParseExceptions,
but catching them and
throwing a FOPException instead. Isn't that the
issue? That a
'missingChildElementError' is actually not a
SAXParseException... because it
has nothing to do with SAX in itself
[Glen]
SAXParseExceptions would
[Glen]
Still, I wonder if it may be better to do away with
this interface and just hardcode the layout/rendering
of these objects (i.e. bookmarks) directly, just like
we do all the other Area objects that are created
during the layout process. This would simplify
area.extensions.BookmarkData and
[Glen]
Actually, to clarify what I wrote: why do we need an
extension interface (TreeExt) for objects placed
outside the document (pdf bookmarks/metadata), while
*not* needing one for extension objects that end up
placed *on* the document?
You subclass Area for elements on the document and TreeExt
[Glen]
OK, I'd like to
1) rename TreeExt to OffDocumentItem (to clarify what
it's really for)
2) change it from an interface to an abstract base
class.
3.) Have this base class hold the when parameter for
when this ODI is to be generated, so the when does
not need to be hardcoded into
Hi Team,
I would like to make some changes to the exceptions used in tree building.
First, I dislike throwing SAXParseException from within FOP. In my
opinion SAXParseException are for reporting problems during the parsing
of XML, not for reporting subsequent problems with the FO tree.
Second,
[Glen]
I'm confused--why is OK to throw SAXExceptions but not
its child SAXParseExceptions? With the latter, it
just holds locator information necessary to pinpoint
the problem for the user. Please elaborate.
The way I see it SAXException is the exception used to communicate
across the
[Glen]
Still, I wonder if it may be better to do away with
this interface and just hardcode the layout/rendering
of these objects (i.e. bookmarks) directly, just like
we do all the other Area objects that are created
during the layout process. This would simplify
area.extensions.BookmarkData and
[Glen]
The FObj.bind() method throws a SAXParseException if
this method hasn't been overridden in the FObj
subclass. I'm unsure why a subclass override is
required (as the javadoc comment for this method
indicates)--wouldn't it be OK if we just have an empty
method here without the exception
Hi Team,
I'm no expert on java's xml transformer APIs so I need a little help.
It appears to me that when using the identity Transformer from xalan we
no longer get notifications of XML parse errors.
Using an obviously corrupt input fo:
?xml version=1.0 encoding=UTF-8?
xfo:root
[Glen]
I'm not sure of the problem here, your input fo is not
an xsl fo, because the xfo to a namespace wasn't
bound. Hence the Xerces error message--what is it
that you're expecting instead?
I would expect that the ErrorHandler methods in FOTreeBuilder
(warning(), error() and fatalError()) was
[Andreas]
Hi Finn,
Not sure if this is what you're looking for, but the
javax.xml.transform.Transformer class does offer a setErrorListener() method
to use a custom Error Handler... IIUC, all we have yet to do is provide an
implementation for a javax.xml.transform.ErrorListener and use it to route
Hi Peter,
Did I miss the announcement?
http://defoe.sourceforge.net/
regards,
finn
[Peter]
Alt-design just uses a sparse array, constructed at END_ELEMENT. Space
savings are progressively realized as the depth of the FO Tree reduces.
Maximum consumption occurs at the points of greatest depth of the
tree, minima at the end of each page-sequence.
[me]
IIRC your sparse array does
Why is it more efficient (I know it is, given your
metrics, but want to know why)--aren't you just moving
the values already stored in the PropertyList into
separate fields in the FO objects? Yes, you're
releasing the PropertyList's memory, but the elements
that the PropertyList previously stored
[Luca]
IMPORTANT: I had to revert Finn Bock's changes to the PDFRenderer (dated
2004/09/22 13:22:16), otherwise leaders with svg use-content produce
errors in the pdf output.
There isn't any run-time error, but when I try to open the pdf file, I get
these warnings:
- There was an error processing
[Clay]
Which of the alignment-* property is the one you're referring to that
has been implemented?
I was just looking at them from the point of view of the property
subsystem, where only baseline-shift has been implemented. I didn't
mean to imply that it actually work all the way through
[Glen]
So if we did this at the FO level, in effect, we'd
have to (1) store an instance variable of every
valid
property for each FO, given that we wouldn't know
whether the FOEventHandler's needs it beforehand,
and
[me]
Yes. Which is massively more efficient than storing
the exact same
Keep in mind that there is 2 different sets of
properties:
- The set of specified properties.
- The relevant properties (as listed in the spec
under each element).
The existing PropertyList stores the specified
properties in the super
HashMap and has an additional cache which stores all
In my proposal the specified and the cached properties are still stored
in the property list but only the relevant properties are retained in
the fo object.
[Andreas]
Yes, and IIJC, at the same time, you're eliminating the need for downstream
property queries having to be performed through the
Hi Team,
I've put together another largish patch that changes the way properties
and used by the FO objects, the layout managers and the FOEventHandler
subclasses.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31699
The performance increase is 42% while at the same time using %27 less
[Glen]
All fo elements are required to
extract all the
properties that they need and to store the values as
instance fields in
the fo element.
I love the performance boost you're recording but have
a philosophical issue of an fo object needing a
property--it is really an issue of the
[Jeremias]
If switched the junit tasks to write to System.out instead of to a file.
Hopefully, we will get more usable output this way. I don't know if we
can get Gump's full output somewhere so we could check the test reports.
BTW, I have no errors locally.
I get an error:
junit:
[echo]
[Jeremias Maerki]
Finn, it seems to me that you probably forgot the check in all your
changes. FOP doesn't compile ATM. The method makeBorder is missing.
Yes, I forgot. I'm sorry for the inconvenience.
Glen, Thank You for temporarily fixing my mistake.
regards,
finn
[Glen]
I see. I liked Locator because I can get away with
passing in one parameter into the vCN() instead of
three. (But I don't think we'll need to change that
portion of the code because whenever vCN() is being
called, the Locator *is* accurate--would you agree?)
Yes.
regards,
finn
Hi Glen,
I think that your recent change that stores the Locator instance in each
FONode is incorrect use of the Locator interface. The docs says:
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/org/xml/sax/Locator.html
Note that the results returned by the object will be valid only during
the
Hi Team,
I think the API for adding additional element mappings to the
FOUserAgent is bound to cause problems when fop is deployed in a multi
classloader environment.
Using tomcat as an example, an extension mapping deployed in a webapp
can not be found if a well meaning administrator has
[Simon Pepping]
I propose that we make Luca Furini a member of the FOP team.
Here is my +1 vote.
+1
regards,
finn
A (farfetched) argument against ThreadLocals would be that they
prevent one FOP processing run to occur recursively during another
independent processing run. Like an extension element that itself
will attempt to process another fo document.
[Glen]
I think that restriction is implicit in the
[Jeremias]
Hi Finn,
I took a look at it and I must say that I'm a bit confused, too.
Anyway, I have a proposal to make. I would expect a command-line
application to work like any other C-program such as grep, svn, ls or
whatever. That means you don't get any [INFO] before each line, but
you can
[Glen]
I think fox: should also be validated. It's, by
definition, part of FOP core, and can't be
added/adjusted to by anyone but us.
Yes. I agree.
regards,
finn
Hi,
I didn't follow the discussion in the spring about command line -d and
commons-logging so I'm likely missing some important pieces, but I'm a
bit confused about the result.
If I attempt to render a fatally corrupt input fo file like:
fo:block/
, I get the expected SAXParseException
[Jeremias Maerki]
Question to everyone: We currently don't have a multi-threaded design
like Peter West's approach. Can anyone think of a reason that all the
FO-building and layouting process for one processing run may run within
more than one thread? I don't think threre is one if the SAX event
My preference would be to explicit pass the shared data (in this case
the FOEventHandler) to the classes that needs it. If the recursion Glen
discovered is deemed too slow, then store the FOEventHandler in an
instance field for each FONode.
[Jeremias]
My preference, too. But having too much in
[Glen]
Oh, when I meant alter the system I also meant
adding classes, using different classes, etc., i.e.,
some things need to be done beforehand to accomodate a
new element.
Come on! That leaves alter the system without any meaning. Recompiling
modified sources into a new fop.jar would IMO mean
Extension writers has to create a subclass of
AbstractLayoutManager (I
just use a LeafNodeLayoutManager) and an subclass of
Area. But that are
normal operations since there are subclasses of
those for each element
type. I must also add code to the renderer to handle
my area, but that
is
Glen
I think that the new validateChildNode() methods are too strict in
response to extension elements. My guess is that the validation should
only occur when one fo namespace element is added to another fo element.
For instance, Block.validateChildNode() doesn't allow any of my
extension
Simon Pepping wrote:
TextInfo derives that value from the value of the word-spacing
property.
That must be an error in the property handling by FOP.
Yes. I'll commit a fix for it tomorrow.
In
FOPropertyMapping 0pt is used as the default value. Apparently
normal should be the default value. I am
Glen Mazza wrote:
I still prefer my solution.
Ok, but please consider that it will then become somewhat more difficult
to add an alternative layout subsystem.
Right now I just have to replace AddLMVisitor (and the XXXLayoutManager
classes). As far as I understand your proposal, I would have to
[Glen Mazza]
I still prefer my solution.
Ok, but please consider that it will then become
somewhat more difficult
to add an alternative layout subsystem.
[Glen Mazza]
Layout subsystems are much rarer than people think, so
not that much a concern IMO. Keyword here is
somewhat more difficult--it's
Glen Mazza wrote:
Team,
While I'm implementing the validateChildNode()
methods, I would also like to work on removing the
AddLMVisitor visitor pattern[1], and revert to our
previous method of having the FO's themselves setup
the LayoutManagers via addLayoutManager(). (See here
[2][3][4] for
Glen Mazza wrote:
I'd like us to go ahead and make Simon Pepping our
newest FOP team member. He has provided steady ML
help and numerous patch contributions for the past few
months, and with the many layout patches that have
been coming in recently, we could certainly use his
continued help on
[Finn Bock]
I don't understand how you propose to solve any of this, but I hope it
would be Ok to commit the straight forward solution I propose.
[J.Pietschmann]
Whatever works. I just want to note that given the almost one-
to-one correspondence between FOs and LMs both in classes
If an expression reference another expression in a parent fo, the parent
fo expression must be evaluated against the LayoutContext that was in
effect for the parent fo and *not* against the child fo LayoutContext.
fo:block id=a border-start-width=10%
fo:block id=b border-start-width=inherit
[Peter B. West]
Finn,
When I apply your most recent patch (10366) against a cvs updated HEAD
tree and attempt to compile, I get the following:
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60:
After applying the patch (10366), the
[me]
If an expression reference another expression in a parent fo, the
parent fo expression must be evaluated against the LayoutContext that
was in effect for the parent fo and *not* against the child fo
LayoutContext.
fo:block id=a border-start-width=10%
fo:block id=b
If it is evaluated already where would the evaluated value be stored?
[J.Pietschmann]
The layout context for the child LM could be an appropriate place.
The resolved property values of the parents should be stored in the
layout context? I must be missing something here!
And then the value
[Simon Pepping]
I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)
I found a few things that
[J.Pietschmann]
The layout context has the actual IPD MinOptMax. There is no
inherent reason it should have a link to a parent context or the
property subsystem, it's only necessary to have a method to
resolve a property expression given a set of MinOptMax for
the various traits which can be used
Somehow, in our current design, the information must be stored in an
object that exists:
[J.Pietschmann]
IIRC that's what the layout context was meant for.
Perhaps, but I doubt it. If they was change to always get a reference to
the parent layout context when they are created, and if they had a
[Simon Pepping]
If in the re-use the layout would not change, the area tree could be
reused. OTOH, if the layout would change, e.g. because another
renderer would use a font with a different font metric, the layout
information in the FO tree cannot be reused.
The layout dimension that is stored
Perhaps, but I doubt it. If they was change to always get a reference to
the parent layout context when they are created, and if they had a
reference to the FObj, and if they was made available to the property
subsystem, then they could properly be used for it.
[J.Pietschmann]
The layout
[Simon Pepping]
Finn,
I see you also solved another problem, viz. that fo:layout-master-set
did not return a proper IPD.
Correct. There are, I'm certain, many more cases where the layout
managers does not yet set all the dimensions needed to resolve all the
different percentages.
However, I
[J.Pietschmann]
Hi all,
I get a nice Junit failure:
Testcase: testFO2PDFWithDOM took 0.23 sec
Caused an ERROR
loader constraints violated when linking org/w3c/dom/Node class
java.lang.LinkageError: loader constraints violated when linking
This seems to have something to do mixing Jars form
[EMAIL PROTECTED] wrote:
Index: fop.bat
===
-java -cp %LOCALCLASSPATH% org.apache.fop.apps.Fop %1 %2 %3 %4 %5 %6 %7 %8
+rem 'shift' removes %0 (i.e., the fop.bat filename)
+shift
+java -cp %LOCALCLASSPATH%
[Simon Pepping]
Quite a piece of work. I will try to understand it.
A small correction:
margin-[top,bottom]:
width of containing block, except for page context where it
^
height (I suppose).
Well, not according to the spec:
Hi,
I just uploaded a patch which add support for percentages and
calculations on percentages to bugzilla.
I don't think that the patch is quite right in its attempt to find the
correct base length to combine with the percentage. Some of my confusion
comes from the fact that I can't tell the
[Glen Mazza]
Another option, Finn, is to move all the Property
subclasses to fo.properties (even if they're alongside
the makers, nested or unnested), after thinking about
it, I think that will be a little bit clearer than
having them in the datatype package. Comments?
I like it. How does this
--- Finn Bock [EMAIL PROTECTED] wrote:
Does anyone know why we wrap the datatypes instances
in a property
instance? I think we could avoid the property
instance by having the
datatypes extends an AbstractProperty class which
implement a Property
interface:
public interface Property
[Glen Mazza]
I now understand what you're saying, and like the
simplification you're suggesting. The current naming
however, is probably preferable--the word Property
figures quite highly in the spec! Do you have a
problem remaining with it?
Not at all, it is just that I though it would be
Each of the typeType classes also implements the gettype methods
from Property so the layout must do exactly the same as it does now to
extract the right value:
propertyList.get(PR_INLINE_PROGRESSION_DIMENSION).
getLengthRange().getOptimum().getLength();
[Andreas L. Delmelle]
Glen Mazza wrote:
Well, instanceof is slower I believe, but better
self-commenting.
[J.Pietschmann]
Instanceof is exactly as fast as a simple function call
after warm-up.
That is not what I remembered, so I made a small test program and ran it
with 3 different versions of jdk:
[/d/fop]
[Andreas L. Delmelle]
snip /
public static void testInstanceOf(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x = prop.getString() != null;
}
}
public static void testCall(Prop prop) {
for (int i = ITERS; i = 0; i--) {
boolean x
file:///d:/java/REC-xsl/slice6.html#fo_external-graphic
[Andreas L. Delmelle]
(Off-topic: Finn, I don't think I have access to your d:-drive ;) )
I hope not :-0 . Sorry about that.
Yeah, if it make sense to add more groups of properties together (and it
seems that such a ipd,bpd pair make sense)
[Simon Pepping]
I have just catched up with the massive changes to the property
system. Allow me to share a few observations:
Thanks for your comments. How do you otherwise think it compares to the
previous generated property makers?
1. If I see correctly, PropertySets is not yet used.
Hi,
While I was trying to fix some warnings from 'javadoc' about missing
@see method references I discovered a suspicious construct in
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfListStyleNumber
where the signature of the
writeListPrefix(RtfList)
method is different from the signature
[Peter B. West]
Is HEAD supposed to be compiling?
Yes. I can compile it just fine from a fresh checkout.
I'm getting errors starting at datatypes/ColorType.java.
Which errors? Have you tried to do a ant clean first?
regards,
finn
Does anyone know why we wrap the datatypes instances
in a property
instance? I think we could avoid the property
instance by having the
datatypes extends an AbstractProperty class which
implement a Property
interface:
[Glen Mazza]
Could you explain why we have the datatypes instances
to begin
Hi,
After updating from CVS, it is most likely necessary to do an ant
clean to get rid of the old generated maker classes, before building.
I have not yet removed the properties.xsl file from CVS. I guess it
should be removed since it isn't used anymore.
I've found an argument for unnesting
I have not yet removed the properties.xsl file from CVS. I guess it
should be removed since it isn't used anymore.
[J.Pietschmann]
I think you could leave the file there for now.
Ok.
It should be
sufficient to inactivate the related task in the buildfile
(for example putting it in an XML
but instead I used the :ext: protocol and set CVS_RSH=ssh with cygwin,
just like I do for sourceforge. Would I get any benefit from using ssh
tunneling?
[Jeremias Maerki]
You don't have to establish the SSH connection everytime you do a CVS
operation. It's speedier.
Thanks, perhaps I'll give it
Hi,
I've received my account information and everything appears to work
fine. In the guides for setting up CVS there are several ways to set up
tunneling
http://jakarta.apache.org/site/cvsonwin32.html
but instead I used the :ext: protocol and set CVS_RSH=ssh with cygwin,
just like I do
Finn Bock wrote:
I would guess that doing ~6 string compares to navigate the binary
tree (with 148 color keywords) is slower than one string hash, ~1.2
int compares and one string compare. But I haven't measured it, so you
might be well be right. Many keyword sets for other properties
[Finn Bock]
You should perhaps also be aware that the values
in a static array gets
assigned to the array one element at a time. So
static int[] a = {
101,102,103,104,105,106,107,108 };
becomes in bytecodes:
Method static {}
0 bipush 8
2 newarray int
4 dup
5 iconst_0
[Glen Mazza
1 - 100 of 136 matches
Mail list logo
