Java.sun.com is down - breaking builds across the land

http://java.sun.com

by drewvolpe • 15 years ago

67 40 15 years ago

java.sun.com

johnnyo• 15 years ago

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.

jmount3• 15 years ago

You are right- nobody should knowingly allow this sort of dependency. Except Sun hard coded a few of these in.

drewvolpe2• 15 years ago

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.

Bootvis• 15 years ago

It seems to be fixed now.

justincormack• 15 years ago

Validating parsers should not be downloading these, they should have local copies. And you should probably not validate against a dtd anyway.

No build should need network access.

smoyer2• 15 years ago

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.

Sigh :(

jonhohle• 15 years ago

Apple took UNIX to the masses. ARM (Acorn RISC Machine) has dominated the price/performance. We've arrived, but Sun didn't get us here.

smoyer2• 15 years ago

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?

InclinedPlane• 15 years ago

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.

vetler• 15 years ago

I don't get it. Why would your builds break?

xsmasher• 15 years ago

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.

burgerbrain• 15 years ago

Does this mean that those builds would fail on un networked machine under normal circumstances?

jmount3• 15 years ago

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.

naner• 15 years ago

Tons of stuff in Java is infested with hard coded URIs and you will never find them all.

If they all start with http:// it shouldn't be too difficult to search for them.

andrewf• 15 years ago

The point of those hardcoded URIs is to be a unique identifier. You really aren't supposed to load them all the time.

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.

jmount3• 15 years ago

Yes, but under many common circumstances a lot of libraries load the DTD. Really should have used a different name space to make the idea more clear.

mrspandex• 15 years ago

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.

The W3C has major problems with browsers doing this for DTDs: http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dt...

funkah• 15 years ago

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.

pregzt• 15 years ago

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.

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.

vegai• 15 years ago

Sorry for being slightly flippant, but I would think that panic is a good idea if one is dependent on Java.

drewvolpe2• 15 years ago

Back online now. Interesting that it was down for 15+ hours and within 30 minutes of posting to HN it was fixed.

smackfu2• 15 years ago

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.

jrockway• 15 years ago

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.

Oh well.

TylerE• 15 years ago

I thought the whole point of a DTD was that a validating parser could download it, and, well, validate.

Ralith• 15 years ago

There are other ways to locate and request a file than by trivial HTTP GET.

ChuckMcM• 15 years ago

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.

0x12• 15 years ago

He was right about Sun having bigger problems though.

smackfu2• 15 years ago

What's the other half of this? Some config file that maps "W3C/DTD XHTML 1.0 Strict/EN" to a local copy of the DTD?

premchai21• 15 years ago

Viz. XML Catalogs: http://www.oasis-open.org/committees/entity/spec-2001-08-06....

msie• 15 years ago

I thought this was so stupid the first time I laid eyes on it. If it's not meant to be a url then don't make it look like one.

Rotor• 15 years ago

Yes, a known and sad fact many java static files have hardcoded URIs to java.sun.com.

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.

Roboprog• 15 years ago

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.

foolinator• 15 years ago

It's DUMB to make ANY of your build dependent on an external system. Build 101 crap.

shaggyfrog2• 15 years ago

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.

jamesbritt• 15 years ago

Can't catalogs be used?

http://en.wikipedia.org/wiki/XML_Catalog

Java.sun.com is down - breaking builds across the land

Related Stories