Why does a JAX-WS client access the WSDL at run-time?

Is this a bug?

No, this is not a bug, but reasonable from a conceptual point of view.

What reason does JAX-WS have to look for the wsdl location at run time?

At build-time, you generate classes from the WSDL which means you need to know what kind of operations the service supports and what structure the messages have (aka portTypes, types, messages).

At run-time a whole lot of different information comes into play. For instance, the actual address the service runs on might have changed. The bindings become relevant: Should messages be sent in SOAP 1.1 or 1.2 or are both formats ok? Futhermore, all sorts of policies (security, reliable messaging, etc.) might be attached to the service. All these things are dynamic and mostly irrelevant at build time. Ideally, you should be able to point your client at a different service that uses the same structure and it should work out of the box.

I'd like to answer another question I think you might have:

Isn't this a total overhead in cases where there is just one service that never changes?

Yes, it is. In cases where there is single service with a particular WSDL that never ever changes from its build-time state, reloading the WSDL at run-time is unnecessary and a waste of ressources. But JAX-WS would do a terrible job if it wouldn't allow for more complicated scenarios where information such as bindings or policies do change or where there is more than a single endpoint for the service.

Nonetheless, most JAX-WS implementations do allow for some mechanism to store the WSDL locally and not load it for invocations at runtime. In the RI, simply pointing the wsdlLocation in your @WebServiceClient to the file on the classpath should do the trick.