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

Java 12

jdk.java.net

Post reply on HN
Print view View original

451–460 of 478 posts

Re: Java 12

#451

Post by ptx »

olavgg wrote: post #400
spricket wrote: post #233

Earlier quoted context omitted.

No idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH. Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy

Groovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension

What makes Groovy unsuitable as a replacement for Java, if the performance is now comparable?

Re: Java 12

#452

Post by lmm »

jimbokun wrote: post #427
lmm wrote: post #349

Earlier quoted context omitted.

> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. There was definitely an era of that, but over the past decade or so it's been acknowledged as a problem, and there's been a lot of effort put into making things simpler and more vanilla. Modern Spring is much much closer to plain old code. (Of cours…

"Modern Spring is much much closer to plain old code." Modern Spring, as far as I can tell, is still very much driven outside of Java code, it's just migrated from XML to annotations and yaml properties files. Seems almost like the typical Spring application has more lines of annotations and properties files than lines of Java code. I am fond of Maven, though, especially with Gradle (superior to pom files).

> Modern Spring, as far as I can tell, is still very much driven outside of Java code, it's just migrated from XML to annotations and yaml properties files.

Disagree; there's been a shift to using constructor injection over setter injection, which often obviates the need for Spring-specific lifecycle methods. So it's now much more common to have a service class that, while it may have Spring annotations on its constructor, can also be used in a first-class way in plain old Java, and e.g. doesn't use Spring for unit tests. If you're using Spring at all then part of your application wiring lives outside Java code almost by definition, but it's now more common to express wiring logic as e.g. an annotated Java method rather than encoded into XML. It's not a complete departure, and it may not go as far as you or I would like, but I do think there's been a real cultural shift.

> especially with Gradle (superior to pom files).

It really isn't. Arbitrary unmanaged code in the build definition is great for writing but terrible for maintainability.

Re: Java 12

#453

Post by stewbrew »

coldtea wrote: post #385
pjmlp wrote: post #351

Earlier quoted context omitted.

What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Still not able to use several of Android Studio features available to Java, like incremental compilation and slim APKs? Kotlin advocates seem to forget JVM will never be rewritten in Kotlin, the language is just yet another guest, with the usual syndrome to wrap existing libraries, having to take care about FFI for Java acc…

> What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Seeing that both Eclipse and Netbeans are now more or less dead (and speaking as a long time Eclipse user, from the very first version to around 4), yes, first class vendor-direct InteliJ support is more than enough. And more than most languages (including Groovy) ever had. > As for Kotlin/Native, there is nothing to worr…

"InteliJ support is more than enough"

That won't get kotlin more traction. No proper/official tools for LSP support means no vscode, vim, emacs etc. users. As a happy eclipse user, I wouldn't call it dead either.

Re: Java 12

#454

Post by vorg »

olavgg wrote: post #407
pjmlp wrote: post #401

Earlier quoted context omitted.

More popular where? Had it not been for Google's adoption of Gradle for Android and it would have been left for Grails maintenance projects. And even then, the pressure for perfomance has been so much that it is being superceded by a Kotlin based DSL. How to improve Gradle has been a common talk at every Android conference since Android Studio has been introduced.

Everywhere? Google Trends says Groovy is just as popular as it was 10 years ago. The number of downloads has increased significantly but it is not because of Gradle, as Gradle bundles Groovy. It is also currently placed #16. on TIOBE Index And last, Groovy with compile static is in most cases, just as fast and memory efficient as Java. Some people always talk down Groovy, yet the numbers speak for them self. Before K…

> Some people always talk down Groovy, yet the numbers speak for them self

Many of those numbers are fake. Groovy was #70 on the Tiobe index only 12 months ago, see [1], but is #16 now. How do you explain that? Groovy was last in Tiobe's top 20 about 2 years ago when the search numbers for "Groovy" from Baidu were hugely incorrect. Groovy later quickly dropped back out of the top 50.

[1] https://www.tiobe.com/tiobe-index/groovy/

Re: Java 12

#455

Post by ivan_gammel »

ptx wrote: post #447
tannhaeuser wrote: post #432

Earlier quoted context omitted.

Exactly. For example, if you're (still) using Spring MVC, what gets called in your backend on a given action attribute in your JSP or Thymeleaf or whatever template, is expressed through your method signature and lots of annotations where the order of arguments matter eg. some magic attributes must come right after others. All you see in your debugger, though, is that your request hangs in some nested and chained han…

Another related surprising thing (as I'm currently learning Spring/Hibernate/etc.) is what happens when the Hibernate Validator library is missing at runtime: Nothing. All the carefully crafted validation annotations just don't do anything, no validation is performed, and there is no indication whatsoever of this.

It’s not a problem with annotations or Spring - could happen e.g. with SPI and anything that’s discovered in runtime. It’s about how you build your project and configure dependencies (separation of API and implementation in different JARs is typical for Java and implies certain way of thought about build and deployment).

Re: Java 12

#456

Post by ivan_gammel »

jimbokun wrote: post #438
ivan_gammel wrote: post #436

Earlier quoted context omitted.

Newbie can write bad code on any platform, but it‘s a short period of life of software developer - the problem of beginners is solved not by the tools they use, but through a reasonable composition of the team with sufficient number of experienced developers who can define the architecture and best practices.

From what I can tell, the "bad" Spring code is the code following the recommended Best Practices, at least according to the tutorials that pop up in Google search results.

There’s one “must read” tutorial - documentation on official Spring website. There’s also github account with lots of examples. It’s better to ignore the trash that comes from search results, because either it’s trivial or obsolete.

Re: Java 12

#457

Post by ivan_gammel »

jimbokun wrote: post #437
ivan_gammel wrote: post #435

Earlier quoted context omitted.

The source code of Spring itself. I know Spring internals - there’s no dark magic there and reference guide describes it well. DI is straightforward, MVC - not perfect, but generally easy, Security - well, it has design problems, but they are not related to annotations.

"but they are not related to annotations" I had a problem with security that I could only solve by adding an "Order" annotation to my class. Reading the code and stepping through it in the debugger did me absolutely no good.

So, annotation was a solution to a problem (how to define a sequence in which configuration is applied), not a cause, right?

Re: Java 12

#458

Post by jholman »

int_19h wrote: post #270
ilovecaching wrote: post #182

Earlier quoted context omitted.

Please elaborate on how OO is fine. OO hides state, which makes reasoning about cache, and therefore performance very difficult, which is why most game programers take a data oriented approach. It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Inheritance isn’t an abstraction because you inherit both code an…

> It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language. > Pretty much all of the OO languages are walking back OO features About the only feature I…

Minor question: what does the word "penultimate" mean in your comment?

Re: Java 12

#459

Post by hyperpallium »

aardvark179 wrote: post #375
hyperpallium wrote: post #264

Earlier quoted context omitted.

My comment's a little out of place. I'm not against pattern matching, but for double dispatch; we can have both. Their initial motivating examples was bare instanceof , but I now see they extend it. How would destructuring fit this model ?!

Brian Goetz has writes quite a bit about ongoing projects. The latest article he has done about pattern matching is I think http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.h... . There is a load of stuff in there about destructuring patterns from about half way down.

Thanks, a methodical article! Not keen on special support required for destructuring. Nice that they discuss Visitor pattern (and the switch example for such cases looks nice). They don't dicuss double dispatch - but not relevant to them.

Re: Java 12

#460

Post by coldtea »

ptx wrote: post #449
coldtea wrote: post #380

Earlier quoted context omitted.

> java is a stable api but it also doesn't evolve You have probably missed the last 5 years. From streams, to closures, to default methods, to functional interfaces, to local type inference, to new Process APIs, to modules, to unsigned arithmetic, to new date/time APIs, http client, 2 new GCs, shell REPL, etc... with more to come, and new releases every 3 months...

> unsigned arithmetic I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)? Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types. [0] https:…

>I thought I had missed something there, but it looks like it's just a bunch of utility methods to reinterpret integers and convert them to longs (etc.)?

Yes, but it's also a new feature (along with dozens of others). The complaint I answered was that Java is stagnant somehow, when it has been evolving fast in the last 5 years, and is accelerating its pace (release cadenze) even more.

>Kotlin, on the other hand, recently added actual unsigned types[0] – taking up the same number of bits as the corresponding signed type, supporting the normal mathematical operators, and preventing unintended mixups with signed types.

Which, given that the JVM doesn't support them at the bytecode level (iirc), they also use some similar trick of working with signed numbers under the hood, just hide it better at the syntax level.

Post reply on HN