harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Cai <greensi...@gmail.com>
Subject Re: [discuss] Harmony Select 6 definition
Date Thu, 30 Apr 2009 03:35:02 GMT
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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message