Java Turns 25 – Whats Next? [pdf] • Hacker News Board

Re: Java Turns 25 – Whats Next? [pdf]

#221

Post by TheUndead96 » Mon, Sep 21, 2020, 6:22 AM UTC

mark_l_watson wrote: post #103

While my career has mostly been as an AI practitioner, Java was also very good for my career. Sun had a link for a year on their Java home page to a blog article I wrote on the Java world tour so for about 10 years I was the first search hit for “Java consultant” which was nice enough. Except for periodically updating my Java AI book [1] (5th edition was released July 2020), I don’t much use Java because most of my c…

Are the customers demanding work in Lisp creating new systems, or maintaining mature systems? I had assumed that the use of Lisp for symbolic reasoning and AI had largely disappeared. Is it making a resurgence?

Re: Java Turns 25 – Whats Next? [pdf]

#222

Post by jussij » Mon, Sep 21, 2020, 6:22 AM UTC

hota_mazi wrote: post #211

tasogare wrote: post #199

Earlier quoted context omitted.

C# (largely inspired by Java) run on even more platforms, because there is compiler/runtimes for mobile platform. It’s also the second biggest "entreprise" language, which fix a lot of Java pain points.

Technically, maybe. In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority. On the other hand, Java is being written on all platforms and being deployed on many as well.

Microsoft is pushing hard with it's .Net Core offerings and that effort is designed to make C# a more universal language.

Whether that effort pays off, only time will tell.

Re: Java Turns 25 – Whats Next? [pdf]

#223

Post by throwaway8941 » Mon, Sep 21, 2020, 6:29 AM UTC

nfg wrote: post #219

hota_mazi wrote: post #211

Earlier quoted context omitted.

Technically, maybe. In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority. On the other hand, Java is being written on all platforms and being deployed on many as well.

> In practice, how many developers write C# on a non Windows platform? I'd say a very, very tiny minority. Plenty do - think of deploying c# web services on Linux servers / containers.

GP said "write", not "deploy".

I write C# on Linux and I am basically the only person I know who does that.

Re: Java Turns 25 – Whats Next? [pdf]

#224

Post by pkolaczk » Mon, Sep 21, 2020, 6:35 AM UTC

throwaway189262 wrote: post #114

topspin wrote: post #69

One thing that is hurting Java today is memory usage. Conventional JVMs use a lot of memory relative to essentially everything else and this is drives up cloud bills. There are alternative JVMs and other tools, some of which is embryonic at this point, but what the world wants and what Java really needs to continue thriving is efficient memory use by the bog standard JVMs that work with everything.

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…

GC and memory settings are not the only cause. There are several other factors:

* JVM overhead - all these advanced optimizing compilers and GCs have non-zero footprint. They need RAM to run their code and they need RAM to perform their tasks.

* Compiled code cache - JVM keeps both the original bytecode and generated machine code in RAM.

* OOP overhead - each object has 2 or 3 words of overhead for the object header vs zero in languages like C or Rust. Even when you don't need dynamic dispatch or object locking, you pay for it.

* Inability to compose bigger structures other than by allocating separate objects and using pointers to reference them - these pointers need space and are not cheap on 64-bit architectures. This is going to probably partially improve with Valhalla, but at this point it is mostly guessing and it has been in development for years.

* No support for packed arrays.

* The smallest unit of loadable code is a class. If you needed a single function, the JVM loads a whole class containing it, and its required dependencies. This is not only bad for memory usage but also for startup time. Unless you pay a lot of attention, it is easy to load 80% of code in order to just display a help message (this is based on a real issue I worked on - I'm not making this up). Compare that to code in languages like C - the OS loads code that gets executed.

And back to GC - I agree the default settings are often to blame, but there is a reason JVM defaults to using RAM so aggressively. GC becomes very inefficient when it doesn't have enough "room". And low pause GCs achieve their low pause goals by trading throughput. Switch from parallel STW GC to G1 and your maximum sustainable allocation rate goes down by a few times.

Re: Java Turns 25 – Whats Next? [pdf]

#225

Post by rcoveson » Mon, Sep 21, 2020, 6:36 AM UTC

throwaway189262 wrote: post #114

topspin wrote: post #69

One thing that is hurting Java today is memory usage. Conventional JVMs use a lot of memory relative to essentially everything else and this is drives up cloud bills. There are alternative JVMs and other tools, some of which is embryonic at this point, but what the world wants and what Java really needs to continue thriving is efficient memory use by the bog standard JVMs that work with everything.

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…

When I hear "Java uses too much ram," lazy reclamation of the heap and other GC overhead are not the first things that come to my mind, personally.

Java doesn't have a "struct". If you want to represent an array of 64-bit signed integers, Java has you covered with its primitive arrays. But if you want to represent an array of anything more interesting than that, (say, a tuple of a double and a long), you have to serialize and deserialize those objects to and from parallel primitive arrays or byte buffers. Because if you do the language-natural thing and use an Object array, you're paying a huge price in memory: 4 or 8 bytes per pointer in that array, plus a 16 byte Object header on each Object. And, of course, those Objects are all individual allocations, not necessarily contiguous. That's a lot of overhead!

Of course, Java programmers concerned with memory usage don't put up with this. Lots of solutions have been devised. OpenHFT's Chronicle Values[0] is one example I came across recently. But this feels like fighting with the language compared to how easy it is to be efficient with memory in C. If you told a beginner C programmer to make an array of compound objects, it's not unlikely that their array will take up exactly as much space in memory as it intuitively seems like it should. (8 byte double + 8 byte long) * 100 values = 1600 bytes in C, no fuss. If you asked the average Java programmer for that they'd give you something that would take up 3 times as much memory. And because Java makes that behavior natural, it "uses too much ram". It doesn't matter as much that it's possible to convince it not too.

0. https://github.com/OpenHFT/Chronicle-Values

Re: Java Turns 25 – Whats Next? [pdf]

#226

Post by deepsun » Mon, Sep 21, 2020, 6:37 AM UTC

rzwitserloot wrote: post #34

mxschumacher wrote: post #2

Slightly tangential, but due to a new job I'll have bite the bullet and learn Java. When googling tutorials, I see the same material I found 12 years ago. A lot must have happened since then. What's a good resource to learn Java for somebody who already knows how to program? I'm interested in ecosystem, tooling, best practices, common pitfalls etc.

> A lot must have happened since then. Yes. As others have said, 'java is stable' which means the old stuff still works. Which in turn means that a lot of people are still using it and still writing blog posts about it. That still makes these old things often obsolete, or needlessly complex and just 'lesser than'. They don't support certain nice features or support them very badly, or have other significant downsides…

Wow, thanks for "JOOQ or JDBI"!

I'm the perfect case of what you sad re. old devs -- I've been using various JVM languages for ~15 years, but still didn't think of replacing JDBC :) Will check those out!

Re: Java Turns 25 – Whats Next? [pdf]

#227

Post by pkolaczk » Mon, Sep 21, 2020, 6:48 AM UTC

throwaway189262 wrote: post #198

deepakarora3 wrote: post #148

Earlier quoted context omitted.

All OK except when you need the same level of performance for those 0.001% of requests when the GC kicks in and takes the response time outside acceptable limits. Due to this reason alone, my company is planning to move off a popular Java based API gateway and to a C++ envoy side car implemented service mesh. And I am wondering if this is really worth it.

Consider trying ZGC first. The main selling point is low worst case pause time. I've seen some tests where P99.9 pause time was less than 5ms, vs several hundred for older collectors. In my limited tests I never saw a GC pause over 5ms. I was basically hammering a Spring Boot application with HTTP load tester.

GC doesn't need to pause to have a negative effect on application latency.

While not-pausing is generally a huge improvement (after several decades of GC development), now what about thrashing of CPU caches?

Re: Java Turns 25 – Whats Next? [pdf]

#228

Post by 0xae4f5b » Mon, Sep 21, 2020, 6:50 AM UTC

throwaway189262 wrote: post #112

hn_throwaway_99 wrote: post #87

Earlier quoted context omitted.

Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has. I was pretty much exclusively a Java programmer for the first decade and a half of my career, before moving to Node and TypeScript. I don't think I could ever go back at the point. Most importantly, this is my first time where t…

I use typescript a lot. It's way better than JS but the type erasure problem is far worse than Java. Essentially all types are erased, so bugs where typings don't match what you expect and everything blows up are common. This isn't possible in Java because it's statically typed at runtime. JS also uses several times more memory, is slower, and has a terrible (non existing) threading model. Yes you can run multiple in…

> has a terrible (non existing) threading model. Yes you can run multiple instance of node or whatever, but sharing objects between them requires message passing

Don’t Node.js worker threads solve exactly this?

Re: Java Turns 25 – Whats Next? [pdf]

#229

Post by pjmlp » Mon, Sep 21, 2020, 6:57 AM UTC

hota_mazi wrote: post #218

pjmlp wrote: post #213

Earlier quoted context omitted.

25 years of libraries to choose from slowly not available on Android. If the Android team plans to rewrite all of them in Kotlin, be my guest. Maybe they will manage before Fuchsia goes live and Flutter wipes the floor, and then everyone will be doing Dart anyway. Have you noticed how shitty are all the languages designed at Google? Thankfully someone that was there since Java 1.0 days bought its rights. GraalVM woul…

> 25 years of libraries to choose from slowly not available on Android. > If the Android team plans to rewrite all of them in Kotlin, be my guest. What are you talking about? Android developers can use Maven Central like any other Java developers without care about what JDK these dependencies were compiled with nor even whether they were written in Kotlin (most did not, obviously). > I am also looking forward to the…

They definitely can not use them, when they they make use of JVM features or JDK libraries delivered post Java 8.

Stating otherwise just proves that you don't know Java.

Android Studio and the complete Android toolchain runs on top of a JVM implementation, as the JVM moves forward, JetBrains will be forced to update InteliJ to take advantage of newer JVM versions, which will force Google to update all their Android development environment.

Just for kicks they are already being forced to do this,

https://github.com/robolectric/robolectric/issues/5258#issue...

https://issuetracker.google.com/issues/139013660

Again, another proof of total lack of knowledge regarding Android

Toxic bille at Java?!?

Quite the contrary, I love Java since 1996 that is my third pillar alongside .NET and C++, what I completely hate is that Google played a Microsoft move with their flavor of Android Java (aka Google's J++), helped Sun going bankrupt withering them the revenue stream from Java deployments on Android, didn't bother to rescue Sun hoping that it would close doors without a hiss, now with its Android Java forces Java developers to create special versions of their libraries tailored to Android, and has a bunch of Silicon Valley fanboys supporting their damaging actions to the Java eco-system.

What were again your apps on Play Store?

Re: Java Turns 25 – Whats Next? [pdf]

#230

Post by pjmlp » Mon, Sep 21, 2020, 7:07 AM UTC

tasogare wrote: post #199

hota_mazi wrote: post #183

Earlier quoted context omitted.

> Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has. It completely succeeded in that! Java (well JVM) developers today can - Write code on any of Windows/Linux/macOS - Deploy that code on any of Windows/Linux/macOS Not a lot of language/platforms can claim to this amount of succ…

C# (largely inspired by Java) run on even more platforms, because there is compiler/runtimes for mobile platform. It’s also the second biggest "entreprise" language, which fix a lot of Java pain points.

Actually C# runs on less platforms than Java, because it doesn't run on embedded devices, M2M, bluray players, military deployments, mainframes, Xerox and Ricoh copiers, SIM and chip based credit cards, and plenty of others devices, like even having a mobile OS based on an Java dialect.