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

81–90 of 156 posts

Re: Paving the on-ramp to Java

#81

Post by exabrial »

I’m actually very happy to see this after using Java for many years. I definitely had all of the mentioned thoughts about the keywords, and not knowing what they do when first learning.

Java needs staunchly maintain its static type nature rather than move towards a ‘everything is a string/array whatever’. The concept of types are not only powerful, performant, but they are way to grasp conceptually because the Java semantics and compile time checking.

I do wish CDI (or SpringFramewotk) was brought into CS and similar degrees. Dependency Injection brings a large number of good habits to developers, but it is a concept that is hard to teach as an employer. In our onboarding program, we have to teach people about the CDI container (a program ruining your program) managing all of your state for you (to great benefit and speed of development). During this time, we’re not getting much value out of the developer, and the teacher is also away from their normal duties as well. :/

Re: Paving the on-ramp to Java

#82

Post by rhdunn »

pjmlp wrote: post #10
chrisseaton wrote: post #5

Earlier quoted context omitted.

Extra language specification rules that you need to be aware of for your whole career... in order to make the first 30 seconds easier when looking at hello-world for the first time.

As I mention on the sibbling comment, C# 10 already went through this. For me it seems like a reaction to JavaScripts and Pythons of this world, optimizing for Hello World just to win over them on those 30 seconds. They are going to rewrite their applications anyway, when performance comes knocking on the door.

It's also a reaction to languages like Kotlin that already have these and run on top of the JVM. With Kotlin these don't apply just to main. IIRC, other JVM languages have similar reductions in boiler-plate compared to Java.

Re: Paving the on-ramp to Java

#83

Post by albertopv »

pron wrote: post #59
cies wrote: post #21

Kotlin's syntax is cleaner in some most places, more explicit in some places (no implicit nulls, and wrt generics) and much terser when using naked functions etc. Did Java's papa get jealous?

I always find it funny when people bring up Kotlin in the context of Java's evolution. It's not one of Java's main competitors, and while Java has borrowed many features from other languages [1], to date it has not adopted a single feature from Kotlin [2]. In fact, almost at every turn -- from data classes, through async/await, to string interpolation (JEP 430) -- Java has opted for a different approach. Is Kotlin th…

Almost 10y with Java, now on Kotlin for everything new and not looking back.

Re: Paving the on-ramp to Java

#84

Post by pron »

RayVR wrote: post #53
kaba0 wrote: post #29

I always love seeing Brian Goetz’s articles, they explain the problem succinctly and they do a great job of validating their approach, showing the shortcomings of alternatives. I especially like the language team’s very conservative attitude, valuing backwards compatibility greatly. Here, they again solve most of the problem by simply changing the “program launcher” code, without any modifications/special casing done…

Succinctly? You must be a Java programmer. This essay is at least 3-4x longer than I’d like. As a (mostly) python and C++ programmer, Java feels like someone is afraid they’re speaking to an imbecile, so they constantly repeat themselves and over-explain every point.

Java has made progress in reducing unnecessary incantations, and it's not more verbose than C++. On the other hand, Java has probably been the most successful language in history in maintaining large codebases over years (although I guess some would say that's not a good thing).

Re: Paving the on-ramp to Java

#85

Post by cesarb »

jmartrican wrote: post #73
kubota wrote: post #67

Earlier quoted context omitted.

var ages = Map.of("sarah",19, "dan",35); //valid java

Map.of came out in JDK 9. I think there are still a lot of companies using JDK 8.... uhg. Maybe OP is one of the poor souls stuck in JDK 8.

For those of us still using Java 8, ImmutableMap.of() (from Guava) is similar (and probably the inspiration for Map.of()), as long as you don't need your Map to be modified later.

Re: Paving the on-ramp to Java

#86

Post by ascendantlogic »

chrisseaton wrote: post #14
Sakos wrote: post #11

Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being waste…

> Otherwise everybody complains about Java boilerplate. Do serious people actually complain about this often? I think it's more of a drive-by comment from people who don't like Java for whatever other reasons.

I wrote a lot of Java in the 2000's and the early 2010's. The verbosity of the language was always my #1 complaint. The amount of stuff I had to type vs the productivity of those lines was always out of whack. Maybe it's better now?

Re: Paving the on-ramp to Java

#87

Post by RockingGoodNite »

mcculley wrote: post #32

I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…

static should be removed from Java. static is bad, not always but because it can be misused and because it makes debugging more difficult and most important of all, it makes testing impossible and PowerMock is to be avoided at all costs.

Re: Paving the on-ramp to Java

#88

Post by pron »

albertopv wrote: post #83
pron wrote: post #59

Earlier quoted context omitted.

I always find it funny when people bring up Kotlin in the context of Java's evolution. It's not one of Java's main competitors, and while Java has borrowed many features from other languages [1], to date it has not adopted a single feature from Kotlin [2]. In fact, almost at every turn -- from data classes, through async/await, to string interpolation (JEP 430) -- Java has opted for a different approach. Is Kotlin th…

Almost 10y with Java, now on Kotlin for everything new and not looking back.

That's great, but for the past 15 years or so, the portion of people using the Java platform through other languages has neither increased nor decreased (around 10%). There's a segment of programmers who prefer more feature-rich languages than Java, or perhaps different programming paradigms, and we're happy to have the platform accommodate them.

Re: Paving the on-ramp to Java

#89

Post by mcculley »

salil999 wrote: post #70
mcculley wrote: post #32

I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…

> Having static fields and state is to be avoided. This is totally false. It will always depend on the use case.

State, while necessary, is the enemy of sanity. It should be kept to a minimum and be well marked as dangerous.

The change I would most like to see in a new Java syntax would be to make final and immutable the default. Force the programmer to make clear where state lives.

Re: Paving the on-ramp to Java

#90

Post by exabrial »

RayVR wrote: post #53
kaba0 wrote: post #29

I always love seeing Brian Goetz’s articles, they explain the problem succinctly and they do a great job of validating their approach, showing the shortcomings of alternatives. I especially like the language team’s very conservative attitude, valuing backwards compatibility greatly. Here, they again solve most of the problem by simply changing the “program launcher” code, without any modifications/special casing done…

Succinctly? You must be a Java programmer. This essay is at least 3-4x longer than I’d like. As a (mostly) python and C++ programmer, Java feels like someone is afraid they’re speaking to an imbecile, so they constantly repeat themselves and over-explain every point.

CDI and modern Java are both great, extraordinarily productive, run an order of magnitude faster than dynamic languages like python JavaScript and ruby, and are succinct compared to the mass of footprint of dynamic languages on a system. Your program runs at near c++ speed and does not need a gaggle of various system chances to run.

Jvm developers also take backwards compatibility seriously which is a concern for companies that will be around for more than a year or two.

While I reach for Python for one-off and random small stuff, the lack of types, it’s lack of performance, and the significant spacing make it challenging to share code and maintain.

Java certainly has its place and the changes in this article certainly expand its footprint.

Post reply on HN