In operating systems, there are several solutions to the problem of code reuse: structural approaches were able to achieve a certain level of reuse by layering the system and providing kernel services, libraries distributed with the OS, and minimal but flexible utilities that could be put together in scripts to get more complex behaviour.
Object orientation allows for a unified view of these services by encapsulating all behaviour in classes, and thus, OS design can be replaced in many locations by class design which is much less error-prone, and can use more sophisticated techniques, the most well known being DesignPatterns.
It is quite natural to think of shell utilities as commandline interfaces (CLI) to some useful services, and usage of these services is possible by accessing their CLI and connecting to stdin/stdout. The benefits of object-orientation, though, require a __class interface__ for every service, so, in an OO environment we must dispose of the CLI in the basic design of these services. This is good because we provide CLI wrappers for shell users/scripts to access the services. On the other hand, applications can now access these services directly through their class interface, and grouping the classes according to their theme within frameworks will lead to better design.
The UNIX utilities (e.g. mv, cat, grep) are examples of utilities widely used in shell scripts, or by the shell user herself. The JosAccessories working group will provide wrapper implementations of these utilities, with the underlying classes coming from the JosBeans group, and additional classes which are needed by the wrappers. What classes exactly are implemented depends on already freely available code. Wherever there is an unrestricted class which is usable/extendable, we use it, and work together with the authors to exchange code.
-- RalfStephan, 12-Nov-97
I've ported some Linux command line utilities to Java.
These ports so far inlude ls, pwd, whoami, cd, mkdir, rmdir, cat, mv, echo and rm -- with more coming out regularly.
http://spin.com.mx/~kevinr/home.html
Kevin Raulerson
KevinR@spin.com.mx