This blog is now the official blog of Bashpile: The Bash Transpiler!
A transpiler is a compiler that produces a different language. This means that you can write in a modern, clean syntax and still have code that runs on any Linux or Unix platform that supports Bash scripts!
More details are at the main page: https://github.com/michael-amiethyst/homebrew-bashpile
 | ||
| This could be you! Image from http://blog.smartbear.com |
 |
| Thread Pool, not to be confused with Deadpool |
ExecutorService will have an equivalent of Thread.join(), and then be re-usable since that is the whole point of a thread pool. A quick skim of shutdown() says to use awaitTermination(). Upon reading the full docs of awaitTermination() it appears that this is what I am looking for.awaitTermination() terminates the WHOLE POOL instead of terminating the currently running threads. What's the point of having a terminated pool? Isn't that what close() is for? Does this have a close()? Why not? Maybe because it is in the java.io package instead of java.concurrent? Again, the entire point of having a thread pool is to reuse the threads!List<Callable<Void>> I need to keep a List<Future<Void>> and loop through all of the Futures to cancel() each one. WHAT? Again, nothing in the documentation of awaitTermination() says that it terminates the thread pool itself. That is buried in the class level documentation. I end up adding a cancelThreads() method to our custom ThreadPool object leaving us with a final API like the following:public class ThreadPool {
ThreadPool(int size) {...}
void add(Runnable) {...}
void add(Callable<Void>){...}
void clear(){...}
boolean isEmpty(){...}
void runSynchronously(){...}
void runAsynchronously(){...}
Callable<Void> toSafeCallable(Callable<Void>){...}
Runnable toSafeRunnable(Runnable){...}
void cancelThreads(){...}
void close(){...}
 |
| Created at imgflip, original image copyright Dos Equis. |
new ExampleSingleton.@Service
// implied Spring Singleton Scope
public class ExampleSingleton {
// should only be called once by Spring
public ExampleSingleton()
{
if (instance != null) {
throw new IllegalStateException("Singleton constructor called twice!");
}
}
}
@ComponentScan(basePackages = {"com.yourcompany"}) and another with @ComponentScan(basePackages = {"com.yourcompany.utils"}), Spring will (re)create all of the Singletons in the overlap (in this example com.yourcompany.utils) twice. I found this surprising and very strange. In addition, the same link mentions that Spring only promises that a Singleton will happen once per ApplicationContext, and Servlets usually have more than one.@Singleton contract and to manage my instances myself. After doing more research I found that in Java the best way is to have a SingletonFactory. I ended up having a base class called SpringSingleton, which has the documentation on why all of this is necessary and a protected constructor that keeps track of which sub-classes have been instantiated with a Set<SpringSingleton> that is accessed in a synchronized block. In addition the @Configuration classes have an @Autowired SingletonFactory and @Bean definitions that get the beans from the SingletonFactory. All in all it still isn't foolproof for Serializable Singletons (see below) but does a great job otherwise. There is more complexity (4 classes for the simple case) but new Singletons end up being easy to implement and work correctly. I would post the code but I made it at work so the company has copyright.@Component on a class with the default scope and have it work right.