The proper solution to using WSDLs and web services is to use the WSDL. While you could forego the pleasantries of a WSDL, for a strongly-typed language such as Java, you are in for a world of unpleasant surprises.
At minimum, to implement a client-side (Java) solution, you'd have to build an entire generic SOAP client just to interface with salesforce.com, and there would be a ton of casting, runtime data type detection, dynamic parameter building, and so on.
On the flip side, you could also implement this using Apex Code's reflection methods, but that would introduce another entire layer of complexity regarding interfaces, virtual or abstract classes, not to mention trying to come up with a uniform interface for dynamic parameters.
The amount of time required to simply re-compile a WSDL and rebuild a project each time the interface changes is significantly less than the time it would take to rig a dynamic framework that would probably be more fragile than offering any significant benefit on time or complexity savings.
You could also use REST instead of SOAP, but the same general problem applies. You'd be forced to do a ton of custom parsing rather than using native objects with stronger bindings, effectively discarding the entire purpose of using a strongly typed language in exchange for a minor convenience feature.