From the osgi> prompt, the cjos command is the entry point to CjOS (the C++/Java Operating System). What can you do with the cjos command?
Any CjOS command
At a CjOS prompt, you can run any CjOS command without the cjos prefix. To embed CjOS in OSGi, without clashing with any existing OSGi command, we've implemented the cjos command as a prefix. The console for a CjOS command is redirected to the OSGi console.
ub command
osgi> cjos ub
The ub command is an entry point for the command-line Universal Browser. This browser uses the Smart API to resolve a URI. To run the browser in OSGi, use the cjos prefix.
For more information on available schemes, see also the JOS Technical Edition.
Example
osgi> cjos ub controller:resource:
This specification displays additional information about the resource: controller. A controller is a Java class; it implements one or more schemes.
smartlist command
osgi> cjos smartlist
The smartlist command displays a list of active schemes in Smart API. To run this command in OSGi, use the cjos prefix.
Tuesday, December 17, 2013
Monday, December 16, 2013
CjOS Project Revisited
The CjOS Project is a research project for a Java-based operating system with a combination of C/C++ and Java. The project has an emphasis on the Java-side of a Java-based operating system. The project has an emphasis on desktop, laptop and server machines. The project has emphasis on long-term stability of both API and implementation we like to call perfect backward compatibility.
Recent activity
One of the most active parts of the project right now is the investigation of OSGi. We're building OSGi modules from a large, monolithic Java class library.
Release 1.0
In addition, the first release of the OSGi initiative is now available. It brings many of the production-quality APIs from the CjOS Project to OSGi-compatible applications, such as the Eclipse platform and IBM WebSphere Application Server.
Example
Allow me to provide just one example of what you can do now. The Smart Archive feature enables your Java application to read a file inside an archive inside an archive inside an archive--without the use of temporary files. It also enables you to find files inside an archive inside an archive inside an archive--without the use of temporary files.
Tradition
The CjOS Project maintains a collection of Java archives. Traditionally, these Java archives are delivered to the Linux platform as a corresponding collection of RPMs. By adding the CjOS Project archives, you enable your Java application to benefit from a large, stable, backward-compatible, monolithic class library of working Java code.
Modular initiative
The previous collection of Java archives do not map directly to a collection of OSGi modules. Using the power of the XVCL Processor, we're re-generating existing Java source code into OSGi modules.
Discovery
By moving to OSGi, we have discovered and fixed hidden problems in our design and implementation. So, the OSGi initiative has improved the overall quality of the project.
Check it out
Download the recent release and experiment with it inside of your OSGi application.
Thanks for listening,
Recent activity
One of the most active parts of the project right now is the investigation of OSGi. We're building OSGi modules from a large, monolithic Java class library.
Release 1.0
In addition, the first release of the OSGi initiative is now available. It brings many of the production-quality APIs from the CjOS Project to OSGi-compatible applications, such as the Eclipse platform and IBM WebSphere Application Server.
Example
Allow me to provide just one example of what you can do now. The Smart Archive feature enables your Java application to read a file inside an archive inside an archive inside an archive--without the use of temporary files. It also enables you to find files inside an archive inside an archive inside an archive--without the use of temporary files.
Tradition
The CjOS Project maintains a collection of Java archives. Traditionally, these Java archives are delivered to the Linux platform as a corresponding collection of RPMs. By adding the CjOS Project archives, you enable your Java application to benefit from a large, stable, backward-compatible, monolithic class library of working Java code.
Modular initiative
The previous collection of Java archives do not map directly to a collection of OSGi modules. Using the power of the XVCL Processor, we're re-generating existing Java source code into OSGi modules.
Discovery
By moving to OSGi, we have discovered and fixed hidden problems in our design and implementation. So, the OSGi initiative has improved the overall quality of the project.
Check it out
Download the recent release and experiment with it inside of your OSGi application.
Thanks for listening,
Monolithic vs Modular Java
To start this series of articles on OSGi, we'll take a look at the difference between monolithic and modular.
Why is it important?
Monolithic and modular Java are part of the same software architectural spectrum. How much is monolithic and how much is modular in your Java application should be an explicit choice. How do you decide?
Non-Motivation
We hear people talking about modular Java. We see books on modular Java. Does that mean that everyone should start developing with a modular architecture? No, you decide if modular is right for you.
Monolithic Java
A monolithic class library is where all classes are part of a single, monolithic namespace. While there may be separate collections of Java archives, the namespace is reduced to a single list.
Simplicity. The monolithic class library is the original model. It is a simple model. All classes are available all of the time.
Very large namespace. The monolithic class library is a viable alternative for large business applications because Java supports a very large namespace. Hundreds of thousands of classes can be used in a business application without loading two classes with the same name at the same time.
In other words, many programming languages prior to Java technologies have been limited by a small namespace. The name of a dynamic link library on a well-known operating system, for example, was limited to just eight characters. Java technology has a limitation, too; but, it is sufficient to say that it is more than a hundred characters.
Static class path. When a class path that is static, it never changes throughout the lifetime of your Java application. This means that the potential list of available classes never changes. Classes are neither added nor removed during the lifetime of an OS process.
Modular Java
A modular class library is where there are multiple, concurrent namespaces. The namespace becomes a tree rather than a list.
Version. Technically, the Java technologies are quite capable of loading two classes with the same name as long as they are loaded by two different class loaders. This has been true since the first version of Java (JDK 1.0).
Volatile class path. When a class path is volatile, it is capable of changing over the lifetime of an application. Classes are added and removed without starting a new OS process.
Complex. Dynamic loading of a Java class involves a little more complexity. A fully implemented module system involves a lot of complexity and resolving a lot of issues.
Moving from monolithic to modular
Changing a software architecture requires research, investigation and establishing a new set of constraints and rules. When classes have been developed in a monolithic software architecture, they must be redeveloped in a modular software architecture. Fortunately for Java classes, redevelopment uses a lot of the same tools with different techniques.
Is it worth the effort?
The big question is: Is modular worth the effort? The answer is maybe yes, maybe no. It doesn't make sense to move everything written in Java to a modular software architecture. A lot of Java code has been written in a monolithic architecture and is fundamentally incompatible with a modular architecture. In other words, some class libraries should not be modularized.
Each class library needs to be evaluated for the benefits of modular architecture. And, ultimately, the benefit of maintaining a loosely-coupled collection of modules should be evaluated. What do you hope to gain from it?
About OSGi
One of the benefits of developing OSGi modules is running applications in Eclipse Rich Client Platform and one of the many Java application servers, such as IBM WebSphere.
Why is it important?
Monolithic and modular Java are part of the same software architectural spectrum. How much is monolithic and how much is modular in your Java application should be an explicit choice. How do you decide?
Non-Motivation
We hear people talking about modular Java. We see books on modular Java. Does that mean that everyone should start developing with a modular architecture? No, you decide if modular is right for you.
Monolithic Java
A monolithic class library is where all classes are part of a single, monolithic namespace. While there may be separate collections of Java archives, the namespace is reduced to a single list.
Simplicity. The monolithic class library is the original model. It is a simple model. All classes are available all of the time.
Very large namespace. The monolithic class library is a viable alternative for large business applications because Java supports a very large namespace. Hundreds of thousands of classes can be used in a business application without loading two classes with the same name at the same time.
In other words, many programming languages prior to Java technologies have been limited by a small namespace. The name of a dynamic link library on a well-known operating system, for example, was limited to just eight characters. Java technology has a limitation, too; but, it is sufficient to say that it is more than a hundred characters.
Static class path. When a class path that is static, it never changes throughout the lifetime of your Java application. This means that the potential list of available classes never changes. Classes are neither added nor removed during the lifetime of an OS process.
Modular Java
A modular class library is where there are multiple, concurrent namespaces. The namespace becomes a tree rather than a list.
Version. Technically, the Java technologies are quite capable of loading two classes with the same name as long as they are loaded by two different class loaders. This has been true since the first version of Java (JDK 1.0).
Volatile class path. When a class path is volatile, it is capable of changing over the lifetime of an application. Classes are added and removed without starting a new OS process.
Complex. Dynamic loading of a Java class involves a little more complexity. A fully implemented module system involves a lot of complexity and resolving a lot of issues.
Moving from monolithic to modular
Changing a software architecture requires research, investigation and establishing a new set of constraints and rules. When classes have been developed in a monolithic software architecture, they must be redeveloped in a modular software architecture. Fortunately for Java classes, redevelopment uses a lot of the same tools with different techniques.
Is it worth the effort?
The big question is: Is modular worth the effort? The answer is maybe yes, maybe no. It doesn't make sense to move everything written in Java to a modular software architecture. A lot of Java code has been written in a monolithic architecture and is fundamentally incompatible with a modular architecture. In other words, some class libraries should not be modularized.
Each class library needs to be evaluated for the benefits of modular architecture. And, ultimately, the benefit of maintaining a loosely-coupled collection of modules should be evaluated. What do you hope to gain from it?
About OSGi
One of the benefits of developing OSGi modules is running applications in Eclipse Rich Client Platform and one of the many Java application servers, such as IBM WebSphere.
Subscribe to:
Posts (Atom)