Re:Java.sun.com is down - breaking builds across the land
by johnnyo on Monday October 10, 2011 @11:19AM
(#3094125)
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.
Re:Java.sun.com is down - breaking builds across the land
by drewvolpe on Monday October 10, 2011 @11:54AM
(#3094302)
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.
Re:Java.sun.com is down - breaking builds across the land
by mrspandex on Monday October 10, 2011 @11:56AM
(#3094311)
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.
Re:Java.sun.com is down - breaking builds across the land
by funkah on Monday October 10, 2011 @12:58PM
(#3094646)
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.
Re:Java.sun.com is down - breaking builds across the land
by jrockway on Monday October 10, 2011 @01:27PM
(#3094812)
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.
Re:Java.sun.com is down - breaking builds across the land
by ChuckMcM on Monday October 10, 2011 @02:13PM
(#3095040)
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.
Re:Java.sun.com is down - breaking builds across the land
by jmount on Monday October 10, 2011 @11:50AM
(#3094278)
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.
Re:Java.sun.com is down - breaking builds across the land
by smoyer on Monday October 10, 2011 @11:34AM
(#3094191)
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.
Re:Java.sun.com is down - breaking builds across the land
by smoyer on Monday October 10, 2011 @01:37PM
(#3094855)
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?
Re:Java.sun.com is down - breaking builds across the land
by sjs on Monday October 10, 2011 @02:47PM
(#3095185)
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.
Re:Java.sun.com is down - breaking builds across the land
by InclinedPlane on Monday October 10, 2011 @04:11PM
(#3095583)
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.
Re:Java.sun.com is down - breaking builds across the land
by Roboprog on Monday October 10, 2011 @03:13PM
(#3095300)
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.
Re:Java.sun.com is down - breaking builds across the land
by xsmasher on Monday October 10, 2011 @01:05PM
(#3094689)
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.
Re:Java.sun.com is down - breaking builds across the land
by pregzt on Monday October 10, 2011 @11:59AM
(#3094320)
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.
Re:Java.sun.com is down - breaking builds across the land
by smackfu on Monday October 10, 2011 @12:40PM
(#3094552)
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.
Re:Java.sun.com is down - breaking builds across the land
by shaggyfrog on Monday October 10, 2011 @08:20PM
(#3096498)
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.
No build should need network access.
The W3C has major problems with browsers doing this for DTDs: http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dt...
Oh well.
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.
HTML 4.01 documents are supposed to start with:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd>;
The intent was not for web browsers to hit up the W3C every time they loaded a web page.
If they all start with http:// it shouldn't be too difficult to search for them.
Sigh :(
Stupid hack: add a java.sun.com DNS entry on the build server to point to local and host the static files on the build server.
If the URL starts failing or serving up different content then your builds may fail.
For example the mentioned http://java.sun.com/dtd/properties.dtd can be found with no issues. Other example is http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd that sits in usual location and I don't expect anyone was going to touch it.
http://en.wikipedia.org/wiki/XML_Catalog