The build script for the website has been updated to clean out the website build dir first, so files that used to exist but have now been tossed are no longer there.
There's also a special website-no-videos target which builds a website deployable without the videos. This makes the upload a lot faster if the videos haven't changed.
Also removed the [] brackets from the supercall, as, if you're chaining to another lombok-generated toString, those are superfluous - lombok's toString includes parentheses already.
now generates the warning on just that node (like with errors), and the API of AnnotationValues has been updated to support setting errors/warning on any node.
hitting 'find callers' on a @Data annotation should find callers of the (static) constructor.
Right now it'll find callers to the *static* constructor ONLY. Letting it find callers of the public constructor if there is no static constructor just doesn't work.
If boolean fields already start with a typical getter prefix (is, has, or get), lombok's @Getter will no longer generate its own prefix as well, so a field named 'hasFoo' will result in a getter named 'hasFoo()', not 'isHasFoo()'.
Also, if any likely getter name already exists for a boolean, a getter will not be generated. Thus, if your field is called 'hasFoo', and you already have a method named 'isFoo', then @Getter will not generate anything (and warn, unless the getter is being generated due to @Data).
This last mechanism works by taking the field name *AND* any other likely base names (defined by the field name being named as prefix+baseName, with prefix being is/has/get), and then prefixing all the likely fieldnames with is/has/get, and checking if any method with that name exists.
Of course, this means weird things are going to happen if you have 2 fields named 'isFoo' and 'hasFoo', but then, you'd be a real idiot if you did that.
Honestly, we haven't tested it! Also updated instructions on how to
build the 64-bit version of the JVM, and generalized some of the loading
aspects of the DLL, as we now need to potentially try 2 of them.
A) FSUTIL is internationalized, so on non-english installs, we can't figure out if a disk is fixed.
B) I trust this better than fsutil for user control access (a.k.a. popups from hell) on vista.
C) fsutil.exe is in C:\windows\system32 so pretty sure it would be there, but there's always a chance it's not in the PATH, or otherwise not accessible.
FF3.5 (video)
FF3.0 (flash, even if flash is at an ooold version)
Safari 4 (video)
IE6, 7, and 8
Opera10
Any flash version (or at least, 6 and up) should work, in that too old versions will show an upgrade-your-flash thingie. If javascript is on. Otherwise, well, you're screwed.
Reinier Zwitserloot