●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Catch up on stories from the past week (and beyond) at the Slashdot story archive
Forgot your password?
Close
This discussion has been archived.
No new comments can be posted.
Load All Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
bybradley13 ( 1118935 ) writes:
IMHO, these problems stem from the following source problems:
- Incompetent developers. Look at the number one problem, number one for years now: injection. I teach students how to avoid this the first time they touch a database, which is typically in year two of their degree program. It doesn't matter: half of them still write injectable queries, even though using "prepared statements" isn't any more complex. The thing is: there is so much code to be written, that even these students - who evidently don't u
byswilver ( 617741 ) writes:
Too many frameworks... that's a good one. You're worried about the vulnerabilities in some of the most stable, highly scrutinized, fully unit tested and secure frameworks Java has on offer and because of that... you roll your own.
I guess I know what is really wrong with the industry: developers that think they can create their own framework, replacing several dozen man years of coding, debugging and testing in just a few days -- and then having the arrogance to think it will contain less vulnerabilities ri
byDNS-and-BIND ( 461968 ) writes:
You are assuming without any justification that the entire suite of functionality these frameworks provide is required. It is not. We just need one thing, but to implement that one thing, we need to massively expand our attack surface by bringing in huge amounts of foreign code. Your argument is that by reimplementing this entire framework vulnerabilities will be introduced, which is correct but it does not address the problem at hand. We aren't reimplementing the entire framework.
byswilver ( 617741 ) writes:
The example given was Guice, which is a DI framework. To implement DI you need to write at least a couple of thousand lines of code, using not every day concepts like annotation scanning, reflection, thread safety, etc. That's a non-trivial amount of work requiring a solid test suite to boot.
Other than that I totally agree with you. I cringe every time I see some huge framework imported just to use one of its utility functions... Sure, a framework is great if over half the code needs it and it saves a lot of work, but adding a new huge framework to a huge existing code base without thought to save writing a dozen lines of code? I reject those commits when I'm leading the project.
Parent
twitter
facebook
byK. S. Kyosuke ( 729550 ) writes:
To implement DI you need to write at least a couple of thousand lines of code, using not every day concepts like annotation scanning, reflection, thread safety, etc.
Hahahaha
Java
Oh, fuck. Well, here you may have your problem.
byswilver ( 617741 ) writes:
Oh, another one of those "the language is your problem" people.
I suppose you also say stuff like:
"... if we had written it in X using this 3 month old framework then we wouldn't be in this mess."
"You don't need a compiler, just write unit tests with full coverage."
"... in language X you can write 30% less lines of code, resulting in 30% less mistakes!"
"My programming speed is bottlenecked by the amount of characters I need to type..."
Anyway, thanks I'll give your valuable opinion the attention it deserves.
byK. S. Kyosuke ( 729550 ) writes:
The first, second and fourth quoted sentence don't seem to make any sense whatsoever. The third is sometimes commonly extrapolated from the assumption that bug density is independent of language, but I'm not sure how much that is accepted.
Regarding "the language is your problem", there's many decent environments out there, but some are just FUBAR. Regarding Java and the frameworks trying to fix it in particular, the old maxim that "programming languages should be designed not by piling feature on top of fea
● current threshold.
byswilver ( 617741 ) writes:
I wrote a simple DI framework, it does take a bit more than that for even basic functionality. However, I'm interested so if you have some link or code. Perhaps it will offer some inspiration.
I would have used an existing framework, but none of the ones I found supported changing dependencies at runtime (when loading a plugin or something). Both Guice and Spring are very much static
bylogicpeters ( 1981740 ) writes:
His original statement that Guice brings in Spring (through transitive dependencies) is a complete falsehood. Check it out yourself in the Maven repo -- I just did, or roll up a simple project and see what it brings in. Both Guice and Guava are very lightweight libraries and don't bring in many transitive dependencies, if any. If they did, they would not be popular at all. Library developers are highly aware of the need to keep dependency trees light and minimal -- and you do a disservice by spreading
●rrent threshold.
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Slashdot
●
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Working...