Oh ... Java ... What Are We Going To Do With You?
-
@dkf said in Oh ... Java ... What Are We Going To Do With You?:
Mix in some threads and so on and you can really have a gigantic amount of memory hanging off one reference without appearing to do so to the casual reader of the code.
In theory, using
async
andawait
and the TPL instead of explicit thread creation should avoid a lot of that. In practice… I'd be more willing to predict the winning lottery numbers than predict the outcome of that situation.
-
@dkf said in Oh ... Java ... What Are We Going To Do With You?:
Fortunately, the leak didn't matter in production deployments
ara ara? how does memory leak not matter in prod?
-
@accalia Best guess: the leak only happened in Debug builds
-
@Buddy said in Oh ... Java ... What Are We Going To Do With You?:
@fbmac said:
the time java took to have generics
Java had generics before c#, which is partof why java generics suck so much worse than c#'s. They thought they could implement them as a zero-cost abstraction, but it turns out not really. C# was able to learn from java's mistake. So if java's a bit slower now on the uptake, I'm ok with that. C#'s endless syntax bloat can be annoyance of it's own.
My favourite pet peeve is how Oracle improved checked exception handling in Java 7 with try-multicatch and exception type detection, only to make checked exceptions nearly pointless in Java 8 when they introduced lambda's which cannot throw any checked exceptions.
I believe I might have a new one soon once they release their Java Modules system. It wil hurt to introduce runtime versions to JARs when almost no JAR has cleanly versioned dependencies or API "borders". I've seen it enough working with OSGi / Eclipse plugins, and Maven only knows about compile time versions.
-
@JBert said in Oh ... Java ... What Are We Going To Do With You?:
Java Modules
Why are they turning Java into Node?
-
@accalia said:
how does memory leak not matter in prod?
When the leak only happens when you undeploy or redeploy. With prod, restarting the container isn't too big a deal (if it would be a problem, you'd also run a load-balancer so losing an entire machine would be tolerable).
The code doesn't leak in service. That would be intolerable.
-
@dkf said in Oh ... Java ... What Are We Going To Do With You?:
(if it would be a problem, you'd also run a load-balancer so losing an entire machine would be tolerable).
"You'd"
-
@fbmac OK, I forgot to conditionalize the statement on also being sane. My bad.
-
@RaceProUK said in Oh ... Java ... What Are We Going To Do With You?:
@JBert said in Oh ... Java ... What Are We Going To Do With You?:
Java Modules
Why are they turning Java into Node?
Not sure if serious... but if you are, four words: hello world startup time.
There are now 104 MB worth of class files in the Java Runtime and Java doesn't have anything like .NET's references. This means that any random program might use any of those class files at random. Result: starting any random program means you have to scan all of those class files at least once to know their availability, including when all you are doing is printing "Hello, world!".
While the Hello World program is of course hyperbole, the same problem applies for any simple or even business application which doesn't have any need for Smartcards, client-side LDAP support and so on.
-
@JBert I agree with you. You can create your own functional interface that does throw the exception type you need, and use that for parameters to your own code, but that doesn't help much when all the standard library methods are using the no-throw versions. Best I've got is having a CompanyFunction interface that thows CompanyException, and has an orElse default method that returns a function. So you can do something like
CompanyFunction.of(Business::method).orElse(e -> { e.printStackTrace(); return null; });
-
@RaceProUK They're not. They're integrating something into the language that has been available to its most popular build tools for the last 14 years.
-
@JBert said in Oh ... Java ... What Are We Going To Do With You?:
There are now 104 MB worth of class files in the Java Runtime and Java doesn't have anything like .NET's references. This means that any random program might use any of those class files at random. Result: starting any random program means you have to scan all of those class files at least once to know their availability, including when all you are doing is printing "Hello, world!".
A lot of common libraries are also not part of the Java core. Instead, they are part of the Java Enterprise Edition specification and have the reference implementation and implementations that any other vendors choose to make.
A good example of this is the library to both write and interact with REST web services (JAX-RS) whose default implementation is named Jersey.
It's also important to note that the ClassPath system can be told to load arbitrary JAR files as class paths... these are the Java equivalent of References.
The ClassPath is generally managed by your build tool... which in Java tends to double as your dependency manager. JBert already mentioned Maven, which is the most popular Java build tool/dependency manager.
Speaking of JAX-RS and Jersey earlier, Java tends to have the specification and implementation of JavaEE libraries as separate JAR files so that you can specify one as a compile dependency and the other as a runtime dependency... or have the runtime dependency instead controlled by the application server instead of the application.
Jersey itself also has multiple packages. If you're manually specifying them , most of the time you'll install jersey-server or jersey-client... either one will also pull in jersey-common which contains the shared part of the code.
-
@JBert said:
Result: starting any random program means you have to scan all of those class files at least once to know their availability
It's not that many files, and scanning a JAR is just reading a ZIP index.
-
@dkf to expand on this, each class is in it'sown .class file, in a folder hierarchy correspondingto its package, so knowing what classes are available really is as simple as getting a list of the files available on the classpath. Unless there's something I'm missing?
-
@Buddy if it's a 300MB zip file, you have to read approximately 300MB of it to get all the filenames.
-
@ben_lubar said in Oh ... Java ... What Are We Going To Do With You?:
@Buddy if it's a 300MB zip file, you have to read approximately 300MB of it to get all the filenames.
When was the last time you had a 300mb jar file. I doubt even Oracle has one that size.
-
@DogsB Minecraft?
-
@ben_lubar said in Oh ... Java ... What Are We Going To Do With You?:
if it's a 300MB zip file, you have to read approximately 300MB of it to get all the filenames.
No. What is the
lseek()
system call, and why would it matter at this point in the discussion?
-
@RaceProUK said in Oh ... Java ... What Are We Going To Do With You?:
@DogsB Minecraft?
300mb of compressed class files? Very much doubt it.
-
@DogsB said in Oh ... Java ... What Are We Going To Do With You?:
@RaceProUK said in Oh ... Java ... What Are We Going To Do With You?:
@DogsB Minecraft?
300mb of compressed class files? Very much doubt it.
Minecraft 1.8.9 is 8.06 MB compressed or 11.7 MB decompressed. Certainly not 300 MB.