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

351–360 of 478 posts

Re: Java 12

#351

Post by pjmlp »

ptx wrote: post #338
pjmlp wrote: post #315

Earlier quoted context omitted.

I am betting Kotlin is the new Groovy. Lets see where it stands 5 years from now, specially if Fuchsia actually gets released.

Kotlin is different because of the focus on tooling, which is the advantage Java still had over all the dynamically typed JVM languages. Also, Kotlin/Native is in beta now and could target Fuchsia (compiling AOT to native code using LLVM).

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 access, not having all features taking advatange of the latest bytecodes, e.g. lambdas implementation.

As for Kotlin/Native, there is nothing to worry about versus what Go, Rust, C++, Dart, D, Nim offer in terms of performance, libraries and in some cases tooling.

Having to buy CLion for a graphical debugger isn't a selling point versus the established alternatives.

Fuchsia is being written in Go, Rust, C++ and Dart, with the team now hiring for node.js support.

https://www.androidpolice.com/2019/03/19/google-working-to-b...

Re: Java 12

#352

Post by pjmlp »

tannhaeuser wrote: post #335
tannhaeuser wrote: post #330

Earlier quoted context omitted.

I have no doubt it's working for you and your customers. But JEE and JSRs have been a dead end for many years now. When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it? In 2006 I played around with Jackrabbit for an architecture concept (for managing airworthiness of airplanes and kit). That was before the Iphone even existed. I was honestly surpri…

Edit: Liferay is a portlets container isn't it? My experience is only with Websfear portal ( shudder ) but I think managing UI state on the server has had no reason to exist since at least 2008 when Chrome/V8 came out, and the massive JavaScript improvements of the last 10 years following it

Meanwhile JavaScript frameworks are all the hype rediscovering server side rendering to improve performance.

I have learned it pays off longterm to watch caravans pass by.

Pure HTML and CSS with minimal JavaScript rules rendering performance.

Re: Java 12

#353

Post by joostdevries »

paulddraper wrote: post #9
crooked-v wrote: post #4

Still nothing to handle checked exceptions in streams properly... sigh.

I share the conclusion of the other statically typed JVM languages (Scala, Kotlin): checked exceptions are bad.

I find checked exceptions interesting. They happen to be the only example of an effect system in a mainstream language. Anders Hejlsberg formulated the main argument against them here [1] Basically the problem is that checked exceptions are infectious and intermediary code needs to annotate all the exceptions of code that it calls. Which is a chore. Lucas Rytz states in his PhD thesis [2] that the problem is not wich checked exceptions themselves, but that in the java implementation 'not mentioning an exception means if won't happen'. He proposes a system where the default is 'any exception' and being able to turn it off with a compiler flag. And states that the developer experience of that would be much better. This may become possible in Dotty Scala using the effect system based on implicit functions. But that's in 'proposed' status.

[1]https://www.artima.com/intv/handcuffs.html [2]https://lrytz.github.io/pubsTalks/ the link to his thesis doesn't work anymore. I cherry pick some of it in my talk for a Scala meetup in Utrecht https://www.slideshare.net/yoozd/effect-systems-in-scala-bey...

Re: Java 12

#354

Post by tobiaswk »

MarkMc wrote: post #214

I'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 years like some flavour-of-the-month Javascript framework. Even on the client where Java has lost to Javascript, I'm finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javas…

I love Dart and Flutter. I actually think it was a good idea not to use Java. Dart is much more modern and nice to work with in my opinion. There are many reason and I won't dwell into it here. The biggest-ish project I've built with Flutter is an alternative to Nissan's ConnectEV app; it's used with the electric vehicles Nissan Leaf and Nissan E-NV200. You can see statistics, battery status and control climate control and charging of your vehicle. My alternative is called "My Leaf" on the Play Store and "My Leaf for Nissan EV" on the App Store. It's completely open source; https://gitlab.com/tobiaswkjeldsen/carwingsflutter

It consists of the main Flutter app and a Dart library for communicating with Nissan's API.

Re: Java 12

#355

Post by jillesvangurp »

ocdtrekkie wrote: post #16

Meanwhile, most enterprise apps still seem to only work with JRE 8. And those which I know of have elected to replace Java rather than upgrade.

You have to realize that the first LTS release after 8 was v11 which was released only a bit over 6 months ago. V12 is a non LTS release. So v8 is going to be around for a while. Adding to this is the rather substantial refactoring that happened due to the introduction of modules in v9. This is creating more than the usual amount of porting headaches. IMHO v8 to v9 was by far the most disruptive Java release ever in that sense.

Re: Java 12

#356

Post by lmm »

Freak_NL wrote: post #325
riku_iki wrote: post #273

Earlier quoted context omitted.

You should return some ResultOrError value instead of throwing Exception..

That's what languages like Rust do with a return return type that is part of the core language. Sometimes I wish Java had one too to complement Optional. I wonder what the argument against that is? Too much confusion with the existing Exception system?

Java managed to break the Optional type badly enough that it can't be used for its intended purpose (it can't contain null which would be great if the rest of the language couldn't contain null either, but as it stands it's not practical to port existing Java code to use Optional), so I wouldn't trust them to implement a working result type.

Working with result types is really cumbersome in languages that don't have HKT (Rust hacks around it with a special-purpose language feature), and even more so in languages that also don't have pattern-matching. So I'm not sure how much use it would be in practice. But yeah it's the right way to solve the problem.

Re: Java 12

#357

Post by lmm »

pjmlp wrote: post #322
fnord123 wrote: post #136

Earlier quoted context omitted.

Part of the issue is that a lot of libraries target jdk 8 since that's what Android supports.

Actually libraries that target Android need to use Java 7, unless they want to constrain their users to API 26+.

Is newer Android fully JVM-8 compatible? It'd be great to be able to start using Scala 2.12 even if it means I have to restrict to new devices only.

Re: Java 12

#358

Post by lmm »

swish_bob wrote: post #350
krakatau1 wrote: post #339

Earlier quoted context omitted.

because every Maven project is more or less same while Gradle projects vary drastically...I don't know how anyone can tolerate Gradle and performance benefit is not that great...

The performance benefit is huge . I understand not wanting to learn another build tool, but I have no regrets where I've moved to gradle. It's so much faster on a project of any size it's stunning. 90% of maven projects don't do anything terribly complicated. Porting them to gradle leaves them uncomplicated and unexciting. I just wish there was a standard release mechanism. Poor as mavene-release is, at least everybo…

> 90% of maven projects don't do anything terribly complicated. Porting them to gradle leaves them uncomplicated and unexciting.

They don't stay uncomplicated though. Someone puts a quick one-liner hack in the build definition to fix some trivial issue they were having, and it never gets removed, and years later it bites you. I don't trust myself to remember and understand arbitrary code that I put in a build definition, yet alone anyone else.

Re: Java 12

#359

Post by ptx »

pjmlp wrote: post #323
james_s_tayler wrote: post #282

Earlier quoted context omitted.

Why do people still use Maven when Gradle exists? I'll never know.

Because Maven doesn't require a background daemon eating 2GB of memory to be fast and IDEs can actually provide code completion and documentation while typing. Android is the only reason to have to put up with Gradle.

Gradle 5 lets you write the build scripts in Kotlin, which is supposed to address the code completion issue. (And the continuous build mode is a nice feature!)

But, yes, is does use a lot of memory.

Re: Java 12

#360

Post by vbezhenar »

ars wrote: post #174
vbezhenar wrote: post #37

Earlier quoted context omitted.

Another option is to fool the compiler. So-called sneaky throws. Something like public static void main(String[] args) { try { sneakyThrow(new IOException("io")); Test. emulateThrows(); } catch (IOException e) { e.printStackTrace(); } } static void sneakyThrow(Throwable e) { Test. sneakyThrow2(e); } private static void sneakyThrow2(Throwable e) throws E { @SuppressWarnings("unchecked") E e1 = (E) e; throw e1; } stati…

This only works if I'm throwing the exceptions myself, but not if I'm using a library function (like a rowMapper for example).

You can write wrapper which takes function that can throw anything and returns regular java.util.function.Function. Here's example: https://github.com/rainerhahnekamp/sneakythrow/blob/master/s...
Post reply on HN