I'm making a Java library called future, the intended purpose is just to make things easier, so you don't have to implement them yourself, or gather up a bunch of multiple libraries.
The two main subpackages of future I will work on is eval (future.eval.*) and types (future.types.*).
I've already got some things in eval, such as EOLError, and I'm currently working on Parser (which will convert Strings to values).
And also have a Queue type in types.
Once the project has finished its first version, the GitHub repo will be made. And, when it is released, I hope to hear your feedback on it.
Thanks for reading!
Cheers!
Cheers!
Top comments (4)
Hi Calin. No need to implement queues yourself, they already come in the JDK, see docs.oracle.com/javase/7/docs/api/...
The link doesn't lead to a class, but to an interface, so take a look at "All Known Implementing Classes". There are several implementations of Queues available, all with different pros and cons.
My version of
Queuedoesn'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
Queuethat suits my needs is really helpful.*shrug*
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. ;-)
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 toRunnable, but, it's better.