I am writing to know your views on using GNU Classpath in an entirely different setting. we have implemented a new object oriented programming language - Indus - that is best described as a common language front end to generate code (it generates Java, C and Small C) that can execute across a large variety of hardware platforms. Indus also introduces new types (agent, component) and new syntax/semantics (for agent coordination, component composition) which enables modeling of any application as a set of concurrently executing agents (think P2P) that cooperatively execute tasks. also, we have written a set of run time libraries that automate the management of distributed Indus objects (agents/components) - things like lifecycle management, transactions, routing, service discovery, run time connections, etc are taken care of transparently. NOW, what we are thinking of is this a) use Classpath as native Indus libraries - we will also need to add some additional library support for concurrent programming support b) make an additional subset of Classpath to meet the requirements of small footprint devices - problem with existing Classpath implementation is that it generates large volumes of C code (even when code pruning is applied)
What we would like to know is a) is altering the nomenclature, structure and composition of Classpath something that is desirable / agreeable and something we can work on - of course, we are keeping any future work under GPL b) what would be the best way of coordinating our efforts, if at all, that is feasible / produces benefits Regards Kallol _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
