• MrTroy (unregistered) in reply to Charles F.
    Charles F.:
    Steve The Cynic:
    And in the article, we saw a good demonstration of why they should not be there.
    Everyone agrees that the JDBC library should not have been put where it was.
    Unfortunately not everyone agrees.

    Anyone who's ever had to upgrade a library version would know that relying on the jar the happens to currently be in the lib/ext folder is a recipe for disaster, but it should be apparent that it might be worth forgiving and educating people who think it's "best practice" to "install" JDBC drivers as extensions.

    CAPTCHA: tego... because lots of technology websites that should know better think that JDBC drivers are meant tego there...

  • (cs) in reply to Ragnax
    Ragnax:
    ANON:
    Each platform has its own dependency hell. Java didn't find a perfect solution, but neither did anyone else, so how can you blame it?

    .NET found a good solution with multiple loading contexts, loading into isolated application domains, using assembly version redirects, etc.

    It even has a special and quite verbose logging facility you can query for runtime type and assembly binding errors related to API/ABI type compatibility, duplicate type definitions, etc. and in general it will point you straight and squarely at the culprit.

    So did Java: it also has multiple loading contexts, custom classloaders, ability to prepend jars to the bootclasspath... ANON didn't say that no platform had a good solution, just that none of them is perfect.

  • JAPH (unregistered)

    Including the JDBC JARs in jre/lib/ext may or may not be a WTF, but the way I read the story, someone put the application JAR in there - a big WTF.

  • (cs) in reply to Your Naem
    Your Naem:
    You fool! The CEO's e-mail application requires the old genCorejdbc.jar in order to parse XML from an access database stored on the network share! You stole his internet and this is affecting productivity!

    Yeah, now the CEO can't bother people by email continuously productivity's gone through the roof! >;->

  • (cs) in reply to JAPH
    JAPH:
    ... the way I read the story, someone put the application JAR in there - a big WTF.

    I think it's a customised version of the JDBC drivers, or possibly a data access wrapper. I can kind of understand how you could consider that a "platform extension"; why you'd stick it in /lib/ext without documenting the fact OTOH is beyond me.

    Also, for those ragging on Andrew's troubleshooting abilities, the story doesn't say Andrew was a programmer. He "supported" genCore. When he struggled to fix it he contacted one of the engineers. And frankly, a support tech who's willing to ask the appropriate colleagues for assistance when they can't fix an issue is someone I'd want working with me.

  • Scourge of Programmers! (unregistered) in reply to AP²
    AP²:
    Rails is convention over configuration.

    The JVM is configuration over configuration.

    You really think jvm is bad, try deploying a RESTful architecture over WCF.

  • (cs) in reply to pjt33
    pjt33:
    Ragnax:
    ANON:
    Each platform has its own dependency hell. Java didn't find a perfect solution, but neither did anyone else, so how can you blame it?

    .NET found a good solution with multiple loading contexts, loading into isolated application domains, using assembly version redirects, etc.

    It even has a special and quite verbose logging facility you can query for runtime type and assembly binding errors related to API/ABI type compatibility, duplicate type definitions, etc. and in general it will point you straight and squarely at the culprit.

    So did Java: it also has multiple loading contexts, custom classloaders, ability to prepend jars to the bootclasspath... ANON didn't say that no platform had a good solution, just that none of them is perfect.

    Java has a lot of similar solutions, but I wouldn't exactly call all of them good. Hence the WTF from the article.

  • anonymous (unregistered) in reply to ZoomST
    ZoomST:
    RFoxmich:
    > “No, it’s not.” Christine, pale, looked to him out of the corner of her eye. “Who put that jar file there in the first place?”

    I did muhuhuhuhahahahahah!!! ;-)

    Ooooh! Spooky! Just ideal for Halloween, I think. Maybe it can be improved: “Who put that jar full of human blood there in the first place?” Trigger or threat? :)
    Trigger or thread?

    Even better!

  • Andy (unregistered) in reply to chubertdev

    Man... All the Java hate over a simple and minor classpath issue! You've never had an issue with an app using an older version which is in the GAC rather than the local one? This issue isn't much different.

  • (cs) in reply to Andy
    Andy:
    Man... All the Java hate over a simple and minor classpath issue! You've never had an issue with an app using an older version which is in the GAC rather than the local one? This issue isn't much different.

    I did, and it took me two seconds to look at the version specificed in the web.config to figure it out. Not having to know that another directory takes precedence over the local version without raising any issue about ambiguity.

  • (cs)
    “No, it’s not.” Christine, pale, looked to him out of the corner of her eye. “Who put that jar file there in the first place?”

    Could it be.....

    Satan?

  • This guy (unregistered) in reply to faoileag
    faoileag:
    Having done that, am I right to assume that... ... I, the application developer, do not have any control over what .jar files might exist in jre/lib/ext/? ... the .jar files in jre/lib/ext/ are loaded prior to my application's .jar files, establishing a method-lookup-up precedence chain?

    I don't know if it will fix the jre/lib/ext issue, but I think it is possible to write your own class loader

  • AN AMAZING CODER (unregistered)

    From the first sign of trouble, I was thinking: "Why not just remove the JVM, reinstall the latest supported version, and redeploy instead of all of this nonsense?"

    Obviously TRWTF is a bunch of TESTING ENGINEERS who let a machine sit around wasting space and time because they don't know how to troubleshoot issues.

  • AN AMAZING CODER (unregistered) in reply to chubertdev
    chubertdev:
    Andy:
    Man... All the Java hate over a simple and minor classpath issue! You've never had an issue with an app using an older version which is in the GAC rather than the local one? This issue isn't much different.

    I did, and it took me two seconds to look at the version specificed in the web.config to figure it out. Not having to know that another directory takes precedence over the local version without raising any issue about ambiguity.

    Except that class loading order is a basic feature of the JVM (and of application servers) which experienced developers should know about.

    Instead, these dudes just gave up when their application didn't work on some fucked-up machine.

  • AN AMAZING CODER (unregistered) in reply to chubertdev
    chubertdev:
    Steve The Cynic:
    ANON:
    Nice story, but actually I see no WTF.
    You don't think that arcane rules about how classes get loaded are sufficiently WTFy for you? Think, man, think! The fact that there can be magical invisible objects that silently override the ones you put there explicitly is a WTF of the highest order.

    Actually this one made me think of an Elegant Syntax Error.

    That's the key. That it's silent. You couldn't compile a .NET project with an ambiguous reference.

    You can't compile a Java application with an "ambiguous reference" either.

    You're just bound to prove how superior .NET is to Java, without actually understanding Java, aren't you?

  • (cs) in reply to AN AMAZING CODER
    AN AMAZING CODER:
    chubertdev:
    Steve The Cynic:
    ANON:
    Nice story, but actually I see no WTF.
    You don't think that arcane rules about how classes get loaded are sufficiently WTFy for you? Think, man, think! The fact that there can be magical invisible objects that silently override the ones you put there explicitly is a WTF of the highest order.

    Actually this one made me think of an Elegant Syntax Error.

    That's the key. That it's silent. You couldn't compile a .NET project with an ambiguous reference.

    You can't compile a Java application with an "ambiguous reference" either.

    You're just bound to prove how superior .NET is to Java, without actually understanding Java, aren't you?

    You're right, the article is a complete lie. :facepalm:

  • (cs) in reply to AN AMAZING CODER
    AN AMAZING CODER:
    chubertdev:
    Andy:
    Man... All the Java hate over a simple and minor classpath issue! You've never had an issue with an app using an older version which is in the GAC rather than the local one? This issue isn't much different.

    I did, and it took me two seconds to look at the version specificed in the web.config to figure it out. Not having to know that another directory takes precedence over the local version without raising any issue about ambiguity.

    Except that class loading order is a basic feature of the JVM (and of application servers) which experienced developers should know about.

    Instead, these dudes just gave up when their application didn't work on some fucked-up machine.

    "That's just the way it's always worked."

    Things like Java are a complete POS when they don't work as you would expect them to without reading the documentation. Having to read every part of Java's documentation to find something that works so counter to intuition is a huge WTF, and part of why I'm glad that I've never had to touch Java, other than working with applications that take up a hundred times more memory than necessary.

  • anonymous (unregistered) in reply to AN AMAZING CODER
    AN AMAZING CODER:
    You can't *compile* a Java application with an "ambiguous reference" either.
    I think you misspelt "without". Since, by definition, every reference apparently means "this jar, unless there's one in this folder over here, in which case, use that one."
  • SD (unregistered) in reply to Steve The Cynic

    'The principal oddity is the behaviour of #include "file.h". This loads from the current directory'

    That's correct.

    'The answer is, "the directory that contains the file doing the include,"'

    That's incorrect. It's relative to the current working directory which invariably is the same as the file doing the include. eg:

    cd foo cc c.c ^^^oki

    cd .. cc foo/c.c ^^^fails to find foo/file.h

  • (cs) in reply to anonymous
    anonymous:
    AN AMAZING CODER:
    You can't *compile* a Java application with an "ambiguous reference" either.
    I think you misspelt "without". Since, by definition, every reference apparently means "this jar, unless there's one in this folder over here, in which case, use that one."

    Thank you. I'm glad that someone gets it.

  • Norman Diamond (unregistered) in reply to SD
    SD:
    'The principal oddity is the behaviour of #include "file.h". This loads from the current directory'

    That's correct.

    'The answer is, "the directory that contains the file doing the include,"'

    That's incorrect. It's relative to the current working directory which invariably is the same as the file doing the include. eg:

    cd foo cc c.c ^^^oki

    cd .. cc foo/c.c ^^^fails to find foo/file.h

    C compilers exist on machines that don't have working directories, which is why the answer (according to the standard) is that there is some association between the file doing the include and the file being included.
  • hydroxichloraquine (unregistered)

    chloroquine side effects https://chloroquineorigin.com/# hcqs pill

  • buy cialis usa (unregistered)

    https://cialiswithdapoxetine.com/ generic cialis

  • odiaeubz (unregistered)
    Comment held for moderation.
  • hjitvuea (unregistered)
    Comment held for moderation.

Leave a comment on “The Curse of the Warped Bootstrap”

Log In or post as a guest

Replying to comment #:

« Return to Article