-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
javax.websocket classes shouldn't be madatory to be in the classpath #81
Comments
What do you mean by "it becomes a bit complex to maintain and not reintroduce problems"? Can you be a bit more specific? |
@pron I means that if in 1 year, you, without noticing, reintroduce direct references to |
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. |
Ok, I will make a PR very soon :) |
@pron the same question arises with the class 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… |
Yeah, that would be overkill. Are you sure, though, that |
I just checked and yes it does happen :/ |
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. |
This is a kind of spinoff of #74.
Basically, because
WebActorInitializer
refers tojavax.websocket.server.ServerContainer
and other classes from the javax.websocket package, when the JVM tries to loadWebActorInitializer
, 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 ?
The text was updated successfully, but these errors were encountered: