Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Paving the on-ramp to Java

openjdk.org

Post reply on HN
Print view View original

141–150 of 156 posts

Re: Paving the on-ramp to Java

#141

Post by doctor_eval »

jmartrican wrote: post #77
doctor_eval wrote: post #54

Earlier quoted context omitted.

Java the language is fine, but Java has - or used to have? - so much idiomatic boilerplate - worst of all IMO was the ridiculous imperative to write getters and setters for every field, but there was also a plethora of very broad interfaces - all of which required all kinds of boilerplate and/or delegation to be able to use. Don’t even get me started on the frameworks. Maybe Java has changed in the last 5 years, but…

To your point, I started writing my POJOs without getters/setters. It felt like I was doing something wrong and the ghosts of senior devs I have worked with were looking down at me with shame.... "how could you". The worst part is that some libraries use getters as convention. e.g. Jackson (by default) uses getter methods to decide what to serialize.

Me too - I absolutely recommend using public member fields and not setters/getters! In 20 years of Java development I did not once benefit from all the extra fluff. Classic YAGNI.

I don’t recall having a problem with Jackson, maybe there is an option you can use? But it’s 5 years now since I used Java.

But my point of course was that this is idiomatic boilerplate you don’t find in other languages. Along with a bunch of other ceremony and nonsense like automatic dependency injection and reflection heavy frameworks that reduce mechanical effort by creating complex, invisible and abstract conceptual systems that require far more mental gymnastics than they save on typing. (I’m looking at you, JPA)

Re: Paving the on-ramp to Java

#142

Post by joshka »

usrusr wrote: post #36
joshka wrote: post #2

Another option is any classless java file is just a class with the same name as the file implementing Runnable. E.g. Foo.java println("foo") Becomes: class Foo implements Runnable { void run() { System.out.println("foo"); } } Then running java Foo.java instead just stubs a main() that looks like: class Main { void main() { new Foo().run(); } }

Instantly my mind wants to "javaify" it again, that is, generalizing it to some general case by involving qualified names: Instead of stubbornly implementing Runnable from those flat files, mix in the well-established concept of single-function-interfaces (Runnable is just one of many) and introduce a top-level "extends" that makes the file body an SFI implementation: extends java.lang.Runnable; java.lang.System.out.…

Yeah, I hadn't quite figured how you'd mix this such that the arguments are passed by convention, so your point about single function interfaces is a good one there.

BTW, I think the pedantic view on this based on the (mailing list discussion) is that it becomes java.lang.StaticImports.println("Hello"), which calls System.out.println.

Re: Paving the on-ramp to Java

#143

Post by joshka »

ajnin wrote: post #108
joshka wrote: post #2

Another option is any classless java file is just a class with the same name as the file implementing Runnable. E.g. Foo.java println("foo") Becomes: class Foo implements Runnable { void run() { System.out.println("foo"); } } Then running java Foo.java instead just stubs a main() that looks like: class Main { void main() { new Foo().run(); } }

You'd be limited very quickly since Java does not have local methods. This would work for only very simple scripts that fit in a single method.

The context of this is entirely what is the lowest amount of ceremony that we need in order to reduce the teaching overhead of a java program. This really comes down to simple first up, with easy exits towards more complex. That very much looks like to me:

1. Single file single function imperative

2. Single file multi-function imperative (introduce multiple functions)

3. OO (introduce classes etc)

Re: Paving the on-ramp to Java

#145

Post by pabl0rg »

sideeffffect wrote: post #130
pabl0rg wrote: post #41

When i read the title, I thought they were finally going to fix gradle or improve maven. Those are the real on-ramps and they are a much bigger barrier to entry than main(). A cleaner/simpler alternative was Kobalt, but it’s now abandoned. A simple, official build tool would make the ecosystem easier to learn. https://github.com/cbeust/kobalt

Maybe you will appreciate https://github.com/sormuras/bach/ ?

Thanks! That is very interesting.

They’ve had great tools along these lines in the Clojure world where the repl/shell has been around longer (deps.edn+repl and boot).

Re: Paving the on-ramp to Java

#146

Post by absove »

brnt wrote: post #144

Is there a good resource for learning modern Java?

There's a new version of Head First Java that came out this year, I expect it's reasonably up to date wrt modern language features. I haven't read it personally but it's frequently recommended.

At a more intermediate level Effective Java 3rd edition is a must read.

Re: Paving the on-ramp to Java

#147

Post by cies »

pron wrote: post #124
cies wrote: post #114

Earlier quoted context omitted.

> Is Kotlin the only other language they know? On the JVM: I'd say yes. Scala, Groovy, Jython, JRuby, and what not came and went. I'd say Clojure is the third, and it take a nice place in the design space. But Kotlin to me is so close to Java that it is basically Java 2.0: the Java that Java cannot be due to intended organizational slowness. > Python is one of Java's main competitors, and when it comes to teaching a…

> the Java that Java cannot be due to intended organizational slowness. When Java was created in the '90s, James Gosling said that it is intended to be a slow-evolving conservative language that will only pick features from other languages once they have been sufficiently proven to be worth it. We try to live up to that goal and be a last-mover. It's not organisational slowness but conservatism in design that has wor…

> I'd say Kotlin was Java 2.0 ten to five years ago, but now it's a language that's going in a different direction from Java's.

Maybe it is, maybe it is not... We all do not know the future.

> Java will never adopt many if not most of the features Kotlin has, because most features never prove themselves as particularly beneficial over time

So what. I care (as said before) for the implicit nulls problem. Also, I dont like to my code to be littered with annotations (to introduce magic) and exceptions-as-alternative-return-values.

Re: Paving the on-ramp to Java

#148

Post by grodriguez100 »

mcculley wrote: post #105
Noe2097 wrote: post #44

Earlier quoted context omitted.

Couldn't agree more. Recently I tried another take on the same idea: using default methods in Interfaces. It has nice properties, as it enables ~mixins in a way not dissimilar to what Scala provides, and enables overriding (e.g. for tests). Give it a try, it's ... refreshing :)

I am also getting a lot of value from default methods in interfaces. Java really could benefit from a new syntax on top of the modern VM that favors immutability.

Like… kotlin?

Re: Paving the on-ramp to Java

#149

Post by mcculley »

grodriguez100 wrote: post #148
mcculley wrote: post #105

Earlier quoted context omitted.

I am also getting a lot of value from default methods in interfaces. Java really could benefit from a new syntax on top of the modern VM that favors immutability.

Like… kotlin?

Like Kotlin, but Kotlin also makes a lot of compromises to accommodate Java’s warts.

Re: Paving the on-ramp to Java

#150

Post by barbarbar »

kaashif wrote: post #72
mcculley wrote: post #62

Earlier quoted context omitted.

Yes, I definitely meant in the mathematical sense. I would really like a way to express pure functions in Java. There would need to some way to mark objects as immutable at the language level.

I switched from being a C++ developer to Java a while back and the lack of const (i.e. immutability) annoys me. It annoys me even more than no-one seems to care about it much, and most think final is good enough - you can still mutate final objects. In C++ all references are final (in a Java sense) since they can't be reseated, but const actually gets you immutability (modulo const_cast). I just want everything to be…

What about Records and immutable Collections, Sets, Maps? Isn't it possible to achieve what you want with that?
Post reply on HN