I think a lot of us Java developers have been conditioned to think that we should only use published APIs in the java or javax hierarchy, and things under com.sun are implementation details that is not guaranteed to be there in the future.

But in this case, if one claim that com.sun.net.httpserver.HttpServer is an implementation detail, then the natural follow-up question to ask is "implementation detail of what?"

As for the urge to find an open-source implementation that offer similar functionality, that'll lead us right back to the Sun JDK, because the Sun JDK is now an open source project.

I'd be skeptical. I'd want to know why they were importing that and if there's something else available that could do the same thing. For this, there are plenty of http servers you can easily embed that have APIs that are less likely to change.

Sometimes there's not. If you want to handle signals on the JVM for example, a com.sun import is pretty much the only way (or at least used to be, I haven't checked recently).

But such a thing should be kept from the rest of the code. Either by wrapping the com.sun packages or by having just a single class that can use it. It prevents making lots of painful edits when that api does change.