<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Iosevka Fixed SS16";
panose-1:2 0 5 9 3 0 0 0 0 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
code
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Iosevka Fixed SS16";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">Thank you, Nir, for a thoughtful discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">It looks like whatever requirement that resulted in a lazy initialization is not applicable anymore, or perhaps some later code changes in CssStyleHelper changed the design
in such a way that the lazy initialization is no longer possible.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">The idea of using reflection or MethodHandlers.lookup().lookupClass().getSuperclass() is an interesting one. Would it work when reflection is disabled by the application?
The reflection is sometimes disabled using a custom SecurityManager, though its days might be numbered. Once SecurityManager is removed, will there be a way for an application developer to disable reflection?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">I do like the idea about annotations, but there is still some amount of code in
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">CssMetaData.isSettable(...) { ... property == null | !property.isBound() }<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">so I am not sure if a pure annotation-based solution is possible (I could be wrong).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">What do you think?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16""><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openjfx-dev <openjfx-dev-retn@openjdk.org> on behalf of Nir Lisker <nlisker@gmail.com><br>
<b>Date: </b>Friday, December 1, 2023 at 20:35<br>
<b>To: </b>John Hendrikx <john.hendrikx@gmail.com><br>
<b>Cc: </b>openjfx-dev@openjdk.org <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Re: CssMetaData.combine()<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">John answered already to most of the points, but I want to give my own insights as well.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16";color:#212121">Even though the syntax is ugly, the current implementation of the static getClassCssMetaData() is <i>nearly
perfect</i>, considering the lack of some kind of a 'lazy' keyword in java.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16";color:#D3CFCA">I don't buy Nir's argument about "questionable API". The API is codified by Node.getCssMetaData() and the current implementation will be perfect with the proposed
utility method </span><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Let's look at what implementation is required from a user who wants to write their own styleable control:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">1. Create styleable properties.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">2. Create a list of these properties to be passed on.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">3. Create a public static method that returns the concatenation of this list with the one of its parent. (This method happens to be poorly documented, as mstr said.)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">4. Create a public non-static method that calls the static method in a forced-override pattern because otherwise you will be calling the wrong static method. (This method's docs seem to be just wrong because
you don't always want to delegate to Node's list.)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">This is mostly redundant work with copy-paste and pitfalls, especially the need to manually specify the parent. I would say that this is a very cumbersome implementation that would not pass code review.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I'm not sure if users even need access to those styleable lists themselves, maybe for GUI builders/analyzers? Surely you don't need 2 methods that do the same thing, and both of those codify the API.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16";color:#212121">What the current code does is two things - a lazy initialization, meaning the code will get executed
only when needed, and it has zero per-instance overhead. I don't think anyone can suggest a better way of doing it.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I'm confused by the notion that this is important. We're talking about static data, that is, per class, not per instance. How many styleable classes do we intend to use in an application? 100? Are we talking
about saving 1KB of memory or 1 millisecond of runtime? *Per instance* is important, *per class* is negligible.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">And why is the need for laziness? John also mentioned that any displayed instance of a class will initialize these anyway (on first use). A benefit can only arise if we create an instance but don't show it,
in which case why did we create it?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Iosevka Fixed SS16";color:#212121">And I would be very much interested to hear from Nir his idea of an API that is not questionable.
I think we'll all benefit from learning how to make javafx better.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Are we stuck with the current behavior of steps 2 to 4 above, or can we circumvent it for future cases? Do we only deal with controls here, or skins also because (as mentioned by John and Michael) they can
also add styleable properties?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">If I had to touch the least amount of code, I would at least make the concatenating method auto-resolve the parent of the current class by calling `MethodHandles.lookup().lookupClass().getSuperclass()`, eliminating
that pitfall. Then we don't need the static method as far as I can see since its whole purpose was to allow this recursive concatenation (except in cases like ContextMenuContext that do something weird).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I think that a better overall approach could be with annotations on styleable properties and an annotation processor. It can have the following benefits:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">* Automatic access to the declared styleable properties.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">* Usable both in controls and in skins (or other classes).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">* Auto-generation of the css reference that is coupled with these.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">* Mention of the corresponding css attribute in their documentation (like I wanted previously
<a href="https://mail.openjdk.org/pipermail/openjfx-dev/2022-February/033482.html">
https://mail.openjdk.org/pipermail/openjfx-dev/2022-February/033482.html</a>).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">It will depend on what exactly we need to do with these properties.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">By the way, John<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="font-size:11.0pt">Lazy initialization in many places that IMHO is not needed<o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I noticed this for the first time in classes like Box, Sphere and Cylinder. Their dimension properties are lazily initialized, but are also initialized on construction, so I never understood what the point
was.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Fri, Dec 1, 2023 at 5:57 AM John Hendrikx <<a href="mailto:john.hendrikx@gmail.com" target="_blank">john.hendrikx@gmail.com</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p>Hi Andy,<o:p></o:p></p>
<p>Let me start to say that I had no problem with this PR being merged as I already agreed with one of the first versions.<o:p></o:p></p>
<p>Sometimes then on the same PR there can be some discussions on what else can be done in this area, potentially maybe even alleviating the need for the change (X/Y problem, ie. why do you need this method? Because you need to concatenate lists, but the underlying
reason is that the CSS property initialization is somewhat clumsy).<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 01/12/2023 01:11, Andy Goryachev wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt">Dear colleagues:<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt">there were a couple of comments after I withdrew <a href="https://github.com/openjdk/jfx/pull/1296" target="_blank" title="https://github.com/openjdk/jfx/pull/1296"><span style="color:#0078D7">https://github.com/openjdk/jfx/pull/1296</span></a>for
reasons of frustration, so I wanted to respond to those in the openjfx list.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt">> </span><span style="font-size:12.0pt;color:#212121">I pondered that back when I was working on replacing these static initializers with the </span><code><span style="font-size:12.0pt;color:#212121">.of</span></code><span style="font-size:12.0pt;color:#212121"> collection
variants. It doesn't work here for problem stated above - we need to modify an unmodifiable list, which is why I didn't touch them in that pass. While the proposed method is useful for eliminating some ugly syntax, cementing a questionable API with more a
public API doesn't seem to me like the right direction. If the method is made internal only, then that's fine. Alternatively, if the method is made useful outside of this specific context, then even if it won't be used here, it could be used in other places,
and that's also fine.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:12.0pt;color:#212121"> </span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt">Even though the syntax is ugly, the current implementation of the static getClassCssMetaData() is <i>nearly perfect</i>, considering the lack of some kind of a 'lazy' keyword in java.<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt">It may be "nearly perfect" from an optimization viewpoint, but it is clumsy and unwieldy for anyone wanting to implement CSS properties.<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt">What the current code does is two things - a lazy initialization, meaning the code will get executed only when needed, and it has zero per-instance overhead. I don't think anyone can suggest a better way of doing it.<o:p></o:p></span></p>
</div>
</blockquote>
<p>This was already mentioned on the PR, but I'll repeat it here: what is the lazy initialization for? As soon as these Nodes need to be shown, all the metadata will have been queried already. I don't see any benefit making them lazy so you can create Nodes
faster, as long as they are never shown.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt">I don't buy Nir's argument about "questionable API". The API is codified by Node.getCssMetaData() and the current implementation will be perfect with the proposed utility method (and maybe we can address some other comments from <a href="https://git.openjdk.org/jfx/pull/1293#discussion_r1411406802" target="_blank" title="https://git.openjdk.org/jfx/pull/1293#discussion_r1411406802"><span style="color:#0078D7">https://git.openjdk.org/jfx/pull/1293#discussion_r1411406802</span></a> ).<o:p></o:p></span></p>
</div>
</blockquote>
<p>How can there be any doubt that this API is questionable? It ignores a core feature of Java (inheritance) and moves this burden to the user by calling static methods of its direct parent... in order to implement CSS property **inheritance** -- it also burdens
any subclass with the caching of these properties (because "performance"), and to make those properties publicly (and statically) available so another subclass might "inherit" them.<o:p></o:p></p>
<p>The API is clumsy enough that I loathe creating stylable properties for the sheer amount of boilerplate that surrounds them.<o:p></o:p></p>
<p>Some alternatives have been suggested, but are shot down without thinking along to see if there might be something better possible here. Solutions where some of the common logic is moved to either Node or the CSS subsystem are certainly worth considering.<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="font-size:11.0pt">... a few bytes and cpu cycles would get saved ...<o:p></o:p></span></p>
</div>
</blockquote>
<p>This is not for you specifically, but JavaFX has a lot of "optimizations", some resulting in really questionable patterns that have/are hurting us:<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Reimplementing core collection classes for some benefit, but then only partially implementing them (and often buggy), and/or completely breaking the collection contract [BitSet]<o:p></o:p></span></p>
<p>- Lazy initialization in many places that IMHO is not needed (benchmark should be time to show window, anything accessed before that need not be lazy, and is likely counterproductive)<o:p></o:p></p>
<p>- Using plain arrays in many places, with a lot of custom code that's already available in some standard collection class or as a standard pattern; the custom code often has untested edge cases that contain bugs [ExpressionHelper]<o:p></o:p></p>
<p>- Making things mutable; surely mutating something must always be faster than having to create a new object? Except that if there's a lot of duplication going on because these objects are unshareable (because mutable), the cost/benefit is no longer so clear
(but try to prove that with a micro benchmark) [PseudoClassState / StyleClassSet]<o:p></o:p></p>
<p>- Also see many usages of LinkedList, a class that if you'd never use it, you'd be better off 99.999% of the time; use of that class should always be explained in a comment, and proven to be better with a benchmark [too many places to list]<o:p></o:p></p>
<p>The list goes on; many of the optimizations I've seen would make sense for C/C++, but not for Java. Now I don't mind some optimizations, but practically none of them are documented (deviating from the standard path always deserves an explanation for the
next developer) and I suspect they were never verified either. I've done extensive "optimization" before, with benchmarks, and you'd be surprised what is actually faster, and what makes no difference whatsoever -- even then, after benchmarking, if the difference
is small, it's best to use established patterns, as that's what the JDK optimizes for. What is marginally faster now, may not be faster on the next JDK, with a different GC, when run in a real application (caches will be used differently), or on a completely
different architecture.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">--John <o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>