Using the prefix "abstract" to mark abstract classes is more a workaround or a shortcoming, than a best practice. Even worse is the introduction of naming conventions for interfaces with the only purpose: avoidance of interface naming collisions with their implementations. The convention "Default" is superfluous as well (what is "Default"?). Even the Remote and Local, Bean suffixes for EJBs are no more that interesting - the Beans are already annotated with the corresponding annotations.
In general: all technical naming conventions are just too convenient. Instead of naming an artifact (class, interface etc.) after its essential responsibilities, it is lot easier to introduce some artificial conventions... It is better to avoid naming conventions and provoke so naming collisions. A naming collision could be an indicator of a superfluous class, interface or another artifact, which could be removed after such naming collision.
Exceptions from the rule: Some frameworks / code generators / patterns may require you to rely on technical naming conventions. This fact should be clearly documented - but it is still just a workaround.
NEW workshop: Building HTML 5 Applications Without Frameworks, Full week in December 2016: from Java EE 7 Bootstrap, Effective, Architectures over Testing to Microservices
On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming.