4 ms·
The last part advises to be feature conservative to avoid promises all together. For that look to enterprise software where backwards compatibility is a legal a
by dexwiz 5y ago
The last part advises to be feature conservative to avoid promises all together. For that look to enterprise software where backwards compatibility is a legal agreement. This carries a bunch of alternative issues.
- eatYourFood 5y agoThe last part advises being feature conservative to avoid promises altogether. For that, look to enterprise software where backwards compatibility is a legal agreement; this carries a bunch of alternative issues. I attempted to fix your questionable grammar as to make your writing easier to understand.
- PufPufPuf 5y agoThe original is understandable. The person might not be a native speaker and calling their grammar "questionable" is too harsh, especially on an online forum. Also I don't think some of your "fixes" are necessary or meaningful.
- eatYourFood 5y agoYou cannot say “this” straight after a full stop (period). Get over it. The commenter is a native speaker and I had to read what they said more than once to understand.
- Talanes 5y agoUsing semicolons to join sentences together isn't a super common style of writing for online comment sections. If you are unable to read a paragraph composed of shorter, more discrete sentences, that's on you.
- eatYourFood 5y ago> That’s on you So they get a free pass for maybe not being a native English speaker but I don’t? Inb4 ‘but you criticised them’ - that’s not related to your attack on me.
- scubbo 5y ago> I attempted to fix your questionable grammar as[sic] to make your writing easier to understand Muphry's Law strikes again! I think you meant "...so as to make..." (+1 to the other reply - the original was perfectly readable)
- eatYourFood 5y agoIdeally you’d just remove the word ‘as’ for the most concise and correct sentence.
- floatboth 5y ago"Features" is a way too abstract thing to blame, tbh. The elephant in the room here is the excessive dynamism allowed by default on the JVM platform. How many applications actually need fancy classloaders? Why isn't every step to get there - "loading a class from anywhere that isn't my JARs", JNDI, JNDI's LDAP backend, etc. - an explicit opt-in flag to the VM? Java's wide-open defaults are what made the blast radius of this huge.
- krzyk 5y agoThere are popular languages that have `eval()`, so I don't see why blame Java only?
- jpfed 5y agoDon't get us wrong, eval() is terrible too.
- zmmmmm 5y agoJava's dynamic classloaders were one of it's original tantalising features. That you could have code from one place running somewhere else - "agents" could literally send their bytes to a device to execute there, run there and then erase themselves when they were done. It sounds crazy these days but it was all meant to be held together by the security model - built in at the core it was safe to let foreign byte code execute locally because the completely managed VM could enforce a security sandbox that allowed the code to do only exactly what it was meant to. In some ways that is where this and all those features fell down ... if log4j had constrained those classes within a security sandbox it wouldn't matter what they did. But nobody understands or uses Java security permissions. The whole system is byzantine and drives people crazy whenever they do run into it. But if it had worked you could be asking the question, "why did log4j allow the permission for the remote code to do bad things" rather than "why was remote code allowed to execute".
- deleted 5y ago[deleted]
- dvhh 5y agoMeaning that Log4J is certainly not the only library to have the problem, maybe the one with the larger footprint, what about JSP ?