So for getters and setters a Jit can inline the function call and in the end you have a direct memory access.
In your example you have to cast because URLConnection could be a HttpURLConnection or JarURLConnection.
But again a good Jit would speculate that it is always a HttpURLConnection and deoptimize if not.
Re:JITs are un-ergonomic
by imtringued on Sunday March 29, 2020 @09:29AM
(#22718843)
The JVM also has full information about the class hierarchy at runtime. If you add a class that overrides a function it will deoptimize that overriden function to a virtual function but otherwise the JVM will just treat it as a static function and inline it if necessary.
In modern Java I don't see why you would directly use an HttpURLConnection. The stdlib provides an easy to use HttpClient.
https://docs.oracle.com/en/java/javase/11/docs/api/java.net....
> I mean, how many connection types exist?
Two? https://developer.android.com/reference/java/net/URLConnecti...
SomeClass x = new SomeClass();
won't make anything slower (ignoring auto for now)
Now, I read Java code and I can't help but wonder how things are harder
For example, setters and getters, what would be a simple memory write becomes a function call. Not complaining when you actually need it.
Reading the examples here (and those are not too bad) https://developer.android.com/reference/java/net/HttpURLConn... it seems you have to actually fight the API to get anything done
Why do you need to cast the return of a url.openConnection() to a HttpURLConnection? (I mean, how many connection types exist?)