Re: [xmlvm-users] OneJar and XMLVM

[Sascha H. <sa...@xm...>]

Let me chime in as well, as I did quite a lot of work recently to integrate
the OneJAR  mechanism into our processing pipeline ...

I agree with Joshua on this one. While I was skeptical when we introduced
the one-jar, I became a fan of it. There is a huge benefit of having a
single consistent JAR that just works and you don't have to bother with
anything else.

I invested quite a lot of time to improve the internal structures of XMLVM,
mainly the UniversalFile API, that makes it now very easy to handle the
situation where resources are located either inside or outside the One-JAR.

You said that things grow big. That is natural and as Joshua pointed out,
this is not a problem nowadays. Of course, if the One-Jar would become
hundreds of MBs big, that would be too much. But right now it doesn't feel
too big to download.
One more note on size: Of course things will get added, but we will
hopefully be able to significantly reduce the size of it soon. The OpenJDK
libs included contain too much stuff we will never need. Once we figured out
what is "junk", we will cut it out and we should be able to get rid of many
MBs easily.

The other argument you made is speed. Panayotis, you wrote a long e-mail
(which you ponted out yourself), but you failed to provide data: What I need
to to know are hard facts. Provide data about what takes how long and why
this is a problem, and how fast it would be in another case. THEN we we have
foundation to talk about and THEN we can maybe find other solutions as well.
For example: I don't know how the OneJAR mechanism exactly does its work,
but I agree with you in that it seams silly to extract parts of the OneJAR
that are not needed. E.g. when you just want to cross-compile a bunch of
files, you don't need to extract certain libs every time. However, with ZIP
files you can extract certain parts only, so it would make sense to have it
extract only the needed parts.
Another way to solve this is to extract things on first run and to cache it
on the disk to improve speed when executed again.

But again, for me what matters are numbers, and not assumptions. If you can
provide measurable numbers about *what's* slow, *why* it is bad and *how
fast* it could be, *then* we can talk concrete steps in improving the
situation.

// Sascha

2010/9/18 Lennie De Villiers <len...@gm...>

> This is one of the frustrations I'm starting to have to write
> Android->iPhone apps.
>
> On Fri, Sep 17, 2010 at 9:24 PM, Panayotis Katsaloulis
> <pan...@pa...> wrote:
> > On 17 Σεπ 2010, at 9:03 μ.μ., Arno Puder wrote:
> >
> >>
> >> fact is that we will soon add quite a bit more to the OneJar. The source
> >> code of the Boehm GC and (more importantly) the cross-compiled version
> >> of the OpenJDK. Especially the latter will increase the size of the
> >> OneJar significantly.
> >>
> >> In principle I like the OneJar approach for its simplicity: everything
> >> is bundled in one jar. However, we should make sure that the
> >> jar-inside-jar for huge files does not have any significant performance
> >> impact. If that should be the case, we definitely need to abandon the
> >> OneJar approach.
> >
> >
> > I totally agree. But I do think that the one jar approach makes system
> slow. For example, if you run xmlvm with no command line arguments, there is
> a significant time before displaying the help text, in order to unzip the
> contents of the file. This is an obvious problem but I also thing there are
> other performance issues elsewhere.
> >
> > One thing I thought and didn't discuss it is, if we want to develop a
> java-based iphone application, only the xml2objc jar should could be added
> to the project and not everything. Similar with Android projects... :) This
> will decrease developer frustration - I think.
> >
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
>
>
>
> --
> Lennie De Villiers Blog: http://lenniedevilliers.blogspot.com/
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>