On Wednesday, May 4, 2016 at 8:43:00 PM UTC-4, Andy Fingerhut wrote: > > > > On Wed, May 4, 2016 at 5:46 AM, Fluid Dynamics <a209...@trbvm.com > <javascript:>> wrote: > >> >> Also, nothing you wrote addresses the other complaint I have, which is >> that stuff shouldn't just magically stop working one day while it's sitting >> in a drawer unused, and that there's not even an *excuse* for it to do so >> if it's *software*. >> > > I have heard a long history of issues where a program written to run on > JVM 1.x does not work when run on JVM 1.y where y > x. While the byte code > itself of the application should be portable to later JVM's, I believe that > most or all of these compatibility issues are due to changes in the Java > library. > > Your situation is quite similar to a case where you have an application > that runs fine on Windows 7, but no longer runs correctly when you install > Windows 10. The application did not change, but the Windows APIs it relies > on likely did, in some way the application doesn't handle. >
Perhaps, though I'm mystified that such a thing should show up as selective networking problems (timeout connecting to REPL, and inability to "see" a proper subset of the things it's looking for in maven repositories when told to update itself) rather than as glaringly obvious things (NoSuchMethodError during startup, or VerifyError, or other Errors caused by missing methods or changed method signatures or such). Pretty much requires Oracle to have changed one or another networking method's parameters in a way that the signature is unchanged, but the semantics have changed (e.g. from URL url, int timeout, int port to URL url, int port, int timeout, or something like that). And even then, why would that make it fail to find *some* dependencies during an update, but still succeed in connecting and downloading *other* dependencies? That Oracle would have done something analogous to swapping "int port, int timeout" in a minor-version-bump is already unlikely (API-breaking changes *should* have major version number increases); that they would introduce a semantic change that is sensitively dependent on the URL parameter, such that localhost and *some* remote URLs fail with the obsolete calling parameter order while others *still work*, is frankly inexplicable. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
