comsat icon indicating copy to clipboard operation
comsat copied to clipboard

javax.websocket classes shouldn't be madatory to be in the classpath

Open victornoel opened this issue 9 years ago • 8 comments

This is a kind of spinoff of #74.

Basically, because WebActorInitializer refers to javax.websocket.server.ServerContainer and other classes from the javax.websocket package, when the JVM tries to load WebActorInitializer, it also tries to load the websocket ones, which must then be in the classpath even tough one (such as me :) would want them not to!

It seems to me that the simplest way to solve that (if we want to of course, an alternative would be to simply add the javax.websocket API only to the classpath) would be to externalize websocket related code in other classes (that wouldn't then be loaded until needed). I've made some tests and it works.

The problem is that it means then it becomes a bit complex to maintain and not reintroduce problems after… not sure how hard it is to make a test around that…

What is your opinion @pron ?

victornoel avatar Oct 19 '16 09:10 victornoel

What do you mean by "it becomes a bit complex to maintain and not reintroduce problems"? Can you be a bit more specific?

pron avatar Oct 19 '16 10:10 pron

@pron I means that if in 1 year, you, without noticing, reintroduce direct references to javax.websocket in WebActorInitializer or any other class where we would like to avoid it, then nothing will warn you.

victornoel avatar Oct 19 '16 12:10 victornoel

There's a tool called Macker, which I used a long time ago for this kind of thing. You may want to give it a try. But not everything needs to be automated. I assume you'll warn me.

I'd certainly consider a PR.

pron avatar Oct 19 '16 19:10 pron

Ok, I will make a PR very soon :)

victornoel avatar Oct 20 '16 07:10 victornoel

@pron the same question arises with the class co.paralleluniverse.comsat.webactors.servlet.ServletWebActors: it contains both websocket and non-websocket utilities.

I don't think we can simply extract the websocket-dependent method because it would break API, but what do you think of making them deprecated for now (and delegating to another class) and then removing them in the next major version? Just an idea, maybe it is starting to be a bit complex just for not including a simple api dependency…

victornoel avatar Oct 20 '16 07:10 victornoel

Yeah, that would be overkill. Are you sure, though, that ServletWebActors loads the websocket classes even if the relevant methods are never called?

pron avatar Oct 20 '16 07:10 pron

I just checked and yes it does happen :/ The more I think about it, and the more I think it's a lot of work just to avoid a dependency: I'm ok to make a PR, but if you agree that all of this is too much, let's abandon the idea :)

victornoel avatar Oct 20 '16 07:10 victornoel

Yeah, I think we'll wait until there's stronger motivation that just including an API JAR, considering how many unused JARs are in most applications anyway.

pron avatar Oct 24 '16 17:10 pron