goxr3plus
Wish list
Here are some things I have thought about, in no particular order.
- No public fields. This will improve testability.
- More use of dependency injection, less creation of objects inside methods that have "business logic" in them. This will improve testability.
- The possibility to inject the sourceDataLine, rather than fetching it from AudioSystem in StreamPlayer.createLine().
- StreamPlayer divided into smaller classes, if possible.
- Maybe the loop that transports data from the source to the output can be in a separate class.
- An interface for StreamPlayer. It would probably contain all public methods of StreamPlayer.
- Unit tests that demonstrate that the threading works as intended.
- Java 9 modules. I assume that that would make the player not usable for people using Java 8. But besides that, it would bring the possibility to only make the player interface reachable from the application.
- All commented-out code removed.
- The possibility to run StreamPlayer from something else than an audio file or a URL. Maybe a signal generator class that produces a sinusoidal signal. This will be useful for testing.
- More consistent types for the StreamPlayer methods. Now it's a mix of int, double and float.
- Remove the use of null as some kind of special value. Remove the possibility or likelihood of NullPointerException.
- For myself, I wish to better understand how the threading model and player loop works. Parts seem to ber hidden in some ExecutorService which I don't yet understand.
*About the URL part , it doesn't work well , seek and stuff doesn't work with URL links i have to fix that.
Please keep updated for the next version : https://github.com/goxr3plus/java-stream-player/releases/edit/untagged-98ddbc2c434b3ab9f14d
I am thinking of the Java 9 because many people are still using Java 8 .
Yes, I'm using Java 8 myself at work, so now is probably not the right time to do the change. It would be wonderful if Java9 modules could be provided for people using Java9+, but not force Java8 users to upgrade their Java runtime. I don't know if it's possible, without providing multiple builds. And multiple builds have problems of its own.