In Java, every object is heap allocated - unless you are lucky enough for that to be optimized away. If you absolutely need the performance, you must resort to a weird kind of place-orientated programming, where you pass around mutable references to primitive types that get operated on by static functions. It kind of resembles C, but without the struct keyword!
https://openjdk.java.net/jeps/404
https://openjdk.java.net/jeps/402
Both .NET and Java did major mistakes at their v 1.0, by ignoring what other GC based languages were doing.
- Proper value types (Even .NET is only catching up since C# 7.0)
- AOT compilation alongside JIT (NGEN was just for startup and without optimizations, and on Java side only third parties)
- Seamless FFI with host OS (P/Invoke did better, JNI is finally getting a replacement)
Eiffel, CLU, Mesa/Cedar, Oberon linage, Modula-2+, Modula-3 were inspiration, but those capabilities were apparently considered not relevant enough, go figure.
Erlang's BEAM's nif[0] interface is the best I've seen in mainstream runtimes for FFI. You write an Erlang/Elixir/etc. function, and loading a native library may swap out the function body. This allows for workarounds in Erlang/Elixir/etc. in case of version skew in your native libraries.
In my day job, I work with a domain-specific language with a similar FFI (actually, 3 different FFIs, one similar to nifs), and it's very handy to have a fallback that does things with /proc/, calling external command line binaries, slower versions of FFI functions, etc. (This allows the native code release schedule to be decoupled from the domain-specific language code changes.)
The syntax isn't the same, but a Java-like syntax would be
// getpid is built in, but it could be done something like this
// look for XNativeGetPID() in mylib.so or mylib.dll depending on OS
@native_replace("XNativeGetPID", "mylib")
public static int getpid() {
// Throw an exception if you want to force
// native implemementation
return Integer.parse(Runtime.system( "/bin/grep pid /proc/self/status | /bin/sed 's/..." ));
}
By the way, it is now in preview.
Do you have any idea how easy it is to provide a Java fallback on platforms where a native implementation isn't available? (I find it's often possible to call out to a command line tool as a workaround for things I'm trying to do in native code.)
To read more about Panama, https://jdk.java.net/panama/
Check Foreign-Memory Access API and Foreign Linker API related entries.
Though I’m not sure I would want this behavior, or at most for really optional deps; ideally software should be “installed” in an ideal environment.
Native implementations with non-native fallbacks can be an important decoupling mechanism.
I used to be a developer for a Linux desktop application with a peak of something like 60 million unique users over a trailing 3 month window. We had Windows, OS X, RPM, and dpkg installers with native libraries, but people also ran our software on FreeBSD, Gentoo, etc.
It's handy to have gradual enhancement/graceful degradation in non-ideal installs where the native API's you'd like either don't exist or are buggy and shouldn't be used.
In my day job, we sometimes have a business need to iterate new features at a faster tempo than our native code release schedule, so it's nice to have a similar sort of fallback implementation.
Let's say you want to have a native-looking prompt window via wxWidgets, and fall back to Swing if wx isn't installed. Or, you want to use some particular optimized native BLAS library if it's installed, or fall back to doing the linear algebra in Java if it's not available.
In these cases, and many others, "detecting OS features" involves checking LD_LIBRARY_PATH (or PATH on Win32) for libraries, checking they're for the correct architecture, etc. The OS already provides dlopen() or its equivalent for this purpose. Properly detecting the OS and emulating the OS's algorithm for finding native libraries is just wasteful when the OS already exposes the functionality.
As an added bonus, an FFI that replaces a method body allows someone who doesn't have the C/C++/Rust/FORTRAN handy, or can't read it, to see roughly what the native code should be doing.
AOT compilation of a dynamic language like Java is hard to do without losing performance. You can AOT Java now with the same compiler used also for JITC (Graal) and you lose, I think, about 20% of the peak performance unless you do C++ style profile collection and double compilation. It's not clear that lack of AOT compilation held Java back any - although SubstrateVM/native-image are getting popular at the moment, that's taking place in the context of hype around "serverless functions". If you aren't using those (or writing small CLI apps, or doing other unusual things) the benefit is less clear.
With respect to proper value types, trying to do that in 1.0 would have just killed the projects. Biting off too much. Look at the complexity of Valhalla - only a small part of it comes from backwards compatibility. Most of it is trying to get the benefits of generics over value types via specialisation without the horrible consequences suffered by other languages. It's not about rectifying past errors but rather, doing something new.
Java is a static language.
In C# structs are value types, and they've been with .Net since the beginning IIRC. I assume maybe you're referring to System.ValueTuple? It was added in C# 7 and allowed tuples to be value types along with significantly better syntax for working with them.
There is so much more for value type programming, see sibling comment.
- proper memory slices
- ability to do stackalloc in safe code
- readonly structs
- generics for blittable types
- zero allocation pipelines
- using without IDispose for structs without implicit boxing
- return scope for zero copy struct parameters
- native function pointers
- static lambdas
I would agree that things like
> - using without IDispose for structs without implicit boxing
and
> - generics for blittable types
would make value types more "proper" in the C# language.
Just like C and C++ offer similar optimizations to avoid writing the tons of Assembly that was so common up to the mid-90's.
So yes, optimizations are definitly part of proper value types.
[0] https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/exp...
See the bullet list on a sibling comment.
https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-...
Your 25 year old jars are supposed to keep working as much as possible.
And I don't even do Java development.
Not to mention android and gradle being broken and randomly failing to work between different JVM versions - depending on the gradle flavour of the day.
I don't really see JVM as a pillar of stability and backwards compatibility.
And modules was a single breaking change, hardly a regular thing.
The don’t upgrade thing on the server is a generally wanted stable environment, or do you upgrade libc in prod without testing it first? Also, it happens mostly in banks and other not-too technically up-to-date places that often times depend on bugs themselves. Trailing the latest OpenJDK is the best thing one can do.
Also, android is not/barely Java.
We literally had software in production that wouldn't work when you upgraded the JVM and their official documentation said it wouldn't work if you updated and you were unsupported (and IIRC downgrading was also a PITA) - this was in JVM 5 -> JVM 6 days which AFAIK was a big change (TBH I don't know back then I didn't do app development I did system integration).
Second, I didn’t say it is in every single case backward compatible, since that is impossible in a continuously evolving platform. But there are really few “user”-facing changes in the JVM. And so I still state that calling the JVM non-stable (for which you provided no evidence), or non-backward compatible is simply false. Please tell me a platform which is stable/backward compatible according to you to at least this degree.
(Also, we are at java 16!, java 5, 6 is so old that it is not particularly telling about anything)
0: https://aspsecuritykit.net/docs/api-reference/aspsecuritykit...
What do I mean by that? Here's my idea. Make a Fluent parser. I have some few shallow structs that can be used interchangeably. E.g. you want to have following structure
Entry:
- Message
- Term
- Comment
Option 1) Go with interfaces. Yay. I've incurred the boxing penalty. I might as well as just write a class.
Option 2) Go with [FieldOffset]. Only do this if you are a masochist and you REEEEEEEEEEEEAAAAAAAALLY need that performance.
In Rust for instance, I could replace that stupid struct with an enumeration, which is impossible in C#. Hopefully in future there will be discriminated unions or some Rust enums equivalent.
If C# had the ability to define
List< struct A | B | C >
You either in for
List<IInterface> List<ABCFieldOffset>- arrays (which most collections use under the covers) will need to allocate `elements*size_of_struct`. Unless the structs are the same size, you'd have to do some level of thunking/offsetting.
- Even if they are the same size, when you're iterating the list, how would the runtime know whether it's `A`, `B`, or `C`? Structs don't have header information that can be used to infer the type, it's only whatever fields you've defined (with padding potentially). Part of 'boxing' is essentially thunking the struct by wrapping a methodtable for the struct into the object [0].
If you need something like polymorphism with structs, your best bet is to make the struct itself quasi-polymorphic (i.e. with enums) and/or start abusing generics in some fashion I haven't yet figured out.
[0] - https://mattwarren.org/2017/08/02/A-look-at-the-internals-of...
Sure, so let's make union or "struct enum" and do the same thing Rust does. Add a discriminator byte to the structure and use it to figure out type.
> If you need something like polymorphism with structs, your best bet is to make the struct itself quasi-polymorphic (i.e. with enums) and/or start abusing generics in some fashion I haven't yet figured out.
Well. I think there is the FieldOffset hack. Basically discriminated unions where programmer plays the role of compiler.
[StructLayout(LayoutKind.Explicit)]
struct DiscriminatedUnion
{
// Imagine we have enum like so
// enum
// {
// V1(byte a, byte b)
// V2(sbyte a, sbyte b)
// }
// The "FieldOffset" means that this Integer starts, an offset in bytes.
// sizeof(byte) = 1, sizeof(EnumType) = 1
[FieldOffset(0)] public EnumType TypeFlag;
[FieldOffset(1)] public byte V1a;
[FieldOffset(2)] public byte V1b;
[FieldOffset(1)] public sbyte V2a;
[FieldOffset(2)] public sbyte V2b;
}
Problem is, this is fragile. It might break on endianess.
I think that's what he is saying. That it's quite a leap from "structs are horrible in practice" to "structs are horrible if you need polymorphism in conjuction with structs" which is in my experience a pretty rare situation. If you approach structs from Rust or C++ you might expect to be able to form hierarchies of them, but approaching it from Java you are very happy to just be able to create a Point(X, Y) struct.
Even the rust type of enum structs with clever overlapping layouts I find pretty rare use for. The common use case is homogeneous data. If I have polymorphism, I'm likely going to incur some pretty expensive virtcalls etc anyway. At that point I just use classes.
In GCed languages the default seems to be that every object is referred to by pointer. Java took the "ugly" step of adding in primitive types so you could calculate 1 + 1 without causing dozens of cache misses. Struct types take this hack a step further. It generally makes the definition of the languages virtual machine a lot uglier, for example most jvm instructions operate on primitive types.
Structs are just that data stored in the same layout.
Classes are just a vtable pointer to some object on heap.
Not in C++.
An OO GC'd language "class" is a mechanism for run-time polymorphism. That's what it's for.
C++ has no "runtime" concerns of these kinds, so virtualization sits on top systems with compile-time semantics (ie., c++ classes).
If the GC language properly supported interior pointers (and first class pointers) for the GC there wouldn't be a need to force boxing in all cases. You would be able to make the decision at the point of instantiation of the object. It would make the GC more complex, but I think these days most GCs support interior pointers for other reason anyway, right?
Or am I missing something?
I feel like this is every wart in the C++ language!
As a C++-lander, I find it surprising that object allocation is tied to the object's type. IMO, the boxed/unboxed axis should be orthogonal to the type itself. It should be a property of the object instance, not of the object's type.
[<Struct>]
type Entry =
| Message
| Term
| Comment
let computeFooForEntry entry =
match entry with
| Message -> 0
| Term -> 1
| Comment -> 2(Optimized) discriminated unions have a size that is the max size of the possible types, plus a flag to indicate the type. This is the best you can hope for without boxing.
Example of that approach: https://github.com/Const-me/Vrmac/blob/1.2/Vrmac/Draw/Main/I...