Deprecated API

Contents

• Deprecated Classes
• Deprecated Fields
• Deprecated Methods

Deprecated Classes

Class and Description
de.cismet.tools.CismetThreadPool either use CismetConcurrency.getDefaultExecutor() or create your own ExecutorService using a ThreadFactory created by an instance of CismetConcurrency.
de.cismet.tools.CurrentStackTrace use StackUtils.getDebuggingThrowable() instead
de.cismet.tools.collections.MultiMap error-prone
de.cismet.tools.collections.SyncLinkedList use Collections.synchronizedList(java.util.List) instead
de.cismet.tools.collections.TypeSafeCollections mscholl: you should be aware of what you're doing when using generics and there isn't much to save either so spare this additional import and method call as there is more overhead that way

Deprecated Fields

Field and Description
de.cismet.tools.PasswordEncrypter.CRYPT_PREFIX

Deprecated Methods

Method and Description
de.cismet.tools.PasswordEncrypter.decryptString(String)
de.cismet.tools.PasswordEncrypter.encryptString(String)
de.cismet.tools.CismetThreadPool.execute(Runnable) it should not be allowed for a "general-purpose" pool to increase in size infinitely and thus may be able to break an application just because of allowing to many threads to run concurrently.
de.cismet.tools.CismetThreadPool.executeSequentially(Runnable) if there is a need for an execution queue it is not likely that it's focus has to be global. Additionally it is better to think about the purpose of the sequential execution and then to narrow it down to the tasks that are really dependent on each other (because that's the whole point of sequential execution). Maybe other solutions for the issue may be even more suited and/or elegant, too.
de.cismet.tools.CismetThreadPool.shutdown() shutdown immediately renders this global pool unusable. It can never be revived. Thus any call to this operation is dangerous for any piece of code that depends on this implementation.
de.cismet.tools.CismetThreadPool.shutdownNow() shutdown immediately renders this global pool unusable. It can never be revived. Thus any call to this operation is dangerous for any piece of code that depends on this implementation.
de.cismet.tools.CismetThreadPool.submit(Runnable) it should not be allowed for a "general-purpose" pool to increase in size infinitely and thus may be able to break an application just because of allowing to many threads to run concurrently.