How SM should resolve the technical impediment?

If Developer comes to SM asking for assistance in resolving Technical impediment (say related to Coding in Java)

How SM should resolve this impediment specially when SM don't have knowledge of Java code?

Why is the Development Team not working together to solve the impediment? Taking the example you provided related to coding in Java, what is beyond the ability of the Development Team? Can the Development Team not take time to learn this particular knowledge gap? Consider using a Spike?

Given that in your example the Scrum Master does not have relevant knowledge to actually remove the impediment do you see any way that the Scrum Master can use resources at their disposal to ensure the impediment is removed?  Sometimes it is best to help others than to do it for them.  The old adage of "Give a man a fish, he eats for a day. Teach a man to fish and he can eat for a lifetime" always pops into my head. Do what will help the team permanently remove the impediment not just something that clears the way temporarily.

The first thing that pops to my mind is, the SM should ask the question to the developer: what would you need to resolve this? And, depending on the answer, help the developer figure out how to get to that.

A SM is not a Macgyver swiss army knife which has all the solutions; a SM is someone to help you find solutions

Two things jump out at me.

First, it is not the responsibility of the Scrum Master to resolve impediments. The Scrum Master helps the team to remove impediments. There may be some impediments that the Scrum Master may resolve with little involvement from the team. Others may require people on the team to be more active. Sometimes, the Scrum Master may work to simply mitigate the impacts of the impediment while others are working to resolve it. Depending on the impediment and its impact, the Scrum Master may also need to help with escalating it - helping the Product Owner and Development Team consider and replan the Sprint to account for it, involving people outside of the Scrum Team to mitigate or resolve it, and so on.

Second, in my view, this is a good argument for the Scrum Master having the background that the Scrum Team works in. In the case of a Scrum Team that is producing a software product, a Scrum Master having a background in software development makes it much easier to have discussions with the Product Owner and Development Team about the impediments they face. It gives a common ground to have a shared terminology for discussions, and that common ground simply makes communication easier. This doesn't mean that the Scrum Master needs to have been a developer, but simply working in the same domain space for long enough and having motivation to learn may be sufficient.