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]
