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

331–340 of 478 posts

Re: Java 12

#331

Post by merb »

ksec wrote: post #302
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…

>Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun. They didn't and Google didn't want a pay a single dollar to Sun on Java. As James Gosling has mentioned multiple times. I don't understand why people are still painting Google as Saint after all these years.

actually they didn't want to pay a single dollar to sun, because of licensing reasons, not because they didn't wanted to buy java.

currently they recreated the java apis by pulling in apache harmony and they tought that they are in the right or at least in a fair use position (they still think they do). but I agree, I'm not sure if the direction of java would've been better when google would have the stewardship.

Re: Java 12

#332

Post by pjmlp »

nineteen999 wrote: post #328
pjmlp wrote: post #91

Earlier quoted context omitted.

Once upon a time the barrier was the existance of VMT tables and method dispatch. GC use can be optimized in high level languages with support for value types (which are still missing in Java, though) and it is not like every game needs to be the next Fortnight.

Only tangentially related to your comment, Fortnite is based on UE4 so it does use garbage collection. And it has caused framerate/hitching issues as recently as a year ago according to an Epic developer. https://www.reddit.com/r/FortNiteBR/comments/7gu8aq/hitching...

My point being that everyone evaluates programming languages for writing games as if they would be doing a AAA hit, when they will actually be doing a minesweeper clone.

Thanks for pointing it out though.

Re: Java 12

#333

Post by tannhaeuser »

ivan_gammel wrote: post #317
tannhaeuser wrote: post #301

Earlier quoted context omitted.

The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serving APIs (expressjs and core http request API, which expressjs middlewares forwards and decorates) is stable since node.js v0.1 or at least 2015, and infinitely better than Java's servlet, JSP, and taglib APIs (web.xml/jetty-config.xml anyone?). The flip side…

Any app reaching complexity of what’s being done on Java will look the same, no matter what platform do you choose. I haven’t yet seen large nodejs deployments with MLOCs and hundreds of developers, but I’m pretty sure it can easily become much bigger mess - the tools and the libraries are immature, there’s lack of enterprise SDLC patterns etc, which creates a lot of obstacles. Spring is becoming too enterprisey thes…

nodejs isn't a replacement for fat backends for sure, but it's working really well for a frontend-facing light backend where frontend developers can add endpoints as the need arises, such as for autocomplete functionality, and where first-party support for asset pipeline tools is desired. The Spring experience isn't bad for newbies creating "REST" microservice spaghetti to have something to show at the end of their agile day, but it gets seriously in your way if you're a seasoned dev and have a solid understanding of what you want to achieve in terms of network-exposed interfaces and integration with other apps.

Re: Java 12

#334

Post by james_s_tayler »

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.

Fair enough. It doesn't sell me on switching back to Maven. Ram is cheap enough. With 32GB Gradle can have a couple if it wants.

Re: Java 12

#335

Post by tannhaeuser »

tannhaeuser wrote: post #330
pjmlp wrote: post #314

Earlier quoted context omitted.

In all these years I have used Spring exactly once for an architecture prototype, during one month project. All our customers doing Java Web projects are either on JEE, or a CMS platform running on top of servlets and JEE related JSRs, like Liferay and AM.

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

Re: Java 12

#336

Post by james_s_tayler »

pjmlp wrote: post #308
james_s_tayler wrote: post #286

Earlier quoted context omitted.

I'm finding library support quite good for .NET Core tbh. Not perfect, but it's not at all a barrier to adoption.

Try to port any commercial component library to it like Telerik and friends, ODP.NET, WCF, EF 6, Forms, WPF. .NET Core 3.0 will fix some of the compatibility issues but not all of them, for example EF 6 will only be partially supported (VS DB tooling is not being updated for Core).

Yeah .NET Core 3.0 will address some of that, not all. I suppose for any brownfield development looking at switching across those things are the potential blockers at the moment. Especially things running EF where EF Core doesn't have a particular feature just yet. But EF Core development is cracking on at a good pace.

Telerik and the likes I'm not so fussed about personally. I suppose DevExpress is another one on that list. I think front end component libraries like Prime-ng/PrimeReact are probably the way to go for the future of UI development for Line of Business applications.

Overall I reckon in a couple of years there won't be much of those blockers left at all.

Re: Java 12

#337

Post by zokier »

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.

Well, most of JavaEE is still stuck on JDK8, unfortunately. Last I heard that Payara is maybe getting JDK11 support in Q2, and OpenLiberty currently only supports JDK11 on OpenJ9.

Re: Java 12

#338

Post by ptx »

pjmlp wrote: post #315
euyyn wrote: post #295

Earlier quoted context omitted.

Kotlin though. Everything you said, but a joy to write instead of a chore.

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).

Re: Java 12

#339

Post by krakatau1 »

james_s_tayler wrote: post #282
samus wrote: post #99

Earlier quoted context omitted.

Yeah, that kinda makes it impossible to become a successor to Swing. But the situation actually got more sane because JavaFX can be included now as a Maven dependency, like any other framework.

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

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...

Re: Java 12

#340

Post by chopin »

vbezhenar wrote: post #20
crooked-v wrote: post #4

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

I wonder why they didn't use generic exception type in their java.util.function classes. That would propagate checked exceptions statically. Something like @FunctionalInterface interface Function { R apply(T t) throws E; }

This doesn't work if your function throws multiple checked exceptions.
Post reply on HN