OpenJDK Java's Native Wayland Support Progressing

[reavertm]

If anyone know of a good IDE for C/C++ that can handle the Linux kernel well I'm all ears. (With a reasonably easy set up of include paths etc as well. The Linux kernel has a rather unique build system after all.)

I've been using KDevelop for all my C/C++ projects for a long time. It is nowhere near as unstable as it used to be in the past. I'm not quite sure it will discover all the include directories from Makefile for code completion though. I need to test that.

[caligula]

Generally speaking in any language you can create perverse situations where a compiler doesn't optimize certain code, even in C/C++

FWIW those small design decisions by the Java team make all sorts of code slower by default. Did you know that Java, in general, cannot even guarantee access to array elements without doing bounds checks every time. It can eliminate bounds checks in SOME cases, but you can't simply turn it off in all cases. E.g. if you're drawing a mandelbrot fractal (one of the benchmarks here https://benchmarksgame-team.pages.de...test/java.html), this might slow down your algorithm by 80% -- 3.27s vs 16.16 (fastest C++ vs Java). I'm not saying Java is shit. It's just that the current de facto implementation has significant inefficiencies in few core features. I also heard they're planning to fix some of those, but those fixes have not landed there yet.

What you say is also correct - despite having these inefficiencies it's still possible to write your code in a more efficient way if you know what you're doing. Also I'm not referring to CLion, but the IntelliJ products in general. The GUI is a bit sluggish. Just compare with something like Code::blocks or some old Tcl/Tk application. It has very much to do with basic handling of event dispatch, reactive GUI elements, generation of short-lived bogus garbage objects. E.g. some toolkits create a new Object every time you move the mouse. For every mickey. That's a huge amount of objects on modern systems with 300 dpi screens and 20000 dpi pointing devices. Some other GUI toolkits are able to immediately reuse the storage. Sure Java has an efficient memory pool for those objects, but it's still a bit slower and generates extra work. Like I said these inefficiencies are extremely tiny, but when your app has millions of lines of code, and all coding conventions are a bit sloppy (wrt performance), the slowness starts to accumulate. It's much easier to notice if you're willing to use those tools on older hardware. Again I'm not talking about parsing code or Intellisense. Please try to run IDEA on some Pentium 3/4 class machine to edit plain text files. Then compare with Geany or Code::blocks.

[Vorpal]

Please try to run IDEA on some Pentium 3/4 class machine to edit plain text files. Then compare with Geany or Code::blocks.

Fortunately I don't need to. I have modern beefy computers. As long as the program runs well enough I don't care. PyCharm runs well enough for my needs, CLion does not. Mostly I suspect because the C code bases I work on are much larger than the Python code bases. Could also be that parsing C++ is much more expensive. (The lexer in C++ (but not C) needs type information for correct parsing if I remember correctly, while Python used to be LR(1), now it is PEG).

[M@yeulC]

Typo:

Hey, welcome back! I missed you :P

[MauganRa]

Both Java and Electron based IDEs ship with a VM of their own. Jetbrains isn't even compatible with the standard OpenJDK, thus there's a need for a custom VM.

Jetbrains products are quite compatible with upstream JDK. Running it with JDK 20 as my daily driver^^ I haven't noticed any rough edges because of JVM shenanigans so far.

[caligula]

Fortunately I don't need to. I have modern beefy computers. As long as the program runs well enough I don't care.

That's the main reason apps become slower over the years. For example, now that the Ryzen 7000 series was released, apps are allowed to gain more weight. The new CPU gen will provide acceptable performance for apps that are 20 to 80% slower than the previous software. Ain't it great? Related: https://danluu.com/input-lag/

[mdedetrich]

FWIW those small design decisions by the Java team make all sorts of code slower by default. Did you know that Java, in general, cannot even guarantee access to array elements without doing bounds checks every time

Oh come on, seriously stop it. This is so little of a bottleneck that even Rust, by default, does a bounds check every time an array is accessed. It can be turned off, but its highly recommend not to do so because it opens the floodgate for security issues (which is ironically the reason why Java does it). And this is Rust we are talking about, which has libraries that compete in terms of performance/memory usage with C/C++.

So many times a single C developer thinks they are "smart" by micro-optimizing their code and not doing a bounds check, only to find out a decade later that some high level CVE security exploit is discovered.

[Weasel]

Oh come on, seriously stop it. This is so little of a bottleneck that even Rust, by default, does a bounds check every time an array is accessed. It can be turned off, but its highly recommend not to do so because it opens the floodgate for security issues (which is ironically the reason why Java does it). And this is Rust we are talking about, which has libraries that compete in terms of performance/memory usage with C/C++.

Another reason Rust sucks but not so much since you can turn it off at least...

So many times a single time a C developer thinks they are "smart" by micro-optimizing their code and not doing a bounds check, only to find out a decade later that some high level CVE security exploit is discovered.

Software quality > security.

Adding pointless checks, especially when it's not even the proper place for them, is just disgusting. Checks should be added to validate untrusted input, but if you automatically add them everywhere, you'll have disgusting code generated in places it shouldn't be, by design.

[mdedetrich]

Another reason Rust sucks but not so much since you can turn it off at least...

Massive facepalm. People have done benchmarks on this, generally if you are concerned about performance of bounds checking on arrays you need to become a better programmer.

Software quality > security.

Software that has shit security is not quality software by definition.

Adding pointless checks, especially when it's not even the proper place for them, is just disgusting. Checks should be added to validate untrusted input, but if you automatically add them everywhere, you'll have disgusting code generated in places it shouldn't be, by design.

I am sure that the billions (if not trillions) of damage caused by not doing such checks is a fantastic way of describing them as pointless.

[Weasel]

Massive facepalm. People have done benchmarks on this, generally if you are concerned about performance of bounds checking on arrays you need to become a better programmer.

I don't give a shit about your benchmarks. It's objectively worse, uses more power, has potential to be slower, and has increased code size (for compiled languages).

If you insert automatic checks even where they are not needed you need to become a better programmer.

Software that has shit security is not quality software by definition.

Ok, here's the simple rundown:

1) Software with no bounds checks in some parts where input must be validated: security issue, but can be fixed.
2) Software with automatic bounds checks everywhere, even when input is known to be good (for example because it was fucking validated by a parent function already): hopeless, will FOREVER remain shit quality code with redundancy.
3) Software with proper bounds checks only where validation is required: quality software.

(1) can be fixed. (2) is a lost cause, it will forever remain shit. (3) is what everyone should aim for, of course.