Not really, because anyone with access to your source would probably also have
access to such a key.  Even if they didn't have the key, a dedicated
source-stealer would simply retype it into their own editor, thus >KAPOOF<
your key would be pointless.

Unless of course you just publish your source for the world to see, but then
why would you do that if you're interested in staying proprietary?

You can encrypt source, and only decrypt it for trusted programmers and
deployers, but that would be a lot of overhead.  Is your source code really
such an asset?  If so, it might be worth it.  For just about everybody,
though, it's enough to keep the source on company premises and in the hands of
trusted employees.  And make sure those employees are actually trustworthy.
It's no different, really, from protecting a proprietary document, say, one
describing certain internal management procedures.

The key is to restrict access to the source to folks you can actually trust.

the usual way to do that is to require login to use the app. The
servlet womb e.g. Tomcat manages the user ids and passwords.

If you have a list of legal IPs or ranges, your app can check for
itself, bypassing the login requirement.

You can create certificates for your clients.  The public key of that
cert is stored in the file on the server. The Login process does a
challenge, asking the client to encrypt something with its private
key, which it sends back.   The advantage of this approach is the user
does not need to remember the id or password.

I used such a system in Linux back in the 90s, for remote text-based
login. I would expect something similar should be supported in many
wombs without you having to write any code.  If not, you can use the
methods that form the Transporter, a light-weight  public key
encryption package that does not need the JCE.  To create your
certificates, to encode and decode. See
http://mindprod.com/products1.html#TRANSPORTER