DEV Community

Discussion on: Java `future` library.

Collapse
 
baenencalin profile image
Calin Baenen

My version of Queue doesn't throw any errors, and it tries to be as light as possible. I know it has been done before, and I'm re-inventing the wheel, yeah yeah.

I think the only thing I should think about, or what the user should think about is, "Does this class, the one the creator of the library made suit my needs?". If it doesn't, they don't have to import it, and if it does, they can feel free to.
I just see that having my own implementation of Queue that suits my needs is really helpful.

*shrug*

Collapse
 
martyonthefly profile image
Sylvain Marty

Hi Calin. The Queue interface posted by Thorsten is very useful for interoperability.

Here is an example: I'm building a software which uses queues. I have one queue for processing unique object only and another one for processing all objects regarding of unicity. If all my queues implements this generic Queue interface, its very simple to change the queue behavior with an external library or my own implementation.

It can allow your library to be more widely used because it is simple to add it or remove it from an existing project, reducing the impact of your library on the system technical debt. ;-)

Thread Thread
 
baenencalin profile image
Calin Baenen

I do like this As I said though, I only maid it to tailor the needs of something else in the project that needed a Queue, and felt like it would be fun to do.

I don't want this library to be as popular as it could get, I'm doing it because I want to enhance my understanding of Java, and because I find making big-scale projects like these fun.

Y'know?

Anyways, one cool feature that's (maybe) unique, is CodeShell, the only comment I'll make on that is that it's similar to Runnable, but, it's better.