<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Sep 10, 2014, at 2:41 PM, Vitaly Davidovich <<a href="mailto:vitalyd@gmail.com">vitalyd@gmail.com</a>> wrote:</div><blockquote type="cite"><p dir="ltr">One thing that bothers me is that even fields marked final aren't really treated as such by compiler because it's paranoid of things like reflection.  If there was some way to reassure it that final fields aren't modified behind its back, then more type info can be captured at init time (e.g. array is not null and length is captured as a constant).</p><div><br></div></blockquote></div><div><br></div><div>In general i agree.</div><div><br></div><div>However, in the particular cases i am looking at, an array field is unlikely to be final since it can be updated with a larger array (e.g. the node table in HashMap or the task queue in ForkJoinPool.WorkQueue), and it's about somehow conveying/expressing the constraint that the array length is always > 0.</div><div><br></div><div>Paul.</div></body></html>