En, let me elaborate the idea.
Think about such a scenario. A user writes a media-player with Java/SWT and
wants to distribute it. He wants to embed a Java runtime with just enough
modules which are required by the media-player. He can then use the tool I'm
talking about here to scan his application and assemble a customized Harmony
Select runtime for his media-player's use.
So I guess my idea is a more high-level one, a real end-user tool, rather
than the underlying mechanism like OSGi.
Hope this explains.
-Jack
2009/4/29 Alexei Fedotov <alexei.fedotov@gmail.com>
> Jack, you wrote:
>
> > Going forward, it will be
> > nice if we can provide some tooling to help users identifiy which modules
> > his/her app needs and create a customized "Select" runtime on the fly.
>
> Did you mean adopting OSGi implementation here? Why we should invent a
> tool for generating runtimes on "fly" for a language with a dynamic
> linking which has a mature (10 year old) "bundle" provisioning
> specification?
>
> Thanks!
>
>
>
> On Wed, Apr 29, 2009 at 11:15 AM, Jack Cai <greensight@gmail.com> wrote:
> > I like the Harmony Select idea. It will do much good for applications who
> > want to bundle a runtime for themselves. Eclipse might be a good example
> > which can take advantage of this.
> >
> > I think that Tim gave a good list to start with. Going forward, it will
> be
> > nice if we can provide some tooling to help users identifiy which modules
> > his/her app needs and create a customized "Select" runtime on the fly.
> >
> > -Jack
> >
> > 2009/4/27 Tim Ellison <t.p.ellison@gmail.com>
> >
> >> Last week, in the lessons learned thread, we talked about having a
> >> reduced footprint runtime delivery based upon our Java 6 branch [1].
> >>
> >> The goal would be to get exposure of the Java 6 code in a form that is
> >> still useful to a wide class of (headless) programs. Using Harmony's
> >> modular architecture we can quite easily deliver on the Java 6 modules
> >> that are further developed at the moment, with plans to back-fill the
> >> other modules as they become available.
> >>
> >> Here's a strawman proposal about what I think should be in the "Harmony
> >> Select" build:
> >>
> >> Included
> >> ANNOTATION ARCHIVE AUTH
> >> BEANS CONCURRENT CRYPTO
> >> JNDI INSTRUMENT LANG-MANAGEMENT
> >> LOGGING LUNI MATH
> >> NIO NIO_CHAR PACK200
> >> PREFS REGEX SECURITY
> >> SQL TEXT XML
> >> X-NET
> >>
> >>
> >> Which means the following modules would be left out:
> >> ACCESSIBILITY APPLET AWT
> >> IMAGEIO ORB PRINT
> >> RMI SOUND SWING
> >> X_MGT
> >>
> >>
> >> I chose the above lists somewhat arbitrarily based upon the Java 5 build
> >> content. I haven't listed some modules we might want to include that
> >> are Java 6 specific (e.g. JAXB).
> >>
> >> Discuss :-)
> >> - Can you imagine paring down the 'Included' list any further?
> >> - What is missing from the list that must be there to make it useful?
> >>
> >> [1] http://markmail.org/thread/zaz4hzg6xes5fijj
> >>
> >> Regards,
> >> Tim
> >>
> >
>
>
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://www.telecom-express.ru/
> http://people.apache.org/~aaf/ <http://people.apache.org/%7Eaaf/>
> http://harmony.apache.org/
> http://code.google.com/p/openmeetings/
>
|