I agree. The problem with Java is its culture, which cannot be fixed by same thinking which created it.

And by culture I mean, java attracted people who think that lines of code are cheap and see nothing wrong with a 200 line class which has no actual behaviour beyond boilerplate. People who measure their output by the number of lines of code added per day, not the number of features added to a project per year.

Any "fixed" version of java needs to either bring those people along - and in the process import a lot of java's stale thinking. (Some corners of the C# world struggle with this). Or leave those people behind and build a new community around your new thing (eg Scala, Clojure). You can see this in the java community already - there are plenty of tools in the modern JVM for doing terse functional programming. But as far as I know that stuff remains unpopular. Why? My theory is that most of the people who really care about writing terse, efficient, maintainable code jumped to better languages years ago.

> 200 line class which has no actual behaviour beyond boilerplate

A skilled Java developer might make a huge POJO have every variable private and then implement getters and setters to control or monitor access to every member.

But then some noob straight outta college will look at that code, not understand why it's being done so 'stupidly', and just delete all the accessors and make every variable public, so you don't even need any getters/setters. Said noob will consider himself a superior programmer until he looks back on it 10 years later, with enough wisdom to see clearly.

Yikes! On behalf of everyone who doesn’t write Java for a living, 200 lines for a plain data object, full of trivial getters and setters everywhere is crazy. Code like that decimates your velocity because of how much effort it takes to refactor or add features to your project.

The noob’s instincts are right. Well written code in just about any other language doesn’t need all that crap. And for good reason - you can really feel the difference if you actually measure your performance programming, in the short term or the long term. And in either features/hour or features/line changed.

I worked at a place once which had this C# project which wrapped incoming http calls into calls to our internal backend (also http). Then it took the JSON from the backend and converted it to JSON for the browser. The code was 3500 lines full of that sort of POJO getter and setter crap. Every time we added a feature, this code needed to be updated. We had 2 people assigned full time to do those changes. After way too many meetings we managed to replace the whole thing with a few hundred lines of nodejs code. Those guys were moved into more useful roles - saving the company 2 full time salaries.

I probably have 1000s of plain getters and setters in my code, and I never typed ANY of them. lol. VSCode has a "Generate Getters and Setters" refactor function, and I can make them plain publics any time I want. So you can't blame the Java Language itself for their existence.

What a waste. C# has properties. If Java wasn't so against breaking forwards compatibility, Java could actually be a good language. It was good in 1995 but the changes since then have been too slow and too late.

About 1998 when Microsoft tried to invent their own "flavor" of Java, I lost all interest in the company, and that's right when I switched from a C++ developer to Java. C# was just another "copy" of the VM concept Java had, as you well know. Even if C# was superior under the hood (which it isn't) I still claim it just fragmented the industry and was just an example of a company creating their own proprietary stuff for their own self-serving reasons, and before you think you're correcting me, yes I know the CLR is supposed to be machine independent. When VBScript was finally yanked out of browsers the world celebrated.

I will openly admit however when VSCode came along and TypeScript I totally regained a new love for Microsoft, and they have redeemed themselves, also by accepting Linux into their dying OS.

The fact that you didn’t have to type them doesn’t make them free. Software spends most of its lifetime in maintenance. Those getters and setters have to be documented, adjusted, unit tested, code reviewed, deleted and renamed, and scrolled past.

Typing is easy. It’s all that other stuff that I avoid by using better languages / better conventions.

That's why experienced Java devs generally try not to put any logic code in POJOs.

So you never generally even open those files unless you're expending the 5 seconds it takes to add a new prop. But as I said I could make each property use one line of code if I chose too...something like "String x;" just like all other languages.

Setters and getters are only popular in Java EE/Spring based environments (and it can be easily useful).

There is nothing in java that requires it per se, it’s just a design pattern/“standard” for some library to dynamically inspect objects. As for the amount of time it takes, I’m fairly sure that it takes less time to press alt+insert+select setters getters than it is to write anything, but to each there own. It’s not like people read source code from top to bottom.

Also, this decimates your velocity is just straight-up coming from an alternative world. How do you write code, are you copying something by typing?

I’m sorry to assume it, but I think you only know about java development from third-hand infos and it has nothing to do with reality. Fact is, Java is so huge that for every unreadable mess of a project, you get someone working on robot programming or something totally different with proper architectural decisions and the like. It is quite a bad take to assume it for the whole language.

> Setters and getters are only popular in Java EE/Spring based environments (and it can be easily useful).

I'd love to see stats on how common this stuff is amongst java programmers. I think its more popular than you think.

I agree that modern java has lots of modern tools to write reasonable code - like closures and functional primitives. But its very normal amongst java programmers to never use that stuff.

I worked as a professional interviewer for a year or so recently and interviewed 400+ programming candidates. One of the tasks was a 30 minute coding challenge - using the candidate's own computer and preferred language. A huge percentage of the java programmers, even under explicit time pressure, wasted time adding needless junk (like getters and setters or extraneous, pointless classes) to their code. Out of maybe 50 java programmers I think I only saw 1 or 2 java candidates use any of java's functional programming primitives (like map) to keep their code terse and clean. Most typed everything manually, and didn't know or didn't use their IDE's codegen features.

Is that the fault of java, the language? I don't know. As I said in another comment I think the problem is cultural. I don't really have a problem with java-the-language. But a large part of java-the-community seems blissfully content with mediocrity. I took java off my resume years ago because I don't want that kind of coworker.

> How do you write code, are you copying something by typing?

In the languages I use, copy+paste is never needed. Thats what the compiler is for, and things like rust's derive(Eq) macros.

> I’m sorry to assume it, but I think you only know about java development from third-hand infos and it has nothing to do with reality.

Nope. Eg:

https://github.com/apache/incubator-retired-wave/search?q=ge...

I think every sufficiently large community will have outliers (in both direction), and Java is huge. I have a similarly bad opinion on the average JavaScript developer (or basically every “average” developer), but it is the product of the business decisions behind projects (cheap, bad developers, with huge churn rate) more than fundamental technical one.

Nonetheless, I’m sorry for my previous overtly aggressive comments, it has no place here.

> I have a similarly bad opinion on the average JavaScript developer

I write a lot of javascript for a living, and you're not wrong[1]. I think the struggle javascript has is that an extremely high percentage of javascript programmers are pretty new to programming in general. So there's an awful lot of javascript code written by unsteady hands.

If javascript is a magnet for novices, java feels like a magnet language for middle aged with kids "programming is just a job for me" indifference. I feel contempt for that mindset - but to respond in kind to your apology, I think the contempt I feel is probably reflected fear / disgust at the idea of settling. To me programming still feels like casting magic spells. I think I'm terrified of that spark some day being extinguished.

[1] I check in on this issue every year or so and it never fails to delight and horrify in equal measure: https://github.com/ChainSafe/web3.js/issues/1178

I personally don't mind heated technical debates. It's unfortunate that there's so many SJW moderators hiding in their 'Safe Spaces' who think it's their job to terminate any arguments that arise. I guess they're always "on the hunt" and trigger happy.

We don’t write it, and we don’t read it, so it never needed to be there. Boilerplate is our arch-enemy, and I’m glad we have Groovy and Scala and Kotlin to attack it.

If it really bothers you, there is lombok. But I will tell you something, the complexity of most programs will require many lines of code that you simply can’t decrease anymore. Whether it is more by a tiny tiny factor doesn’t matter, over performance, observability and maintainability of a language - though being on the JVM, the mentioned languages can tick all of them (I’ve only written groovy with gradle, but due to the lack of typing, I though of it as more of a scripting language)

I use Java since first beta. These getters and setters are always looking awkward for me, unless they are part of a library API, so they are useful for providing backward compatibility, or they are lazy objects, or they are defined in an interface. In my own code, I avoid using them in POJO.

For example, I prefer

  public class LineOptions {
    public Color color = Color.BLACK;
    public int thickness = 1;
    ...
  }

  void drawLine(int sx, int sy, int tx, int ty, LineOptions options) { ... }

  ctx.drawLine(0,0, 100, 100, new LineOptions() {{ color=Color.RED; thickness=3; }});

IMHO, it is much simpler and easier than classic POJO + Builder patterns.

  public class LineOptions {
    private Color color = Color.BLACK;
    private int thickness = 1;
    ...
    public LineOptions() { }
    public LineOptions(Color color, int thickness, ...) {
      this.color = color;
      this.thickness = thickness;
      ...
    }
    public Color getColor() { return this.color; }
    public LineOptions setColor(Color color) { this.color = color; return this; }
    public Color getThickness() { return this.thickness; }
    public LineOptions setThickness(int thickness) { this.thickness = thickness; return this; }
    ...
  }
  
  ctx.drawLine(0,0, 100, 100, new LineOptions().setColor(Color.RED).setThickness(3));

or even more classic

  LineOptions opts = new LineOptions();
  opts.setColor(Color.RED);
  opts.setThickness(3);    
  ctx.drawLine(0,0, 100, 100, opts);

The Java languages gives you the choice of whether to use getters/setters or not. You added a good example. The main reason I love getters/setters is they are a 'hook' to add any code (like logging) if you want to detect when a variable is being read/written.

Isn't that exactly what is happening in Java land now?