I think that was to be a part of the 1.1 release? Larry
On 7/28/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > You forgot to mention the part where it will byte-weave the compiled > diff into the classfile... > > geir > > On Jul 22, 2005, at 12:22 PM, Upayavira wrote: > > > Subvertive Incubator Proposal > > -------------------------- > > Here is a proposal for an incubator project that originally arose over > > beers at ApacheCon EU 2005, and was received with thunderous applause > > during the lightning talks at that same ApacheCon. > > > > Introduction > > ------------ > > Java, when first introduced, proposed mobile code. This proposal > > offers > > an extension to the definition of mobile code, allowing code to > > transfer > > between developer and application, server and client, dynamically, at > > runtime. > > > > It proposes a classloader that, whenever a class is loaded, checks > > with > > a subversion repository for changes to the class, downloads diffs and > > compiles the class before executing it. > > > > Sponsoring Members > > ------------------ > > Below are the Apache members who put their names behind this > > proposal: > > > > Erik Abele > > Danny Angus > > Noel Bergman > > Stefan Bodewig > > Ken Coar > > David Crossley > > Torsten Curdt > > Bertrand Delacretaz > > Lars Eilebrecht > > Justin Erenkrantz > > Brian Fitzpatrick > > Santiago Gala > > Martin Kraemer > > Raphael Luta > > Geir Magnusson Jr > > Jeremias Maerki > > Giacomo Pati > > Gianugo Rabellino > > Cliff Schmidt > > Henning Schmiedehausen > > Leo Simons > > Sander Striker > > Upayavira > > Sylvain Wallez > > Dirk Willem Van Gulik > > Carsten Ziegeler > > > > Below are the apache committers and other respected community members > > who wish to show their support for this project: > > > > Ugo Cei > > Marcus Crafter > > Daniel Fangerstrom > > Brian McCallister > > Alfred Nathaniel > > Ruediger Pluem > > Dalibor Topic > > Mladen Turk > > > > This proposal would like to offer this as the default classloader for > > the Harmony project. An official statement from Harmony was made about > > this project: > > > > "Harmony is interested in how this might develop" > > > > Use Case > > -------- > > Imagine a scenario. You have been called by a user who is using your > > software. They tell you that a popup has appeared saying "Null Pointer > > Exception" with a "mail it" button. You ask them to click on that > > button, and it mails you a stack trace. You can see a straightforward > > fix, which you commit to Subversion, and tell them to try it again. > > Their classloader checks Subversion, finds a change, downloads a diff, > > compiles, reloads the class and this time the user's application runs > > without flaw. > > > > Note, this dynamic would work via mailing lists too - imagine > > mailing a > > mailing list and hearing soon that a commit has been done to fix > > it, and > > your web server just starts working again. > > > > Subversion > > ---------- > > As Java can easily support HTTP requests, and there is already a JCI > > project within Jakarta (the Compiling Class Loader). Thus, in > > combination, the basic idea underlying this proposal would be very > > easy > > to implement with existing components. > > > > CVS > > --- > > However, not all projects use Subversion (SVN). Therefore, support for > > CVS will be required. An extension will be added that allows the > > classloader to talk the CVS pserver protocol. > > > > Some firewalls block pserver. Therefore, we will also allow the > > classloader to download the class changes via a viewcvs installation. > > And so that the maintainers of the viewcvs installation don't need to > > worry unnecessarily, we will set the user agent string used to that of > > Internet Explorer, so that it is not possible to identify requests > > from > > this classloader. > > > > Google > > ------ > > Imagine the scenario whereby a classloader is asked for a class > > that it > > doesn't know about. It does not exist in any of the SVN or CVS > > repositories known by the classloader. Therefore, the classloader will > > be extended to do a search for the class on Google, It will locate the > > classes original SVN or CVS server, download the class from that > > server, > > compile, and your application will just work with the class that > > couldn't be found. > > > > An insider from Google said about this proposal: "We can support > > the load [caused by this classloader]". > > > > This almost entirely kills the need for complex classpaths. Doesn't > > Java > > get so much easier? > > > > Mailing List Archives > > --------------------- > > Imagine an unlikely scenario where a Subversion server is not > > available, > > down for maintenance or such. This can be handled by, again with > > Google, > > searching mailing list archives for commit mails, and rebuilding the > > class from these diffs. > > > > Developer Support > > ----------------- > > The classloader will have additional support specifically for > > developers. > > > > Firstly, it can be configured to use a Swing client, which, when a > > class > > compilation fails, will pop up a Swing window, which allows the > > developer to fix the problem. Clicking submit will cause the > > classloader > > to recompile the new class. If it correctly compiles, it will also, > > optionally, commit the change back to the SVN repository. > > > > Where the application is running remotely, it will be possible for the > > classloader to send an IM or IRC message to the developer (based upon > > the Javadoc author tag) with the stacktrace. By reply, the author can > > provide a diff that will be used by the classloader when reloading the > > class. Again, the classloader can be used to recommit the change > > back to > > the repository. > > > > Where IM is not practicable, the stacktrace will be mailed to the > > project's mailing list, such that a fix can be arrived at promptly. > > > > Finally, an extension to the classloader will allow it to run Junit > > tests against the class before loading it. The above methods will be > > used to gain a correction if the tests fail. > > > > Extensions > > ---------- > > The classloader could be optimised to use bytecode manipulation when a > > diff is downloaded. Thus, only the diff needs to be recompiled, > > speeding > > the reloading of the class. > > > > Given the number of features described above, modularity is going > > to be > > important. Therefore, it is proposed that OSGi be used as an > > underlying > > framework for managing this modularity. > > > > Conclusion > > ---------- > > With all of the above functionality, build tools, such as Ant, or > > Maven, > > will no longer be required. Development work becomes so much more > > effective, using software becomes more immediate, and we can finally > > truly call our software development methodologies 'agile'. > > > > Required Resources > > ------------------ > > We are aiming to become a top-level project, > > > > subvertive.apache.org <http://subvertive.apache.org> > > > > potentially with several subprojects for e.g. integrating with other > > version control systems such as Visual SourceSafe and > > implementations of > > this concept in different languages. We plan to target at least > > the .Net > > CLR and the Parrot VM. > > > > Initial mailing lists: > > > > [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] > > > > Note we believe that niether a commits mailing list nor a > > development mailing list will be necessary as development shall > > after an initial > > bootstrapping period shall be taking place completely through the > > Subvertive Swing interface. > > > > Issue tracking: > > > > Jira please. > > > > Source repositories: > > > > In order to make it more likely that we will provide support early on > > for the widest range of SCM systems, we would like to request both CVS > > and SVN repositories, both named subvertive. > > > > IP Issues and Known Patents > > --------------------------- > > Several of the initial sponsors have informed us that they believe > > they > > may have relevant patents in this field. The CVSGrab developers have > > informed us that they have a patent pending regarding the IE browser > > emulation. However, all these parties have agreed to provide us with > > non-exclusive licenses under the proper RAND terms. > > > > Dependency on salaried developers > > --------------------------------- > > Considering the strong support for this project gathered during just 5 > > minutes at the ApacheCon conference, we are confident that this > > will not > > be an issue. In fact, several companies have indicated they are > > considering firing their developers if they push this forward, so we > > should be fine. > > > > The Future > > ---------- > > When we have got a prototype working, and a specification written, > > this > > specification will be put to the JCP as a JSR. The target date for > > doing > > this will be the first day of April. > > > > +1 from us. What do you think? > > > > - Upayavira and listed supporters, 22 July 2005 > > ApacheCon EU 2005 > > > > P.S. Congratulations if you got this far. In case you haven't > > worked it > > out yet, this is nothing more than a joke. Please carry on all > > discussion on this proposal on the community@apache.org list rather > > than > > on [EMAIL PROTECTED], so as not to polute the real discussions > > going on > > here :-) > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
