Why do people let their builds depend on servers they don't control? If your build is breaking because some server somewhere on the internet is down, your build was already broken, you are just now realizing it.
It's easy to say that, but that's not the default in Java and it takes a decent amount of work to completely decouple yourself. For example: it uses XML all over the place to setup and configure things and, by default, will validate these XML files against a schema at a URL. If that URL starts redirecting to a splash page (as http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd currently does), it breaks the build.
Although this shouldn't affect applications, some xml parsing libraries request the defining URI. For those that don't know, these URIs are for unique identification, not necessarily a real URL.
A couple years ago my company had something that was breaking because W3C finally started denying these requests. Whatever broke was some braindead XML thing as you say. The lame hack, which I believe is still in place, was to put w3.org in the hosts file and serve the file locally.
It was a dumb idea to use http:// as the namespace for XML DTDs. They should have used URIs that don't work when typed into a browser, like dtd:/W3C/DTD XHTML 1.0 Strict/EN instead of http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd.
Way back, in a far away land, I was working in a wholly owned subsidiary of Sun called 'FirstPerson' and we were the evolution of Project Green and had yet to become JavaSoft. I had come over from Sun proper after having been the creator, and with the help of several great engineers, implementor of a poorly named service, NIS+.
It came to pass that the FirstPerson group needed to put together a 'spec' and have it put into some form that wouldn't evolve quite so rapidly as it was impossible for partners (and even some engineers) to keep up. One of the components of that spec was creating a globally unique name space for classes if they were to exist in a global namespace. The 'natural' choice was to use DNS names, DNS was easy, it already existed, and as Bill Joy pointed out "If sun.com doesn't exist we've got bigger problems than where to find our class instances." The counter argument that 'protocols live forever' and another that we should not tie the core of the language to the corporate entity that birthed it, were not compelling. The tertiary argument that as name spaces went a 'layered system', one where a level of abstraction was added to allow for changing the underlying space, would be better than tying it to DNS names, was also unsuccessful. The choice stood.
Its always interesting to 'win' an argument over 15 years later. Doesn't change anything of course, one can either take pleasure in knowing they were right when others were wrong, or feel guilt at not having been more eloquent or convincing in their argument. Of course neither really does any good.
But if you are out there and you are thinking to 'copy' the Java scheme of naming things based on DNS names. Please reconsider, nothing is forever unless you can control all the moving parts.
Tons of stuff in Java is infested with hard coded URIs and you will never find them all. For example to load properties in XML format the XML doctype is the following little gem: <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd>; . http://download.oracle.com/javase/1,5.0/docs/api/java/util/P... claims the URI isn't loaded- but that is only if you are using the exact set of XML libraries in the exact classpath order they were thinking about when they wrote that promise (especially on the IBM JVM which isn't smart enough to put the system copy of the XML libraries in a mangled namespace to prevent the user from accidentally overriding then when they and new XML implementations to the classpath). Frankly I'd like to see all of this stuff broken and then excised.
None of my builds are breaking, but it certainly saddens me a bit. Remember when everyone dreamed of having a SPARC-station? We really believed it would be Sun that took *NIX to the masses and that the company's RISC processors would dominate the price/performance game.
So true ... though the Apple masses don't tend to recognize they're using UNIX. And ARM is a great technology that's also pushed others. Would Atom exist if ARM hadn't been pushing the low-power agenda?
If Solaris was ever successful on that scale the masses wouldn't recognize it was Unix either. The masses just don't care about geeky stuff like that, for better and for worse.
OS/X, iOS, and android have very much taken unix/linux to the masses. They took somewhat of a roundabout way to get there, but they're doing a pretty good job as it turns out.
Ugh. I remember hacking my "web.xml" and the like files at home years ago so that I could work offline. I simply pointed them to local copies of the files with a "file:" URI. Not sure what the least-evil fix for this is, though.
Most Java projects depend on XML documents, which contain a URL telling you where the "document definition" (DTD) lives. That DTD is / can be used to verify that the XML is valid.
If the URL starts failing or serving up different content then your builds may fail.
java.sun.com is down and redirects to Java-related section of Oracle's website. Other than that all the DTDs and XSDs are in usual location, so there is no need for panic.
Reminds me a bit of when one of the Java 6 point updates changed the vendor name from Sun to Oracle. That broke a lot of older applets that were coded to require Sun Java over Microsoft or Netscape Java, and they had to revert it back.
It was in the book Ship It (IIRC) that put the proposition down to putting a project at risk because you wanted to save on purchasing storage instead of downloading andhosting external packages (libraries); penny smart and pound foolish.
