I know, but with the JVM having full support, that might eventually change in Java 11 lets say, after the experience how everything went.

Brian did not state they will never do it.

Also the other languages could take advantage of it anyway, even a reiffied version of Java for example.

Good thing Kotlin already supports reified generics (with the current caveat that they must be used in inline functions), Java the language is less important these days than the JVM having support for the feature.

That was my reaction the first time I was introduced to it. I looked at it again two years later and it just clicked. What's really cool is that the developer who has to go maintain it has 20% as much code to maintain.

Say you want a POJO with accessors, mutators along with equals and hashcode. Let it generate the methods by defining a class like:

  @Data
  public class something {
    String name;
    int age;
  }

Lombok generates:

  public String getName() { ... }
  public void setName(String name) { ... }
  public int getAge() { ... }
  public void setAge(int age) { ... }
  public boolean equals(Something other) { ... }
  public int hashcode() { ... }
  public String toString() { ... }

I believe a similar argument could be made against using any 3rd party library. At some point who ever is maintaining your code will have to understand its dependencies at some level.

For lombok specifically, other languages have these types of features built in which of course people need to learn in order to use it.

I agree it isn't a perfect solution, but java is in dire need of boilerplate reduction features like this and lombok fills this need well.

Lombok is a bad idea, IMO.

Getters and Setters are verbose, but usually model classes are contained in a single class anyway, and can be generated automatically with any IDE. I can glance at a typical bean and ignore the code bloat without any problem.

The real issue is that Lombok generated classes don't play well with the dozens of libraries that expect Java bean style methods for auto marshaling and serialization: json generators, commons bean utils, binding libs, etc.

The savings aren't worth the trouble.

Are you attempting to separate the concepts of specialization vs reified generics? Java does neither right now, and both effects are due to type erasure -- the runtime simply doesn't have the necessary information. I'm not quite sure where you're trying to draw the line.

Furthermore, runtime specialization (as opposed to compile-time) would seem to require reified types. So that further confuses things. But you can definitely have reified types without specialization, which I think is the point that you are trying to convey.

Aside from backwards compatibility, what's good about type erasure for generics?

I think I see where you're coming on that. For most of my applications, I terminate TLS connections with nginx. I do use ChaCha for high-speed encryption in other areas, though. The BC libraries have always worked great for me.

Probably a rethink of the design. Why are you creating an object, then mutating its name from client code?

The whole point of an object is that client code shouldn't be concerned with such details as maintaining the state of each internal field. Try and think of an object as a single thing you send high level messages to you, instead of a struct, or a bag, or a hashtable.

Diameter is a nice example of a getter property. However you could change radius to simply

    public int Radius;

Thing is you don't really need to write getters and setters in modern Java.

They're quite a smell that you have no encapsulation, plus mutable state.

I find myself either

- Writing object oriented code with higher level operations that operate on data internally without exposing it via getters and setters.

or

- Value types that take values in constructor and provide naming and additional behaviour on that data (proper Value Types support will really help with this.)

or

- Data pipelines dealing with n-tuples. For which you might be tempted to reach for getters/setters but I'd tend to either use off the shelf tuple types. i.e. tuple(A,B,C) or classes with public fields, or interfaces with static factory to create instances. I'd love better support for tuples with named attributes (Like new c# has)

Loads of getters/setters is something that the frameworks of the last decade encouraged people to do but aren't really a thing any more.

Adding 8 comment lines doesn't help your argument. More importantly though, you need to consider the mental load of constantly thinking about and remembering whether something is a property or a method.

I used to be an advocate property syntax, but after seeing them used in C# and now in Swift I have completely changed my mind. It's an inconsistent mess that Java has avoided at the small price of some more lines of code (that are mostly auto generated and need no documentation)

And you forget the declaration of the field itself.

Compare with Kotlin:

    class MyFoo(val foo: Foo)

Done.

A compiler switch that makes trivial comments on accessor methods a compile error, now that would be something I could support!

Those Javadoc comments are useless. If you have useful comments, they would take up the same space even if the language supported properties.

Now you're left with something that could be fit on three lines (the "final" for the parameter is also useless and can be removed):

    public Foo getFoo() { return foo; }

    public void setFoo(Foo foo) { this.foo = foo; }

Even if you don't write the actual source like that, a good editor like IntelliJ can automatically display them like that (code folding).

The C# version is about the same length:

    public Foo Foo {
        get { return foo; }
        set { foo = value; }
    }

Also, you don't have to write the get/set methods yourself. You hit a few keys and your editor generates them.

Are people manually writing getters and setters? Every Java IDE I've used has the ability to generate them for you.

Or perhaps they know better than to release confidential information about their roadmap?

I believe Google is running out of solutions to further optimize Android because they keep running into self inflicted Java roadblocks. If Fuchsia is any indication of their future efforts their next major overhaul will support multiple first class languages.

Hey thanks ... .NET core is awesome too, they should check out http://www.steeltoe.io/ for our attempt to bring Spring love their way :p