since 3 years ago
15 of 15
Tip Reveddit Real-Time can notify you when your content is removed.
your account history
Tip Check if your account has any removed comments.
view my removed comments you are viewing a single comment's thread.
view all comments
Premise: I am a university researcher so I use Java mostly to write simulations. For me, the biggest problems are: - no value types (I am waiting for project Valhalla) - no unsigned math - strict double precision instead of using 80bits extended on x64 - modules are really complicated which in turns makes dependency management a chore. - in general, not much tools for scientific computing compared to Python… like Math doesn’t even include all the functions of math.h of the C standard library
When you say modules are you referring to "java modules", like the things created with
module-info.java, or just maven-style dependency management?Both to be honest. The module-info.Java makes little sense to me and, because of it, using external libraries is complicated. In the past, I could just download the jar and put it in my class path. Now, you usually have to mix this old style with the new module style.
Maven is quite complicated to use for me. But I believe that’s a me problem. It assumes a certain project structure that is more suited towards “enterprise” or web applications, with multiple programmers involved, unit tests and deployment to servers. In contrast, my projects are very small, I work on them alone, I don’t write many tests, and I don’t need to deploy them anywhere except my pc or the Linux machine in the basement.
But anyway, I like a lot to use Java, and I will continue to use it. It’s a pity that my field is so niche that it barely gets any attention by the core devs.
You really shouldn't use module-info for such projects (or perhaps at all). All my personal projects don't use it, nor do any of our professional projects. It's
rarelynever needed.The JPMS is optional for most applications, and unless you really want to use jlink or GraalVM, I'd recommend to not bother with it. As long as you avoid split package situations and use reflection sparingly, your code should be portable to it though.
If all you need from Maven is compilation and some dependency management, then you can just copy&paste the same
pom.xmluntil the heat death of the universe. There are less verbose build systems out there, but I'd pick it for personal projects for the same reasons as for enterprise ones: it works and it behaves quite unsurprisingly, most of the time.You don't have to use any of that, except the
src/main/javadirectory. You can also use different Maven project archetypes.And the dependencies are declared in the POM file. Unless you have some transient dependency conflict, it's not complicated.
You can still download jars from Maven Central manually and put them in your classpath.
You might want to check out Apache Ant. The reports of its demise have been greatly exaggerated.
I know Ant and I used it for a project. It's a lot simpler to use than Maven.
It's not dead, of course, but it's steadily falling out of use
Yes
You can use Valhalla Early Access builds but afaik IntelliJ/Eclipse both do not support the syntax and new bytecode.
However I have a toy project where I use it with Eclipse with regular JDK 17. My Vec3/Vec2/Mat4 etc are just POJOs with final fields. But I pre-process all my source files into a new directory and add "value" keyword to all of my value based classes(Vec3/Vec2/Mat4/etc). Then I compile everything (everything! even usage of value classes generates different bytecode) with Valhalla EA JDK 20 and run it on that.
This way I have IDE support, because I just code with regular old Java 17 without new syntax.
This is a bit messy setup and not really something you would do in regular development, but if you do R&D (which you definitely do as a researcher) then you are probably familiar with weird workflows anyway.
This is actually a cool hack I did not think about! Thanks for the hint! :-)
JDK architect Joe Darcy wrote some convincing arguments against adding distinct unsigned-integer types. I was convinced, although the links to the post seems to be dead.
JDK 8 added unsigned functions to java.lang.Integer like compareUnsigned, divideUnsigned, remainderUnsigned: the Java compiler/runtime inlines these to CPU instructions so they are fast and there is no runtime overhead.
Project Valhalla value types sound exciting, but that's mainly about runtime performance, right?
I'm curious, what type of math functions do you want? There are tons of Java math libraries.
Unsigned integers are very useful for bit masks, byte manipulation, and very long counters. They are also pretty useful in geometric stuff. Unsigned integers save you from negative value checks when passing sizes of stuff to methods, for example.That said, unless you deal with raw io or specific cases, you gain get away without them. Valhalla is for performance, you are correct. In the openjdk wiki there is an example of a contiguous array of 2d vectors which is not currently possible to obtain. It would have been nice to have the error function and it’s complementary function (erf and erfc) in Math.*
unsigned ints are useful, but JDK8+ has full unsigned functionality without distinct unsigned types. You can put unsigned values into the signed integer types with full bit-length. Addition, subtraction, and multiplication are bit-wise identical for unsigned values. For division/remainder + comparison, you have to use the special unsigned methods in java.lang.Integer.
Yes, Valhalla will be nice to let you have arrays of points/vectors in a convenient performant fashion. Right now, you can either have List<Vector> which is convenient but slow, or you can have multiple double[] arrays, which is fast but inconvenient.
Things like erf and erfc are in Apache Math and many, many other math libraries.