nealkumar / jbrew Goto Github PK

Describe the bug
Unit tests are needed to expand code testing coverage. There should be a new branch, "unit_tests" created, which will integrate unit testing (so that coverage is at least 50%) for each respective Task in software.nealk.concurrent.tasks.

A static factory or builder will serve as a concrete interface for (Non)RetrievableTasks.

closes #5

Group ID = "org.jbrew"
Artifact ID = "concurrent"

Proposed Release Date = 2/14/20

Describe the solution you'd like
toString() in a Task should be overridden to print out the task name.

Is your feature request related to a problem? Please describe.
Creating a ObjectBlockingTask or MethodBlockingTask and assigning names/priorities/other fields can get cumbersome with multiple dot statements. This problem can either be solved by having a constructor which takes in n arguments, where n is the number of fields as Task specifies. On the other hand, a Builder pattern would allow for a cleaner solution.

Describe the solution you'd like
A Builder pattern as the primary interface for a ObjectBlockingTask and MethodBlockingTask.

Describe the solution you'd like
All tasks should have the ability to be interrupted dynamically, especially if a given condition is filled from another Task

Describe the bug
Change Registry.java to TaskRegistry.java and TaskRegistry.java to TaskRegister.java.

easy fix.

Epic for the TaskProducer<> implementation issue group.

Is your feature request related to a problem? Please describe.
No problem, but users should have the ability to ask a ThreadFactory for an already constructed Default instance of a (Non)RetrievableTask

Describe the solution you'd like
Will have 3 overloaded factory methods returning a Thread.java:

1. A default - no arg - method which simply returns back a new Thread()
2. A method which takes the param of a org.jbrew.concurrent.Task.
   a. This Thread object will input the Runnable Task in the Thread.java constructor, as such:
   Thread t = new Thread(providedTask);
3. A method with the option to have a default instance of a Task instantiate and return back.
   //continue...
   All returned threads should have their priorities set to max (10).

Describe alternatives you've considered
This is able to be done naturally without a library feature, but it would be helpful to have this functionality out-of-the-box

Additional context
Client call would like like: SimpleThreadFactory.generateTask(myTask).start();

Description
For the planned static factory #74 add the ability to have 2+ Tasks run concurrently, then sequentially compare the results and return accordingly.

Describe the solution you'd like
Refactor get/setVal() to assign() and retrieve() respectively. This aids in downstream consumer cohesiveness.

Please describe.
SonarCloud integration will help patch code smell and other related bugs.

Describe the solution you'd like
Integration for a very easy to use task scheduler service with an option to define an explicit sized thread pool and and asynchronously "execute" (via the execute() method) the task. This may or may not require creating a reflections library which initializes all implementors of Task (if not using a Class-Loader / "Service-Registry")

Describe alternatives you've considered
At the moment, Task and thread management have to be explicitly handled, which may be undesirable for some users. Instead, abstracting this layer away with the concurrency library may be beneficial for those who don't want to worry about these details..

Describe the bug
The fields in the in the pom need to be deleted. At present, it is tagged to 0.0.0, giving incorrect SCM tags.

Epic relating to the issue group of overhauling and extending the Task API contract, as well as modifying existing Tasks to extend BlockingTask.

Is your feature request related to a problem? Please describe.
There needs to be a uniting utility library which contains things such as Annotations, custom exceptions, serialization interfaces, etc.

Describe the solution you'd like
Group ID: org.jbrew.util
ArtifactID: jbrew-util-parent
AS parent pom

AND

Group ID: org.jbrew.util.core
ArtifactID: annotations (UnderDevlopmentInvestigation), exceptions (RadixSortException), testing (for logging test), fat (takes in all 3)

AND

Is your feature request related to a problem? Please describe.
This feature will create default instances of (Non)RetrievableTask(s). This feature will make it simple to get started using the concurrency library without having to extend a Task.

Describe the solution you'd like
This will create a default implementation of the NonRetrievableTask.java class - DefaultNonRetrievableTask.java - as well as a method - defaultTask() - in NonRetrievableTask.java.

Clients can instantiate a default non-retrievable task by either:

1. Initializing and creating a new instance of DefaultNonRetrievableTask.java
2. Calling the static method - defaultTask() - in NonRetrievableTask.java which returns a NonRetrievableTask.java by following the steps prescribed in item 1.

Additional context
[IMPORTANT]: This feature will likely be explicitly used for issue #5

Describe the solution you'd like
A new (Non)RetrievableTask which has the ability to dynamically unblock the retrieve() method. This would invoke a new method call on a BlockingTask.java: unlock()

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

should be simple enough, but is blocked by #81

Is your feature request related to a problem? Please describe.
A core library with things such as annotations and custom exceptions would help to standardize such items across the software.nealk library

Describe the solution you'd like
A core library

Describe alternatives you've considered
At the moment, things such as annotations and custom exceptions are held locally within the Concurrency Library

Is your feature request related to a problem? Please describe.
A ThreadSafe PriorityBlockingQueue for Tasks (hence the name PriorityTaskBlockingQueue). Ideally, this implementation would be a ground-up implementation

Describe the solution you'd like
New class / feature request for a PriorityTaskBlockingQueue.java object as a part of the concurrency library.

Additional context and alternatives
Java collections has a PriorityBlockingQueue, but this implementation ideally would be extendable so that consumers would be extensions of the software.nealk.concurrent.tasks.RetrievableTask abstraction.

Is your feature request related to a problem? Please describe.
Want to disable console printing when ever a com.nealk.concurrent.Task is started (via start()). This can hinder performance.

In addition it would be nice if I could have the names of Threads print out rather than an only the number. So maybe having an option for the name to print out with/instead of the thread number

Describe the solution you'd like
A method that takes a boolean parameter to enable or disable an option for the println.

Additional context
Perhaps in the future you could add the option to name a Task, and then have that print out?

Describe the solution you'd like
Functional interfaces -> lambda expressions -> default implementation.

Is your feature request related to a problem? Please describe.
At present, ObjectBlockingRetrievableTask uses the standard primitive wait()/notify() to handle contention. While this implementation is works well, there should be further investigation as to the performance of various other synchonizers.

Describe the solution you'd like
There should be multiple drafts and metrics measured between the various types of synchronizers. This can include re-entrant locks (with Conditions), executor thread pool service (either via internal build with Task or leveraging the java concurrent api).

Additional context
During the measuring and comparisons of various synchronizers, a design decision will need to be made as to whether to include one or multiple implementations of ObjectBlockingRetrievableTask.

Describe the solution you'd like
A TaskRegistry will have a static factory interface allowing users to add new Tasks to the registry in order to perform bulk operations (such as bulk set tag, or to execute all operations with a certain tag).

Is your feature request related to a problem? Please describe.
There should be RetrievableTask support for the Void class type in order to make RetrievableTasks.java essentially a non-retrievable task.

Describe the solution you'd like
This could be further expanded by removing the seperation between Retrievable and NonRetrievableTasks; Tasks can simple have an abstract execute() method which returns T - a attribute which is explicitly provided at compile-time. If a user does not want to return back a value, they can supply the Void type instead of a proper concrete class.

Note that this implies that the execute() method would be the blocking method, instead of the getVal() method. The getVal() method would be eliminated.

Describe alternatives you've considered
RetrievableTasks and NonRetrievableTasks are the current solution.

Additional context
This could either be done via have two paths to creating Retrievable and NonRetrievableTasks.

1. Users can simply use a RetrievableTasks (or some variation of it created specifically for this... RetrievableTask could be further abstracted) for both returning and on-returning concurrent operations.
2. Users can have both ^ and the current setup of RetrievableTasks and NonRetrievableTasks. The drawback with this approach is that this could create ambiguity between which is the "correct" approach for the library.

Is your feature request related to a problem? Please describe.
Drop the "nealk" prefix from the sdk name. Would require a new artifact id.

Describe the solution you'd like
New artifact id

Additional context
This fix helps clean up the nomenclature

Describe the solution you'd like
Adding the SONAR_TOKEN environment variable to TravisCI will allow for an "after_success" tag to automatically execute "mvn verify sonar:sonar" so that we don't have to manually check this. In addition, there should be a way to add this as an official github push/pr check?

Describe alternatives you've considered
Running "mvn verify sonar:sonar"

Additional context
The environment is presently on the local deployment machine, but this makes verifying cumbersome.

Release Proposal

The public release of the Concurrency Library will contain multiple options for RetrievableTask blocking. In particular, downstream consumers will have the ability to differentiate between a RetrievableTask which blocks until exeucte() is complete OR a RetrievableTask which blocks only until the obj is not null (essentially rendering the leftover logic in execute() akin to a NonRetrievableTask).

Proposed Release Date
2/28/20 - End of the month release

Is your feature request related to a problem? Please describe.
It is cumbersome to continually offer() multiple tasks to the TaskRegister. Instead, it would be cleaner to have a Builder to automatically declare Tasks upon initialization.

Describe the solution you'd like
Builder interface for TaskRegister.java

Is your feature request related to a problem? Please describe.
A Task should have the option to be serialized for passing around between json or other means calling for serialization.

Describe the solution you'd like
A new sub-package within the concurrency library which integrated with the native Java serialize interface. Bonus points if it can have adapters for other types of json serialization (ie guava, JSON simple, etc.)

Describe the bug
A clear and concise description of what the bug is.
In standard Java syntax, the modifier "final" proceeds "synchronized". Although this does not affect JVM performance, these modifers should be re-ordered so as to reflect best practices with regards to modifier temporal ordering.

Describe the solution you'd like
BlockingTask.java will be an abstraction layer for all (Non)RetrievableTasks. This will implement the update Task interface, as well as Union the common logic between various Task implementors. As such, Retrievable and NonRetrievableTask will extend BlockingTask.

Describe the solution you'd like
Tasks should be able to be tagged a grouped together. Then, a TaskRegister could stopAll() or interruptAll() dynamically.

Is your feature request related to a problem? Please describe.
A great addition for the sdk would be a sorting library that can do linear sorts (such as radix sort) - particularly if this can be packaged with RetrievableTask(s).

Describe the solution you'd like
This is obviously not the correct place to request this, but see above ^

Is your feature request related to a problem? Please describe.
At present, all Tasks use a single generic type parameter. However, what if a client requests a return value from a different object type? RetrievableTasks should have the flexibility to handle this via multiple type parameters

Describe the solution you'd like
Go from type to <T, R> in RetrievableTask.java.

Describe the bug
PrintStrategy.java needs code coverage expansion prior to release of v0.1.0.

Describe the solution you'd like
A @threadsafe singleton implementation of TaskRegister.java would be a nice feature. However, should the various options for a TaskRegister be mutually exclusive, or should there be multiple existing options for downstream consumers?

Describe the solution you'd like
A CoffeePot would be a simple Thread wrapper for Tasks. One advantage: Automatic Integration for the TaskPriority enum for Task#priority value.

API Declaration:

• CoffeePot.start(Task<?>)
• CoffeePot.startAll(Collection<TaskRegistry<Task<?>>>)
• CoffeePot.interrupt(Task<?>)
• CoffeePot.interruptAll(Collection<TaskRegistry<Task<?>>>)

Describe the solution you'd like
At present, the Task interface acts as little more that a wrapper around Runnable. Tasks should be have added functionality uniting all common features of all Tasks. This should include methods such as:
get/set int priority() - with validation logic in the setter
get/set String name() - to name a task
get/set long serial - an interface implemented from org.jbrew.util.

Describe the solution you'd like
A serializier interface with a long serlialize() method.

Ideally this would be placed in the util library, but it can temporarily live in the concurrent lib until formal documentation needs to be created.

Is your feature request related to a problem? Please describe.
Currently Retrievable Tasks block until the execute() method returns. However, this can be problematic. For example, what if I would like to return the value back to the caller but still have further processing to do inside of execute()?

Describe the solution you'd like
Either an expanded contract for RetrievableTask.java with two separate (or overloaded) execute() methods OR an extension of RetrievableTask with only this variation of the execute() method.

Describe alternatives you've considered
Writing an additional semaphore, but isn't the point of the library to avoid users doing this?

README.md needs major updates. At present, it contains very stale info...

The README.md needs to be updated to reflect the new features and updates introduced in v0.1.0-x

Is your feature request related to a problem? Please describe.
There needs to be a javadocs servlet to establish a fine grained api definition for the library.

Describe the solution you'd like
Either a locally exposed or provisioned static file http servlet through aws that serves this library’s javadocs.

Release Proposal

Release for a graphics library that wraps around Swing for easy access and integrates with the concurrency library.

Proposed Release Date
Unknown

Additional Remarks
This will establish a new artifact and library: swing.

Is your feature request related to a problem? Please describe.
JBrew Workflow Epic Issue Group tracker.

Describe the bug
Currently points to old project homepage.

Epic tracking all new and proposed JBrew libraries.