Use a logging framework such as as SLF4J instead of System.out.println

[oakkitten]

Expected Behavior

the library logs stuff using SLF4J and the application controls the actual output. this will allow logging stuff like logger and thread names, etc. the library uses different log levels (trace, debug, error) for different things and it's easy to filter them out, if needed. as the output is controlled by the application, no stuff like if (WebSocketImpl.DEBUG) is needed.

also, it would be nice to have a proguard rule file that would remove the logging messages from the code.

Current Behavior

the library prints its debug messages to stdout in a pretty raw form. all messages, accordingly, are of the same “level” and are inconsistent with the other messages that the application prints

Possible Solution

use SLF4J

[marci4]

Hello @oakkitten,

thank you very much for this improvement!

Do you think it is possible make this somehow happen without f**king everyone up right now, especially users who do not use a build system like maven or gradle?
Or do I have to provide a separate download then?

I have no knowledge on how to write such a rule so could you maybe help me do this?
Thank you!

Greetings
marci4

[WalkerKnapp]

Hi @marci4,
I'm not the original one to post the issue, but I think the best way to go about addressing the first issue would be to distribute a Fat Jar (Not the most technical of terms, sorry) for those who don't use a build system and to have a fallback logger with System.out (Depending on WebSocketImpl.DEBUG, like currently) if they don't provide a slf4j compliant library. Are there any issues with a system like this?

I really hope this issue is implemented eventually as it is a really nice feature to have slf4j logging. Thanks!

[marci4]

Hello @WalkerKnapp,

thank you for your feedback!
I quess I have to do it this way and maintain 2 versions.
One maven version and one standalone version.
Will only do this to the next major release 1.4.

BTW input is always welcome!!! That what github is build on! :)

Greetings
marci4

[marci4]

Hello everyone,
You can see the current development status for this in this branch (https://github.com/marci4/Java-WebSocket-Dev/tree/slf4j).

Would like to get some feedback on this please!

Greetings
marci4

[WalkerKnapp]

Looks great in my opinion. Although, there were still some printlns dotted around, so I commented on those in the commit. Other than that, looks perfect and I hope to see it in the next major release.

[NoahAndrews]

Any update on this?

[marci4]

@NoahAndrews 1.4 is planned as the next release. No ETA since there is a lot to do...

[neoedmund]

An unconstructive dissent here.
Why not just use java.util.logging.Logger? add 48 classes and 123KB just for a logger? what makes bloatware.

[PhilipRoman]

At this point SLF4J is basically an industry standard (and for a good reason). With java.util.logging you lose a lot of flexibility.

SLF4J API jar is 40kb and it's java.util.logging implementation is only 8kb.

[neoedmund]

SLF4J maybe popular, but there is no such thing that SLF4J is an industry standard.
And there is also a reason for a library like Java-WebSocket not use any specified logging library, at least because logging is not playing as a must part, it should be totally disabled when it's out of development into a stable release(Java don't have proprocessor like C, or can be easily done).

About the size, in Java-WebSocket-1.4.0-with-dependencies.jar
org.java_websocket 79 items, 268KB
org.slf4j 48 items, 123KB
dozens of lines of logging functions taking up 1/3 of the code size!
Bloatware pollution, at the point of software engineering.