Live data from Hacker News

Still using java? Lombok can make you more productive

projectlombok.org

11–20 of 36 posts

Re: Still using java? Lombok can make you more productive

#11
I was a little bit confused when the speaker kept referring to "yava" until I realized he meant "java".

Neat tool, but I really don't see this being that much of a time-saver over the built-in tools that Eclipse or Idea has for this.

In addition, using annotations to generate things like "cleanup" blocks around a stream seems dangerous in the long run to me - I don't like having any part of the flow of my code being handled by "magic".

Re: Still using java? Lombok can make you more productive

#12

I always disliked this way of using OOP. If you use data classes so much, why don't you make an actual DataClass and be done with it?

Because your code would be more difficult to read.

mountain.getLatitude() vs. dataClass.getDataElement("latitude");

It's the same reason I use XMLBeans (a schema-based codegen) for serializing/deserializing XML documents. Rather than writing mountainElement.getAttribute("latitude"), I can say mountain.getLatitude().

Re: Still using java? Lombok can make you more productive

#13
post #9

Earlier quoted context omitted.

How cavalier of you... never mind that there are many thousands of people who may not have a choice but to use Java. Anything that eases the pain of boilerplate is a good thing.

What are you talking about? Clojure is a lisp for java, written in java and itself, published as a jar.

And your point is? Because it is written in Java and packaged as a jar does nothing to convince my boss and team members that we should write all of our code in Clojure. I wish it were that easy.

Re: Still using java? Lombok can make you more productive

#14

I was a little bit confused when the speaker kept referring to "yava" until I realized he meant "java". Neat tool, but I really don't see this being that much of a time-saver over the built-in tools that Eclipse or Idea has for this. In addition, using annotations to generate things like "cleanup" blocks around a stream seems dangerous in the long run to me - I don't like having any part of the flow of my code being…

>I really don't see this being that much of a time-saver

I don't either, but I do agree with his argument that it will make code more readable. And, w.r.t. the auto-finally block thingy, badly implemented exception handling is a common cause of error in "maintenance mode" codebases. [Yes, code reviews SHOULD happen, etc.]

Re: Still using java? Lombok can make you more productive

#15

I was a little bit confused when the speaker kept referring to "yava" until I realized he meant "java". Neat tool, but I really don't see this being that much of a time-saver over the built-in tools that Eclipse or Idea has for this. In addition, using annotations to generate things like "cleanup" blocks around a stream seems dangerous in the long run to me - I don't like having any part of the flow of my code being…

>I really don't see this being that much of a time-saver I don't either, but I do agree with his argument that it will make code more readable. And, w.r.t. the auto-finally block thingy, badly implemented exception handling is a common cause of error in "maintenance mode" codebases. [Yes, code reviews SHOULD happen, etc.]

I think I feel the opposite - that this might make the code a little less readable, unless you know exactly what @Closeable (or whatever it's name was) does. But, to each his own...

Re: Still using java? Lombok can make you more productive

#16

I always disliked this way of using OOP. If you use data classes so much, why don't you make an actual DataClass and be done with it?

Because your code would be more difficult to read. mountain.getLatitude() vs. dataClass.getDataElement("latitude"); It's the same reason I use XMLBeans (a schema-based codegen) for serializing/deserializing XML documents. Rather than writing mountainElement.getAttribute("latitude"), I can say mountain.getLatitude().

In this case it would probably be something like:

mountain.getDouble("latitude")

With at least two advantages: I'm pretty sure what getDouble will do, as opposed to getLatitude which may query google maps for all I know, and it can be processed in abstract ways. You can have operations which work on any structure: serialization, encription, logging, persistence, hash codes, sorting, raporting and a lot more.

Edit: It also makes for easier code reuse. You make something that works with mountains but could work just as well with houses, you don't have to play with class hierarchies to use it on both.

Re: Still using java? Lombok can make you more productive

#17
post #2

It's a cute idea, to use annotations to generate getters/setters etc, instead of generating source code (IDE style). A good strategy for any boilerplate that a particular project requires. Will other tools find this code? E.g. I think javadoc is source-based, and I don't know if it will invoke such annotations. I would expect the annotation spec to require it, for annotations that can create methods etc, but I'm just…

Why are we still programming in text? We spend so much time now with making fancy editors and IDEs that make souce code appear like hypertext. This shows that we have outgrown text. Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial? (Just for starters.)

Re: Still using java? Lombok can make you more productive

#18
post #2

It's a cute idea, to use annotations to generate getters/setters etc, instead of generating source code (IDE style). A good strategy for any boilerplate that a particular project requires. Will other tools find this code? E.g. I think javadoc is source-based, and I don't know if it will invoke such annotations. I would expect the annotation spec to require it, for annotations that can create methods etc, but I'm just…

Why are we still programming in text ? We spend so much time now with making fancy editors and IDEs that make souce code appear like hypertext. This shows that we have outgrown text. Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial? (Just for starters.)

I often wondered that myself, until I saw:

http://code.google.com/p/lambda4jdt/

It's quite an innovative idea. Just because the text is in java, why does it have to look like blub?

Re: Still using java? Lombok can make you more productive

#19

Earlier quoted context omitted.

Because your code would be more difficult to read. mountain.getLatitude() vs. dataClass.getDataElement("latitude"); It's the same reason I use XMLBeans (a schema-based codegen) for serializing/deserializing XML documents. Rather than writing mountainElement.getAttribute("latitude"), I can say mountain.getLatitude().

In this case it would probably be something like: mountain.getDouble("latitude") With at least two advantages: I'm pretty sure what getDouble will do, as opposed to getLatitude which may query google maps for all I know, and it can be processed in abstract ways. You can have operations which work on any structure: serialization, encription, logging, persistence, hash codes, sorting, raporting and a lot more. Edit: It…

If java has one thing going for it, it's the tooling. Refactoring, eclipses compile errors as you type + quick fixes etc are the only reason to stay in java.

If you program like you are suggesting you lose the only reason to use java, and have to enforce your code using unit tests in a verbose language. No thanks.

Re: Still using java? Lombok can make you more productive

#20
post #18

Earlier quoted context omitted.

Why are we still programming in text ? We spend so much time now with making fancy editors and IDEs that make souce code appear like hypertext. This shows that we have outgrown text. Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial? (Just for starters.)

I often wondered that myself, until I saw: http://code.google.com/p/lambda4jdt/ It's quite an innovative idea. Just because the text is in java, why does it have to look like blub?

That just supports my point. We could achieve the same functionality with a lot less code with source code with a bit more structure.
Post reply on HN