Live data from Hacker News

Java is fast, code might not be

jvogel.me

241–250 of 259 posts

Re: Java is fast, code might not be

#241
post #219

Earlier quoted context omitted.

Have always really liked Java, but yeah, Spring overall has been terrible for the language. Autowiring is against the principles of a typesafe programming language - Don't make me guess what what object is going to be attached to a reference. And if you do, at least figure out what linked object is at compile time, not at run time. Spring autowiring makes Java seem as a whole unnecessarily complex. Think it should be…

> Autowiring is against the principles of a typesafe programming language Constructor autowiring is the application of the inversion of control and dependency injection pattern. If there was no autowiring, you could autowire the components together just the same with normal code calling constructors in the correct order. Spring just finds the components and does the construction for you.

Yeah, for me at least, personally believe inversion of control should be used more surgically instead of blanketing the system with it. On the one hand, freeing your application layer from direct dependencies with the lower-level objects conceptually seems like a good idea, but think in practice, this is hardly ever helpful especially when used for every dependency.

At least from my experience, seems like we don't change the objects we use that often, that once a object is set on a reference var, a very, very large majority of them won't change.

And because of this, seems like that for most objects dependencies, we should just new them directly, and if later on we do need to change them, then at that time, we can refactor the code to use more abstraction (like inversion of control) to break the direct dependency, but only for the code that needs it (or if there is a important situation where having a direct dependency could be highly problematic in the future, like to a DB provider).

It's like the performance optimization problem. One guideline that is often quoted is that it's best not to over optimize the performance of your code, until you actually can test it in real-world test cases, because you very often optimize things that aren't the bottleneck. Same with the over usage of inversion of control. Spring makes it so we're using IOC everywhere, but it's just adding unnecessary complexity.

Think that if inversion of control is used, should be used mainly at a higher level, for components instead of on every class like often happens. But even for components, think you should be careful when deciding to do so.

... and agreed, you could just use the factory pattern instead of Spring.

Re: Java is fast, code might not be

#242
I feel like most of these things can be avoided if people just think what they are going to write in abstract terms before writing the code. If they do it like this, I think they are going to choose the best Data Structure for the job, which is what most of this article was.

Re: Java is fast, code might not be

#243
post #234

Earlier quoted context omitted.

Lets look at Java in modern day. * Most mature Java project has moved to Kotlin. * The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java. * Log4shell, amongst other vulnerabilities. * Super slow to adopt features like async execution * Standard repo usage is terrible. There is no point in using Java anymore. I don't agree that Rust is a replaceme…

> Python, Node, and C/C++ extensions to those, you can do everything you need. Or you can use Java and have libraries that cover almost anything provided in those languages, having access to a massive pool of labour when needed. > * Log4shell, amongst other vulnerabilities. As if no Python, JS, C/C++ libraries ever had vulnerabilities? That's a non-sequitur, every ecosystem has security issues, the most important asp…

> Java and have libraries that cover almost anything provided in those languages,

This is pretty funny.

or example, the other day I wrote a menu for mac os using rumps. Simply pip install rumps, write code, run, boom Mac os menu. Let me know when I can do the equivalent for java, or any other "performant" language.

>As if no Python, JS, C/C++ libraries ever had vulnerabilities?

Comparing the severity of log4shell to any python vulnerability is beyond crazy.

You have the Apache foundation, pushing its logging library as the industry standard, and multiple people saw no problem with not only the idea of a log statement being able to execute arbitrary code from the internet, but also making it the default behavior.

If at that point, everyone would instantly abandon any software from Apache in Java, I would have more respect for Java devs. But of course, they can't, because the ecosystem is so small that there is no replacements, so everyone is forced to cuck out to Apache, and who knows what and when other idiotic decision they are going to make.

And as a reminder, this used to be a thing https://www.reddit.com/r/java/comments/19s23g/online_counter...

There are plenty of other issues to cover on Java, but the log4shell pretty much is indefensible. Even if Im wrong about everything else, my argument still stands on that alone.

Re: Java is fast, code might not be

#244
post #234

Earlier quoted context omitted.

> Python, Node, and C/C++ extensions to those, you can do everything you need. Or you can use Java and have libraries that cover almost anything provided in those languages, having access to a massive pool of labour when needed. > * Log4shell, amongst other vulnerabilities. As if no Python, JS, C/C++ libraries ever had vulnerabilities? That's a non-sequitur, every ecosystem has security issues, the most important asp…

> Java and have libraries that cover almost anything provided in those languages, This is pretty funny. or example, the other day I wrote a menu for mac os using rumps. Simply pip install rumps, write code, run, boom Mac os menu. Let me know when I can do the equivalent for java, or any other "performant" language. >As if no Python, JS, C/C++ libraries ever had vulnerabilities? Comparing the severity of log4shell to…

Ok, don't use Java, it's fine :)

Re: Java is fast, code might not be

#245
post #219

Earlier quoted context omitted.

> Autowiring is against the principles of a typesafe programming language Constructor autowiring is the application of the inversion of control and dependency injection pattern. If there was no autowiring, you could autowire the components together just the same with normal code calling constructors in the correct order. Spring just finds the components and does the construction for you.

Yeah, for me at least, personally believe inversion of control should be used more surgically instead of blanketing the system with it. On the one hand, freeing your application layer from direct dependencies with the lower-level objects conceptually seems like a good idea, but think in practice, this is hardly ever helpful especially when used for every dependency. At least from my experience, seems like we don't ch…

For large applications, having the implementation (or multiple implementations) of certain functionality decoupled from the code using it, improves maintainability and configurability of the application. That is where inversion of control helps. And then manually writing the instatiation, scoping, dependency ordering and cleanup code to manage all of that is not useful to write yourself. Any dependency injection framework will work, although Spring is well used and has many integrations.

Re: Java is fast, code might not be

#246
post #226

Earlier quoted context omitted.

Lets look at Java in modern day. * Most mature Java project has moved to Kotlin. * The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java. * Log4shell, amongst other vulnerabilities. * Super slow to adopt features like async execution * Standard repo usage is terrible. There is no point in using Java anymore. I don't agree that Rust is a replaceme…

> Most mature Java project has moved to Kotlin. Demonstrably false, not even close Re Gradle using groovy/kotlin: so what? Gradle is not a standard any more than Maven, and java is not primary used as a scripting language, so it makes sense that it has a different language for its config files? What's the deal here? Show me a language without vulnerabilities. It has virtual threads for quite some times and it is a mu…

>Demonstrably false, not even close

Are you arguing that the Android Ecosystem uses Java? Because it most certainly moved to Kotlin, and will soon move even off of that.

>Show me a language without vulnerabilities.

There is a scale of vulnerability severeness in terms of severity and how the vulnerability was introduced.

Most every language has libraries with bugs that can create vulnerability. Log4shell wasn't a bug - it was introduced intentionally without anyone at Apache looking at it and thinking that it was wrong, knowing that log4j is the most widely used logging library for java.

Re: Java is fast, code might not be

#247
post #244

Earlier quoted context omitted.

> Java and have libraries that cover almost anything provided in those languages, This is pretty funny. or example, the other day I wrote a menu for mac os using rumps. Simply pip install rumps, write code, run, boom Mac os menu. Let me know when I can do the equivalent for java, or any other "performant" language. >As if no Python, JS, C/C++ libraries ever had vulnerabilities? Comparing the severity of log4shell to…

Ok, don't use Java, it's fine :)

Its not about personal use, its about people getting facts wrong about Java.

Re: Java is fast, code might not be

#249
post #245

Earlier quoted context omitted.

Yeah, for me at least, personally believe inversion of control should be used more surgically instead of blanketing the system with it. On the one hand, freeing your application layer from direct dependencies with the lower-level objects conceptually seems like a good idea, but think in practice, this is hardly ever helpful especially when used for every dependency. At least from my experience, seems like we don't ch…

For large applications, having the implementation (or multiple implementations) of certain functionality decoupled from the code using it, improves maintainability and configurability of the application. That is where inversion of control helps. And then manually writing the instatiation, scoping, dependency ordering and cleanup code to manage all of that is not useful to write yourself. Any dependency injection fram…

Yeah, I get the idea, abstractions allow decoupling. But, think that it should be used in a thoughtful way - there is quote from the original Design Patterns book that said something like a careful considered use of Design Patterns should make the system easier to work with, or something like that (sorry, don't have it on hand).

We can go back and forth on this, so will just say, in my opinion, Spring autowiring overall doesn't provide enough benefit versus its downsides, which to me are: increased complexity and doesn't work well enough (it should be easier to debug autowiring problems for one).

You seem very knowledgeable about design, and, of course, you're entitled to your opinion, so seems like we'll probably just have to disagree on this:)

Re: Java is fast, code might not be

#250
post #226

Earlier quoted context omitted.

> Most mature Java project has moved to Kotlin. Demonstrably false, not even close Re Gradle using groovy/kotlin: so what? Gradle is not a standard any more than Maven, and java is not primary used as a scripting language, so it makes sense that it has a different language for its config files? What's the deal here? Show me a language without vulnerabilities. It has virtual threads for quite some times and it is a mu…

>Demonstrably false, not even close Are you arguing that the Android Ecosystem uses Java? Because it most certainly moved to Kotlin, and will soon move even off of that. >Show me a language without vulnerabilities. There is a scale of vulnerability severeness in terms of severity and how the vulnerability was introduced. Most every language has libraries with bugs that can create vulnerability. Log4shell wasn't a bug…

> Are you arguing that the Android Ecosystem uses Java

Now you are just arguing in bad faith. Who talks about Android, which historically lagged a decade behind OpenJDK and not particularly good at being up to date even today, so people moved to kotlin vs java without goddamn lambdas? Is that your argument? Especially that it's a tiny segment compared to the vastness of web backends. Are Google's, apple's, alibaba's backends, amazon cloud etc insignificant in your mind?

And you may want to browse the list of vulnerabilities, there are plenty interesting ones.

Post reply on HN