Meta tags:
description=While all three remove boilerplate, the similarities don t go much further. Records have stronger semantics with important downstream benefits, which makes them better*. (* not always; depends on circumstances; excuse the clickbait);

Headings (most frequently used words):

why, are, better, data, records, lombok, kotlin, classes, java, than, and, record, semantics, worse, reflection, transparency, restrictions, math, sorry, consequences, destructuring, patterns, with, blocks, serialization, also, the, boilerplate, value, is,

Text of the page (most frequently used words):
the (100), and (60), that (58), java (49), records (40), data (36), you (36), can (33), are (32), int (32), with (31), range (25), for (22), record (21), low (21), why (20), #classes (19), class (18), this (18), #better (17), kotlin (17), high (17), all (16), but (15), project (15), not (14), state (14), type (14), pair (14), lombok (13), semantics (12), there (12), more (12), their (12), return (12), set (12), have (10), which (10), them (10), boilerplate (10), constructor (10), get (9), because (9), components (9), from (9), about (9), than (8), doesn (8), what (8), your (8), value (8), don (8), code (8), need (8), also (8), they (7), reflection (7), its (7), use (7), benefits (7), accessors (7), values (7), final (7), canonical (7), api (7), private (7), see (6), then (6), means (6), same (6), second (6), well (6), create (6), functions (6), change (6), product (6), serialization (6), patterns (6), theory (6), public (6), features (5), design (5), much (5), transparent (5), some (5), exactly (5), hidden (5), compiler (5), even (5), how (5), turn (5), way (5), really (5), new (5), immutable (5), transparency (5), hence (5), types (5), model (5), first (5), junit (5), language (4), look (4), worse (4), other (4), two (4), like (4), would (4), component (4), just (4), says (4), tuples (4), both (4), say (4), semantic (4), tools (4), here (4), destructuring (4), additional (4), fields (4), inheritance (4), structure (4), back (4), instance (4), into (4), take (4), blocks (4), apply (4), jep (4), accessible (4), operands (4), increment (4), these (4), math (4), sorry (4), whole (4), restrictions (4), core (4), community (4), license (3), full (3), next (3), course (3), while (3), space (3), possible (3), does (3), jvmrecord (3), guarantees (3), out (3), too (3), thought (3), note (3), didn (3), different (3), functionality (3), any (3), generates (3), allow (3), requires (3), platforms (3), apart (3), works (3), structured (3), very (3), newrange (3), instances (3), could (3), will (3), pattern (3), matching (3), want (3), cool (3), things (3), must (3), carriers (3), consequences (3), name (3), 395 (3), calls (3), needed (3), bijective (3), integer (3), call (3), know (3), sets (3), null (3), amber (3), when (3), documentation (3), override (3), follow (3), share (3), post (3), pioneer (3), demos (3), streams (3), clean (3), privacy (2), rss (2), stackoverflow (2), github (2), twitch (2), youtube (2), discord (2), mastodon (2), bluesky (2), trade (2), off (2), between (2), freedom (2), one (2), potential (2), over (2), years (2), aren (2), similar (2), strong (2), mathematical (2), otherwise (2), generally (2), generating (2), read (2), declaring (2), jvm (2), exist (2), has (2), understand (2), regular (2), check (2), paraphrasing (2), had (2), only (2), before (2), write (2), comments (2), around (2), those (2), har (2), make (2), weak (2), pretty (2), offer (2), building (2), build (2), often (2), whose (2), purpose (2), such (2), said (2), using (2), relies (2), great (2), either (2), come (2), stronger (2), may (2), generate (2), methods (2), future (2), add (2), via (2), shouldn (2), though (2), might (2), good (2), natural (2), consequence (2), algebraic (2), tostring (2), implementation (2), welcome (2), immediately (2), hashcode (2), equals (2), lot (2), changed (2), document (2), together (2), makes (2), being (2), variables (2), precisely (2), easy (2), something (2), sure (2), nothing (2), further (2), without (2), work (2), where (2), example (2), nominal (2), above (2), true (2), few (2), couldn (2), similarly (2), takes (2), applyasint (2), function (2), operate (2), single (2), operand (2), each (2), called (2), now (2), let (2), fancy (2), string (2), words (2), gets (2), reduction (2), downstream (2), val (2), getclass (2), active (2), various (2), watch (2), notified (2), publish (2), content (2), rant (2), talks (2), libfx (2), args (2), var (2), year (2), techniques (2), switch (2), valhalla (2), panama (2), loom (2), leyden (2), performance (2), optional (2), ramp (2), migration (2), meta (2), maven (2), libraries (2), lambda (2), javafx (2), basics (2), j_ms (2), generics (2), dop (2), deprecation (2), libs (2), collections (2), architecture (2), tags (2), javascript (2), contact, imprint, developer, power, happy, forward, unfolding, others, scala, case, firm, foundation, limiting, our, enable, powerful, least, reliable, attribute, info, later, framework, relying, introspect, migrating, existing, preserving, abi, besides, cases, interoperability, proposal, abide, rules, still, concept, freedoms, worst, worlds, readers, been, pointing, big, gotcha, mate, ask, stop, mull, barely, keyboards, angry, yet, judgement, costs, sense, fine, kids, holding, focus, deriving, indeed, mutable, unlike, extended, own, method, hand, give, quite, top, copy, main, hold, standard, utility, mechanically, derivable, docs, advertise, heavily, apis, internal, time, projects, break, minor, update, goes, users, isn, hide, technical, debt, lengths, attaches, attached, adapt, requirements, although, able, looking, instead, end, prevented, restrict, discussed, rename, probably, reassigning, backing, implement, interfaces, since, throws, measure, save, writing, explicitly, kinda, nice, proper, going, explained, earlier, following, many, audio, prefer, short, wrote, twitter, thread, spotify, inside, podcast, episode, byte, stream, json, xml, external, representation, again, put, expose, straightforward, feature, far, reality, considerably, dropped, pass, execute, block, declare, assign, derive, expressions, aligned, declaration, rely, except, failed, transport, syntax, made, version, introduce, copies, usually, thanks, miss, difference, returned, flipped, instanceof, proposes, array, enhance, capabilities, arrays, checks, 405, most, revolve, fact, recreate, manner, loss, information, names, should, careful, overriding, drive, point, home, construction, beyond, form, hardly, definitely, little, explain, embedding, projection, identified, mix, access, index, get1, actually, alluded, tuple, did, individual, direction, arguments, reconstitute, incrementpair, unaryoperator, proof, consideration, combining, yields, min_value, max_value, intunaryoperator, given, kinds, applying, products, aspect, combined, properties, etc, remain, intact, injective, corresponding, bit, insight, specifically, combination, written, pairs, integers, yes, simple, terribly, incomplete, legal, branch, logic, studies, related, academic, study, systems, likewise, wikipedia, bunch, elements, colors, numbers, finite, typically, throw, infinite, strings, plus, 2147483647, 2147483648, blue, gold, allows, term, strict, answer, primary, parameters, hiding, elsewhere, parameter, list, matches, accessor, returns, live, models, closer, motto, harsh, anyways, maybe, lured, promise, think, equivalent, muddying, chances, bite, creating, telling, colleagues, wide, world, shallowly, transparently, everything, else, follows, act, unfortunately, easily, lost, obvious, sexy, demonstrate, exposure, help, angle, explains, due, scope, naturally, vague, comes, describing, down, official, essentially, right, familiar, depending, needs, lines, hight, line, hash, objects, false, object, boolean, gethigh, getlow, seen, examples, blown, pojo, toc, table, contents, lic, artist, dev, source, src, three, remove, similarities, important, always, depends, circumstances, excuse, clickbait, 2021, slides, upcoming, past, schedule, recordings, virtual, threads, vector, concurrency, lilliput, galahad, babylon, openjdk, conversation, book, club, videos, jms, newsletter, blog, posts, testing, jigsaw, jdeps, impulse, default, lang, review, site, enabled, nipafx,

Text of the page (random words):
ject amber project babylon project galahad project leyden project lilliput project loom project panama project valhalla records reflection serialization streams structured concurrency switch techniques tools turn of the year var vector virtual threads recordings streams schedule code demos demos demos junit pioneer record args libfx talks my talks past upcoming slides about about me license privacy 2021 05 05 why java s records are better than lombok s data and kotlin s data classes post java 16 records rant while all three remove boilerplate the similarities don t go much further records have stronger semantics with important downstream benefits which makes them better not always depends on circumstances excuse the clickbait src source dev artist lic license why java s records are better than lombok s data and kotlin s data classes table of contents record semantics transparency restrictions math sorry consequences why records are better destructuring patterns with blocks serialization also the boilerplate why records are worse why lombok s data value is better why kotlin s data classes are better reflection share follow share this post with your community i m active on various platforms watch this space or follow me there to get notified when i publish new content toc record semantics transparency restrictions math sorry consequences why records are better destructuring patterns with blocks serialization also the boilerplate why records are worse why lombok s data value is better why kotlin s data classes are better reflection s f share this post with your community i m active on various platforms watch this space or follow me there to get notified when i publish new content i m sure by now you ve all seen the examples of how records turn a full blown pojo class range private final int low private final int high public range int low int high this low low this high high public int getlow return low public int gethigh return high override public boolean equals object o if this o return true if o null getclass o getclass return false range range range o return low range low high range high override public int hashcode return objects hash low high override public string tostring return low high into a single line of code these are components record range int low int hight of course lombok s data or value depending on your needs could do that for years with a few more lines data class range private final int low private final int high and if you re familiar with kotlin you know how data classes do the same data class range val low int val high int so these are essentially the same features right no no they re really not because for records boilerplate reduction is not the purpose it s just a welcome consequence of their semantics these are really not the same features unfortunately this gets easily lost the boilerplate reduction is obvious and sexy and easy to demonstrate so it gets a lot of exposure but the semantics and their benefits don t it doesn t help that the official documentation also takes the boilerplate angle and while jep 395 better explains the semantics due to its scope it s naturally vague when it comes to describing the downstream benefits so i thought i d write them down here first semantics then benefits record semantics jep 395 says records are transparent carriers for immutable data records are classes that act as transparent carriers for immutable data so by creating a record you re telling the compiler your colleagues the whole wide world that this type is about data more precisely data that s shallowly immutable and transparently accessible that s the core semantic everything else follows from here if this semantic doesn t apply to the type you want to create then you shouldn t create a record if you do it anyways maybe lured in by the promise of no boilerplate or because you think records are equivalent to data value or data classes you re muddying your design and chances are good that it will come back to bite you so don t sorry for the harsh words but it needed to be said transparency restrictions let s have a closer look at transparency records even have a motto for that paraphrasing a project amber design document the api for a record models the state the whole state and nothing but the state to live up to that some restrictions are needed an accessor for each component with the same name and return type that returns exactly the component s value or the api doesn t model the state an accessible constructor whose parameter list matches the components called canonical constructor or the api doesn t model the state no additional fields or the api doesn t model the whole state no class inheritance or the api doesn t model the whole state because more can be hiding elsewhere why though lombok allows additional fields and kotlin s data classes too as well as private components that s the record term kotlin calls them primary constructor parameters so why is java so strict about this to answer that we need some math math sorry a set is a bunch of elements e g we can say c is the set of all colors blue gold and n the set of all natural numbers 0 1 the finite set 2147483648 0 2147483647 is what we in java typically call int and if we throw in null we get integer similarly the infinite set of all possible strings plus null is what we call string so as you can see types are sets where the set s values are exactly the values that are legal for that type that also means that set theory the branch of mathematical logic that studies sets says wikipedia is related to type theory the academic study of type systems likewise which language design relies on types are sets now let s do something fancy and build pairs of integers yes that fancy 0 0 0 1 this is what a simple and terribly incomplete java class for that would look like class pair private final int first private final int second we could call the corresponding set pair and that would work but there s a bit more insight to be had because we know more about the set s structure specifically we know that it s the combination of all int s with all int s set theory calls that a product and it s written as int int each type in a product is called an operand that s pretty cool because set theory has all kinds of things to say about applying functions to these products one aspect of that is how functions that operate on a single operand can be combined to functions that operate on all operands and which properties of the functions injective bijective etc remain intact for example given bijective function from int to int intunaryoperator increment i i integer max_value integer min_value i then combining two increment s yields a bijective function this requires no additional proof or consideration unaryoperator pair incrementpair pair new pair increment applyasint pair first increment applyasint pair second did you note the accessors pair first and pair second they didn t exist in the class above so i need to add them otherwise i couldn t apply functions to individual components operands and so i couldn t really use pair as a pair of int s similarly but in the other direction i needed a constructor that takes both int s as arguments so i can reconstitute a pair more generally to apply set theory to a type in the way i alluded to above all its operands need to be accessible and there must be a way to turn a tuple of operands into an instance if both is true type theory calls such a type a product type and their instances tuples and there are a few cool things we can do with them actually records are even better than tuples jep 395 says records can be thought of as nominal tuples where nominal means that records are identified by their name and not their structure that way you can t mix up two different record types that both model int int for example pair int first int second and range int low int high also we access the record components not by index not range get1 but by name range low beyond that a record s accessors and its canonical constructor form an embedding projection pair but i hardly understand that definitely too little to explain consequences i want to drive the point home records want to be product types because of the cool things and for that to work all their components must be accessible i e there can be no hidden state and construction from them must be possible that s why records are transparent carriers of immutable data records are product types that s why they re transparent hence the compiler generates accessors hence we can t change their names or return type hence we should be very careful with overriding them hence the compiler generates a canonical constructor hence there can be no inheritance why records are better most benefits we get from the algebraic structure revolve around the fact that the accessors together with the canonical constructor allow to take apart and recreate record instances in a structured manner without loss of information destructuring patterns jep 405 proposes record and array patterns which will enhance java s pattern matching capabilities they will allow us to take records and arrays apart and apply further checks to their components if range instanceof range int low int high high low return new range high low thanks to full transparency we can be sure not to miss hidden state that means that the difference between range and the returned instance is exactly what you see low and high are flipped nothing more with blocks a future version of java may introduce with blocks that make it very easy to create copies of usually immutable instances with some values changed it could look something like this range range new range 5 10 syntax is made up range newrange range with low 0 range 5 10 newrange 0 10 the language can derive with expressions precisely because range s api is aligned with its declaration and similar to before we can rely on newrange being exactly like range except for low there can be no hidden state that we failed to transport and the language really doesn t have to do much here declare variables for components e g low high and assign values via accessors execute the with block pass the variables to the canonical constructor note that this feature is far from being a reality and might change considerably or even get dropped serialization to turn an instance into a byte stream a json or xml document or any other external representation and back again requires a way to take an instance apart into its values and then take those values and put them back together you can immediately see how this works really well with records not only do they expose all their state and offer a canonical constructor they do so in a structured way that makes the reflection api for that very straightforward to use for a lot more about how records changed serialization check out the inside java podcast episode 14 also on many audio platforms e g on spotify if you prefer a short read i wrote a twitter thread about it also the boilerplate going back to the boilerplate for a second as explained earlier we need the following code so a record can be a product type canonical constructor accessors no inheritance i didn t explicitly state that but it s kinda nice if 0 0 0 0 so a proper equals implementation is welcome as well which immediately requires a hashcode implementation since we need all that the compiler might as well generate it so it does and throws in tostring for good measure not so much to save us from writing it but because it s a natural consequence of the algebraic structure why records are worse records semantics restrict which class building tools you can use as discussed you can t add hidden state via additional fields can t rename accessors can t change their return type and probably shouldn t change their return value records also don t allow reassigning component values i e their backing fields are final and no class inheritance you can implement interfaces though so what if you need that then records aren t what you re looking for and you need to create a regular class instead even if that means that just to change 10 of the functionality you ll end up with 90 of the boilerplate that a record would ve prevented why lombok s data value is better lombok just generates code there s no semantic attached so you have all the freedom you need to adapt the class to your requirements of course you don t get the benefits that come from stronger guarantees either although lombok may be able to generate destructuring methods in the future lombok attaches no semantics that said i don t advertise using lombok it heavily relies on apis internal to the compiler which can change at any time and which means projects using it can break on any minor java update that it goes to great lengths to hide that technical debt from its users isn t great either why kotlin s data classes are better here s what the docs say about data classes you often create classes whose main purpose is to hold data in such classes some standard functionality and utility functions are often mechanically derivable from the data you can see that the semantic of holding data is there as well but it s pretty weak and the focus is on deriving functionality i e generating code indeed data classes offer more class building tools than records mutable components hidden state but unlike with lombok you can t use all of them can t be extended can t create your own copy method on the other hand data classes don t give records strong guarantees so kotlin can t quite build the same features on top of them data classes have weak semantics before you get your keyboards out to write angry comments which you can t because i didn t get around to have those yet har har this is no value judgement it s a different trade off with different costs and benefits and if kotlin s make more sense to you that s fine with me don t me as the kids say note readers have been pointing out kotlin s jvmrecord some as a big gotcha see data classes can be records too check mate i m paraphrasing but only barely if you had the same thought i ask you to stop and mull it over for a second what exactly does that get you the data class has to abide by all record rules which means it can t do more than records but kotlin still doesn t understand the concept of transparent tuples and can t do more with a jvmrecord data class than with a regular data class so you have records freedoms and data classes guarantees the worst of both worlds why does jvmrecord exist then just interoperability as the proposal says there s not much use in declaring jvm records in kotlin there s not much use in declaring jvm records in kotlin besides two use cases migrating an existing java record to kotlin and preserving its abi generating a record class attribute with record component info for a kotlin class to be read later by a potential framework relying on java reflection to introspect records reflection so of co...