On Wed, 11 Mar 2026 18:17:43 GMT, Vishva N <[email protected]> wrote: >>> The fix proposed here doesn't look right. >>> >>> > While using Google Big Query JDBC Jar, If proxy username property is >>> > present in the connection url, the default authenticator is reset by a >>> > code piece in the jar without any checks for existing authenticator. >>> >>> This seems wrong and is the root of the issue, so I would suggest fixing >>> the behaviour of that jar instead. >> >> This fix is to give control to owner of a big java project. This is not the >> only jar that I am gonna use. With this fix, there is no need to wait for >> update from the jar. Instead I can just skip the setDefault() call with this >> fix. Setting default authenticator is necessary in case where central proxy >> control is needed or Authentication is managed centrally. >> >> This jar is just an example. The proposed fix prevents any kind of Default >> Authenticator override. > >> The fix proposed here doesn't look right. >> >> > While using Google Big Query JDBC Jar, If proxy username property is >> > present in the connection url, the default authenticator is reset by a >> > code piece in the jar without any checks for existing authenticator. >> >> This seems wrong and is the root of the issue, so I would suggest fixing the >> behaviour of that jar instead. > > Also, Giving control to the JVM owner should be the right way I think. This > is significant in emergency production releases.
@vishva238 I think it would be better to start a thread on net-dev to discuss the problem/issue you are running into. It's way too. Are you migrating from an environment that used a security manager? Have you looked at the example agent in JEP 486 to get ideas for how to instrument the use sites to prevent the execution of methods that don't want to execute. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30193#issuecomment-4041331481
