

Java.sun.com is down - breaking builds across the land - drewvolpe
http://java.sun.com

======
johnnyo
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.

~~~
drewvolpe
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.

~~~
justincormack
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.

~~~
oconnor0
Apparently you've never met Maven.

~~~
shaggyfrog
I believe the expression is "Maven downloads the Internet".

~~~
serverascode
I'm going to use that one! ha!

------
mrspandex
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...](http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/)

~~~
funkah
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.

------
jrockway
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.

~~~
ChuckMcM
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
He was right about Sun having bigger problems though.

------
jmount
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://java.sun.com/dtd/properties.dtd>);
.
[http://download.oracle.com/javase/1,5.0/docs/api/java/util/P...](http://download.oracle.com/javase/1,5.0/docs/api/java/util/Properties.html)
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.

~~~
andrewf
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>](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.

~~~
jmount
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.

------
smoyer
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
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.

~~~
smoyer
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?

~~~
sjs
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.

------
Rotor
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
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.

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

~~~
xsmasher
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
Does this mean that those builds would fail on un networked machine under
normal circumstances?

~~~
brown9-2
Yes

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

------
pregzt
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
Sorry for being slightly flippant, but I would think that panic is a good idea
if one is dependent on Java.

------
smackfu
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.

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

~~~
shaggyfrog
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
Can't catalogs be used?

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

