incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: Project Proposal: Subvertive
Date Thu, 28 Jul 2005 21:40:34 GMT
You forgot to mention the part where it will byte-weave the compiled  
diff into the classfile...


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.
> ---
> 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,
> 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:
> 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 list rather  
> than
> on general@incubator, so as not to polute the real discussions  
> going on
> here  :-)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Geir Magnusson Jr                                  +1-203-665-6437

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message