Forums

In the recent libSBML survey, people frequently asked for a
pure Java implementation. We're considering it. Developing
it would be a non-trivial undertaking and have serious
maintenance implications, for example because we would have
two separate code bases to deal with. We have some ideas
for how to avoid rewriting some of the more complex parts,
but here are some issues we don't know what to do about:

1) When libSBML 5 is introduced with its modular extension
mechanism to support SBML Level 3 packages, and we
request other developers to provide implementations of L3
packages, would people have to provide *both* a regular
implementation (including a SWIG interface definition for
Java) and a pure Java implementation? If not, then who
will implement the other version?

2) Level 3 package support should come with validation code,
so that libSBML can do validation on models that include
the given L3 package. The validator built into libSBML
will likely be modularized to support extensions for L3
packages. Will developers who implement support for L3
packages also have to provide validator code in *both*
C/C++ and pure Java form, if a pure Java version of
libSBML exists?

We'd like your opinions on what to do.

MH
P.S. If you haven't already done so, please do the survey:
http://sbml.org/SBML_Projects/Development/LibSBML_survey_2009

____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hello, Neil, All,

On Mon, May 18, 2009 at 4:32 PM, Neil Swainston
<neil.swainston@manchester.ac.uk> wrote:
> Did you get convincing reasons as to why the current JNI approach is
> unsatisfactory?

Have you ever tried to deploy across different platforms?

A pure Java version can easily be deployed across platforms without
change (ideally). However, if you depend on binaries, you need to
provide different ones for each platform. If a system already has the
binary installed but in a version incompatible with your software,
then you have a problem. You can still run it in a cage such as with
Java Webstart, but that is infinitely harder to deploy and debug than
just putting a pure Java application in a JAR for download.

The JNI approach also prevents you from avoiding redundancies, for
example, libSBML needs native XML support, and your application may
need Java XML support in addition to that.

Take care
Oliver

--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

* Michael Hucka <mhucka@caltech.edu> [2009-05-18 21:18] writes:
> In the recent libSBML survey, people frequently asked for a
> pure Java implementation. We're considering it. Developing
> it would be a non-trivial undertaking and have serious
> maintenance implications, for example because we would have
> two separate code bases to deal with. We have some ideas
> for how to avoid rewriting some of the more complex parts,

Whew, that sounds like a nightmare. It also doesn't sound very
sustainable in the long run--my prediction would be that after lurching
along as a hybrid for a few years, you'd eventually collapse back into one
codebase. If the majority of people wish libSBML was written in Java, you
might consider switching to Java instead of C++, which would make me sad,
but still sounds better to me than trying to be a hybrid.

You also have to consider the speed at which your team can provide
updates. I can't say what the survey responders would prefer, but I know
that if I had to make a choice between more frequent updates and a code
base written in my favorite language, I'd choose more frequent updates.
This would apply to a language switch as well as a switch to being a
hybrid, the only difference being that a language switch might
theoretically pay off in the future if it became easier for your team to
code in the new language, while a switch to being a hybrid would not only
eat up time now, it would continue to eat up time in the future, and would
therefore never pay off.

The cost/benefit analysis is looking pretty grim from this end.

> 1) When libSBML 5 is introduced with its modular extension
> mechanism to support SBML Level 3 packages, and we
> request other developers to provide implementations of L3
> packages, would people have to provide *both* a regular
> implementation (including a SWIG interface definition for
> Java) and a pure Java implementation? If not, then who
> will implement the other version?

If you up the requirements, you will get less help. So I think that apart
from asking nicely, if you go to a hybrid system you are commiting your
team to implementing the other version of the submitted module. IIRC, you
are already basically committing your team to maintain supplied packages,
right? So this might not be quite as bad as it might otherwise be. But
again, it's a huge cost in terms of time. If you were going to have to
write the extension yourself, by going hybrid you just killed any benefit
you were hoping to receive by asking for outside development support.
There's also either an added lag time between one version and the next
coming out, or an added lag time of anything coming out if you want to
release both at once.

> 2) Level 3 package support should come with validation code,
> so that libSBML can do validation on models that include
> the given L3 package. The validator built into libSBML
> will likely be modularized to support extensions for L3
> packages. Will developers who implement support for L3
> packages also have to provide validator code in *both*
> C/C++ and pure Java form, if a pure Java version of
> libSBML exists?

Same answer here--you can't expect to receive both versions of the code,
though you can ask. Which means you're committing your team to doing it.

My vote (which is worth the pixels its printed on (which if it was a
usenet post would be hundreds if not thousands of dollars!)) is:

1) A single-language codebase in my favorite language
2) A single-language codebase in a different language, with bindings for
mine.
3) A hybrid double codebase which includes my favorite language.

-Lucian
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

So, here's a question for you. The Virtual Cell group has
(I imagine) one of the biggest Java code bases -- so what
happens now, with the current native binary version of
libSBML? How much trouble has it been to use in VCell?

MH

>>>>> On 18 May 2009, Oliver Ruebenacker <curoli@gmail.com> wrote:

curoli> Have you ever tried to deploy across different
curoli> platforms?
curoli>
curoli> A pure Java version can easily be deployed across
curoli> platforms without change (ideally). However, if
curoli> you depend on binaries, you need to provide
curoli> different ones for each platform. If a system
curoli> already has the binary installed but in a version
curoli> incompatible with your software, then you have a
curoli> problem. You can still run it in a cage such as
curoli> with Java Webstart, but that is infinitely harder
curoli> to deploy and debug than just putting a pure Java
curoli> application in a JAR for download.
curoli>
curoli> The JNI approach also prevents you from avoiding
curoli> redundancies, for example, libSBML needs native
curoli> XML support, and your application may need Java
curoli> XML support in addition to that.
curoli>
curoli> Take care Oliver

____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hi all,

I take on board the complications surrounding platform independence
and the hassles therein.

As far as the second issue goes, I agree that it would be nice to
exploit Java features such as this (and equals() and comparable
methods etc.) but personally don't think that it would be a huge
amount of hassle to put together a few helper classes for us Javans to
do things like this:

/**
*
* @param model
* @return List<Species>
*/
public static List<Species> getListOfSpecies( final Model model )
{
final List<Species> list = new ArrayList<Species>();
final ListOfSpecies listOfSpecies = model.getListOfSpecies();

for( long l = 0; l < listOfSpecies.size(); l++ )
{
list.add( listOfSpecies.get( l ) );
}

return list;
}

I'm not sure that it's Mike et al.'s responsibility to do things that
we could be doing and sharing between ourselves. I've got a library of
libsbml-related Java classes that I recently shared up at http://sbml.org/Community/Programs/libAnnotationSBML
. I'm sure other Java-ites have the odd class that would be of
interest to the community as a whole. I reckon if we're more active in
sharing them, then I'd imagine that the requests for a pure Java
implementation would diminish.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England

On 18 May 2009, at 23:08, Michael Hucka wrote:

>>>>>> On 18 May 2009, Neil Swainston
>>>>>> <neil.swainston@manchester.ac.uk> wrote:
> NS> Hi Mike, Did you get convincing reasons as to why the
> NS> current JNI approach is unsatisfactory?
>
> Hi Neil,
>
> It's mostly the expected reasons -- portability, deployment,
> and Java-ishness of the API.
>
> Since the survey is anonymous, I think it's ok to report the
> specific comments about this issue here. Here they are (in
> no particular order):
>
> "The Java binding currently leads to plattform dependence
> of libSBML and therefore the great advantage of the
> plattform independence of Java gets lost. It would be
> beneficial to have a Java implementation."
>
> "The java API could make use of java generics instead of
> having a ListOfX for every type X. For example,
> List<Species> instead of ListOfSpecies."
>
> "I know it isn't really practical at all, but I really
> dislike having to install the C++ libs everywhere I want to
> use the jars :)"
>
> "Having a pure java libSBML."
>
> MH
>
> ____________________________________________________________
> To manage your libsbml-development list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>
> For a web interface to the libsbml-development mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the libsbml-development list,
> contact sbml-team@caltech.edu
>

____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hello Mike,

I think you are addressing 2 different issues here. The first is
whether its is desirable/feasible to provide a pure java version of
libsbml. Whereas the second is whether official extension need to
provide libsbml support.

I think the later is easier to decide. The reality is that we can not
enforce it, especially not the constant maintenance of such a support
library. Thus the existence of an libsbml extension for SBML packages
as a requirement for an official SBML L3 package should not be made.

Regarding the pure Java support. In another thread you said that
portability would be a benefit of such an implementation. My personal
experience is that the gain is minimal. We have less problems compiling
the C++ version of libsbml on any platform as to getting it to work
with the different java installation. In theory the latter should be
trivial but it is not. A pure java implementation will face similar
problems. This is why most larger java based application ship with
their own particular java version.

In a world with unlimited resources a pure java implementation is
nevertheless desirable. But we have limited resources and I would
prefer to spend them on increasing the reliability and improving the
java bindings or making them more java like. This seems to me a far more
efficient approach.

Another often mentioned concern is the ability to deal with large
models. I think that java is not the ideal way to address this.


Thanks,
Stefan


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.edu
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hello Stefan, All,

If the portability gain from a pure Java implementation is minimal,
then I am wondering why including libSBML causes me ten times as much
headache than including the other ten Java libraries.

Maybe we are talking about two different scenarios here: If you
deploy an application that requires libSBML and you require your users
to set up libSBML themselves, it may not be such a big difference. But
that's not what we want: We want to offer an application that runs out
of the box. If it is all Java, I can put all class files into one JAR
file, and that is so much easier to both developers and users.

Take care
Oliver

On Tue, May 19, 2009 at 10:55 AM, Stefan Hoops <shoops@vbi.vt.edu> wrote:
> Hello Mike,
>
> I think you are addressing 2 different issues here. The first is
> whether its is desirable/feasible to provide a pure java version of
> libsbml. Whereas the second is whether official extension need to
> provide libsbml support.
>
> I think the later is easier to decide. The reality is that we can not
> enforce it, especially not the constant maintenance of such a support
> library. Thus the existence of an libsbml extension for SBML packages
> as a requirement for an official SBML L3 package should not be made.
>
> Regarding the pure Java support. In another thread you said that
> portability would be a benefit of such an implementation. My personal
> experience is that the gain is minimal. We have less problems compiling
> the C++ version of libsbml on any platform as to getting it to work
> with the different java installation. In theory the latter should be
> trivial but it is not. A pure java implementation will face similar
> problems. This is why most larger java based application ship with
> their own particular java version.
>
> In a world with unlimited resources a pure java implementation is
> nevertheless desirable. But we have limited resources and I would
> prefer to spend them on increasing the reliability and improving the
> java bindings or making them more java like. This seems to me a far more
> efficient approach.
>
> Another often mentioned concern is the ability to deal with large
> models. I think that java is not the ideal way to address this.
>
>
> Thanks,
> Stefan
>
>
> --
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute - 0477
> Virginia Tech
> Bioinformatics Facility II
> Blacksburg, Va 24061, USA
>
> Phone: (540) 231-1799
> Fax:   (540) 231-2606
> Email: shoops@vbi.vt.edu
> ____________________________________________________________
> To manage your libsbml-development list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>
> For a web interface to the libsbml-development mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the libsbml-development list,
> contact sbml-team@caltech.edu
>
>



--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Let me ask a different question. If we don't go the route
of implementing a pure java version, are there things that
we can do with the current scheme to reduce implementation
and portability headaches for people?

Maybe some of the problems are things that we can fix by
taking a hard look at the current code base, and improving
that. If we can address even 50% of the problems, it sounds
like that would be a significant help (roughly X * 50% fewer
headaches in the world, where X is the number of people
trying to deploy Java-based apps with libSBML).

Can we identify precisely the common problems?

MH


____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hi Oliver, All,

> in practical terms, mistakes are made easily and
> finding and correcting them is extremely time-consuming.


That's exactly why I advocate having a Java Web Start "module" that
users (us) can import. That way, only one person (I nominate Mike!)
has to go through the time-consuming steps of finding and correctly
mistakes, leaving us to do something much more interesting instead.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England

On 19 May 2009, at 18:10, Oliver Ruebenacker wrote:

> Hello Neil, All,
>
> Thanks, but writing the JNLP file is the easy part. In theory, Java
> webstart is easy, but in practical terms, mistakes are made easily and
> finding and correcting them is extremely time-consuming.
>
> Take care
> Oliver
>
> On Tue, May 19, 2009 at 6:01 AM, Neil Swainston
> <neil.swainston@manchester.ac.uk> wrote:
>> Hi all,
>>
>> Just looking a little further into Oliver's issue, the following may
>> be useful:
>>
>> http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html#213
>>
>> Effectively, it seems that we could use the Java Help example and do
>> something similar for versions of libsbml. So, if I was to create a
>> Java web start application using libsbml, I could write something
>> similar to the following in my jnlp doc...
>> <jar href="neils_app.jar"/>
>> <extension name="libsbml3_3_1" href="http://www.sbml.org/jws/3_3_1/libsbml.jnlp
>> "/>
>> So, I would be downloading the appropriate version of libsbml from
>> sbml.org, where the contents of libsbml.jnlp would look a little like
>> this...
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <jnlp spec="1.0+" codebase="http://www.sbml.org/jws/3_3_1"
>> href="libsbml.jnlp">
>> <information>
>> <title>libsbml</title>
>> <vendor>sbml.org</vendor>
>> </information>
>> <resources os="Windows">
>> <nativelib href="natLibWin.jar"/>
>> </resources>
>> <resources os="Linux">
>> <nativelib href="natLibLinux.jar"/>
>> </resources>
>> <resources os="Mac OS X">
>> <nativelib href="natLibMac.jar"/>
>> </resources>
>> <component-desc/>
>> </jnlp>
>>
>> The production of libsbml.jnlp and the appropriate three jar files
>> would only have to be done once per release of libsbml, and then all
>> of us can deploy our stuff using Java Web Start with the minimum of
>> fuss.
>>
>> Obviously this is pseudo code, and issues would arise from this. But
>> I'd guess that less issues would arise from this than from
>> duplicating
>> the entire libsbml effort to produce a pure Java version.
>>
>> Cheers,
>>
>> Neil.
>>
>>
>> Neil Swainston
>> Experimental Officer
>>
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> England
>>
>> On 19 May 2009, at 00:25, Oliver Ruebenacker wrote:
>>
>>> Hello Mike, All,
>>>
>>> Users click on a link on our website and Java Webstart selects the
>>> appropriate binary among three options: Windows, Mac and Linux.
>>>
>>> We have a person responsible for deployment (Fei Gao) who has been
>>> doing this for years and I am assuming she is on top of it.
>>>
>>> Meanwhile, I developed a stand-alone application (SyBiL) that uses
>>> libSBML and deployed it myself on our website, also using Java
>>> Webstart. You need to have binaries for Win, Mac and Linux in the
>>> same
>>> version you use for development. If the application needs access to
>>> the file system (ours do), all JAR files need to be signed.
>>>
>>> In principle, it is not hard to do. In practical terms, it can be
>>> painful, because you either redeploy (upload to webspace and
>>> download
>>> again with your browser) all files together, which can take time if
>>> your application is large, or you try to redeploy only the files
>>> that
>>> need updating and easily pick the wrong ones. If you fail to
>>> suppress
>>> caching, this can create artificial version conflicts and other
>>> irreproducible behaviour.
>>>
>>> Of course, if you are willing to invest the work, you can do things
>>> like set up a local webspace on the same computer you use for
>>> development, or set up some clever automatation.
>>>
>>> And, of course, this requires that three binaries are enough to
>>> cover all users you intend to have, and that you have the means to
>>> test deployment of every one of them. Maybe true these days, but who
>>> knows how that will be in the future.
>>>
>>> Take care
>>> Oliver
>>>
>>> On Mon, May 18, 2009 at 6:13 PM, Michael Hucka <mhucka@caltech.edu>
>>> wrote:
>>>> So, here's a question for you. The Virtual Cell group has
>>>> (I imagine) one of the biggest Java code bases -- so what
>>>> happens now, with the current native binary version of
>>>> libSBML? How much trouble has it been to use in VCell?
>>>>
>>>> MH
>>>>
>>>>>>>>> On 18 May 2009, Oliver Ruebenacker <curoli@gmail.com> wrote:
>>>>
>>>> curoli> Have you ever tried to deploy across different
>>>> curoli> platforms?
>>>> curoli>
>>>> curoli> A pure Java version can easily be deployed across
>>>> curoli> platforms without change (ideally). However, if
>>>> curoli> you depend on binaries, you need to provide
>>>> curoli> different ones for each platform. If a system
>>>> curoli> already has the binary installed but in a version
>>>> curoli> incompatible with your software, then you have a
>>>> curoli> problem. You can still run it in a cage such as
>>>> curoli> with Java Webstart, but that is infinitely harder
>>>> curoli> to deploy and debug than just putting a pure Java
>>>> curoli> application in a JAR for download.
>>>> curoli>
>>>> curoli> The JNI approach also prevents you from avoiding
>>>> curoli> redundancies, for example, libSBML needs native
>>>> curoli> XML support, and your application may need Java
>>>> curoli> XML support in addition to that.
>>>> curoli>
>>>> curoli> Take care Oliver
>>>>
>>>> ____________________________________________________________
>>>> To manage your libsbml-development list subscription, visit
>>>> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>>>>
>>>> For a web interface to the libsbml-development mailing list, visit
>>>> http://sbml.org/Forums/
>>>>
>>>> For questions or feedback about the libsbml-development list,
>>>> contact sbml-team@caltech.edu
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Oliver Ruebenacker, Computational Cell Biologist
>>> BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
>>> Center for Cell Analysis and Modeling
>>> http://www.oliver.curiousworld.org
>>> ____________________________________________________________
>>> To manage your libsbml-development list subscription, visit
>>> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>>>
>>> For a web interface to the libsbml-development mailing list, visit
>>> http://sbml.org/Forums/
>>>
>>> For questions or feedback about the libsbml-development list,
>>> contact sbml-team@caltech.edu
>>>
>>
>> ____________________________________________________________
>> To manage your libsbml-development list subscription, visit
>> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>>
>> For a web interface to the libsbml-development mailing list, visit
>> http://sbml.org/Forums/
>>
>> For questions or feedback about the libsbml-development list,
>> contact sbml-team@caltech.edu
>>
>>
>
>
>
> --
> Oliver Ruebenacker, Computational Cell Biologist
> BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
> Center for Cell Analysis and Modeling
> http://www.oliver.curiousworld.org
> ____________________________________________________________
> To manage your libsbml-development list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>
> For a web interface to the libsbml-development mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the libsbml-development list,
> contact sbml-team@caltech.edu
>

____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Stefan Hoops wrote:
> Hello Mike,
>
> I think you are addressing 2 different issues here. The first is
> whether its is desirable/feasible to provide a pure java version of
> libsbml. Whereas the second is whether official extension need to
> provide libsbml support.
>
> I think the later is easier to decide. The reality is that we can not
> enforce it, especially not the constant maintenance of such a support
> library. Thus the existence of an libsbml extension for SBML packages
> as a requirement for an official SBML L3 package should not be made.
>
>
I agreed that it would be hard to require that. But in practice, if
there is not such an extension, the
SBML L3 package will be less used/supported I think.
> Regarding the pure Java support. In another thread you said that
> portability would be a benefit of such an implementation. My personal
> experience is that the gain is minimal. We have less problems compiling
> the C++ version of libsbml on any platform as to getting it to work
> with the different java installation.
I think, you are exactly speaking about one of the problem here, it is
difficult to make the libsbml bindings works properly.
And you have to compile first (or ask the users to compile) libsbml for
the different platforms before trying to setup the java bindings.
With a pure java implementation, all of that is gone.
> In theory the latter should be
> trivial but it is not. A pure java implementation will face similar
> problems. This is why most larger java based application ship with
> their own particular java version.
>
Wrong assumption here, the jre is often ship with an application to be
sure it is available to run the application and
that the user do not need to do anything else that click a button to
launch and run it properly.
May be Oracle is one of the only one that ship their own JVM in purpose
but it will probably change in the near future.

> In a world with unlimited resources a pure java implementation is
> nevertheless desirable. But we have limited resources and I would
> prefer to spend them on increasing the reliability and improving the
> java bindings or making them more java like. This seems to me a far more
> efficient approach.
>
There is no certainty that this path will be the less time consuming.

> Another often mentioned concern is the ability to deal with large
> models. I think that java is not the ideal way to address this.
>
Again, an other misconception, most applications dealing with terabytes
of data developed at EBI are written in Perl or Java.
And, the most important point is that java application are tolerant to
errors and reliable and performance is not anymore a problem this days.

Nico



____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hello Nico,

On Wed, 20 May 2009 09:47:51 +0100
Nicolas Rodriguez <rodrigue@ebi.ac.uk> wrote:

> Stefan Hoops wrote:
> > Hello Mike,
> >
> > I think you are addressing 2 different issues here. The first is
> > whether its is desirable/feasible to provide a pure java version of
> > libsbml. Whereas the second is whether official extension need to
> > provide libsbml support.
> >
> > I think the later is easier to decide. The reality is that we can
> > not enforce it, especially not the constant maintenance of such a
> > support library. Thus the existence of an libsbml extension for
> > SBML packages as a requirement for an official SBML L3 package
> > should not be made.
> >
> >
> I agreed that it would be hard to require that. But in practice, if
> there is not such an extension, the
> SBML L3 package will be less used/supported I think.

This correct but we must not confuse libsbml which is an SBML enabling
tool and SBML. I agree that it is in the best interest of any package
to provide an libsbml extension.

> > Regarding the pure Java support. In another thread you said that
> > portability would be a benefit of such an implementation. My
> > personal experience is that the gain is minimal. We have less
> > problems compiling the C++ version of libsbml on any platform as to
> > getting it to work with the different java installation.
> I think, you are exactly speaking about one of the problem here, it
> is difficult to make the libsbml bindings works properly.
> And you have to compile first (or ask the users to compile) libsbml
> for the different platforms before trying to setup the java bindings.
> With a pure java implementation, all of that is gone.

This is correct however the availability of libsbml installation
packages would relieve this issue considerably and is far easier to
achieve than providing pure java bindings. Additionally this approach
would benefit all the user of other language bindings too.

> > In theory the latter should be
> > trivial but it is not. A pure java implementation will face similar
> > problems. This is why most larger java based application ship with
> > their own particular java version.
> >

> Wrong assumption here, the jre is often ship with an application to
> be sure it is available to run the application and
> that the user do not need to do anything else that click a button to
> launch and run it properly.
> May be Oracle is one of the only one that ship their own JVM in
> purpose but it will probably change in the near future.

No, I have seen multiple commercial software package which ship a
particular version of the JVM. This is not necessarily a modified
version, i.e., it comes directly from SUN (now Oracle since you mention
it). This leads to the fact that you have multiple JVM installed. The
assumption that all java software works with all JVM is definitely
incorrect.

>
> > In a world with unlimited resources a pure java implementation is
> > nevertheless desirable. But we have limited resources and I would
> > prefer to spend them on increasing the reliability and improving the
> > java bindings or making them more java like. This seems to me a far
> > more efficient approach.
> >

> There is no certainty that this path will be the less time consuming.

Yes, but it is very likely. The only thing which the addition of a pure
java binding would remove from the libsbml development tasks is to
maintain the java bindings. I think it is very unlikely that the
maintenance of the bindings is more time consuming than developing and
maintaining a pure java implementation.


> > Another often mentioned concern is the ability to deal with large
> > models. I think that java is not the ideal way to address this.
> >
> Again, an other misconception, most applications dealing with
> terabytes of data developed at EBI are written in Perl or Java.
> And, the most important point is that java application are tolerant
> to errors and reliable and performance is not anymore a problem this
> days.

As long as you stream the data I agree that Perl and java will do a
sufficiently good task. However, the memory overhead of holding the
data is far larger than in C (or C++). As far as I recollect is most of
the EBI terabytes of data in databases and the Perl and java programs
handle only the return of SQL queries.

The error tolerance of any software is not depending on the programming
language. It is depending on the error handling the developers
implement and the amount of quality insurance (testing) part of the
development process. The libsbml has done a fantastic task to develop
and maintain a huge amount of tests to assure the quality of libsbml.

Thanks,
Stefan


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.edu
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hello Mike

On Wed, 20 May 2009 12:35:09 -0700
"Michael Hucka" <mhucka@caltech.edu> wrote:

> Let me throw out another idea about this.
>
> Suppose (hypothetically speaking :-)) that we were to
> introduce a web service for libSBML [+], and produce a pure
> Java version that is *not* a *complete* reimplementation,
> but instead called on the web service version for certain
> complex operations such as model validation, unit analysis,
> etc. My thinking is that this would address multiple
> problems:
>
> 1) It would permit a pure java implementation
>
> 2) It would do it without incurring the implementation and
> maintenance cost of reproducing the entire libsbml code
> base. There would still be only one code base for some
> of the really hairy bits that are also the most worrisome
> from the standpoint of ensuring identical behavior.
>
> 3) It would also make the pure java deployable smaller in
> size than a full libsbml java implementation would be.
>
> Downsides:
>
> 1) Some of the libsbml functionality in the pure java
> version would require a network connection to use.
> We'd be careful to make them only things that have to be
> deliberately called, not common operations.
>
> 2) It wouldn't solve the problem of having to implement
> Level 3 packages twice. (You wouldn't want to implement
> them only in the libsbml core and then make all of it
> accessible over the web service; the point of the
> approach being proposed here is that *most* of the
> libsbml functionality would be in the pure java client.
> I don't see that L3 packages would not be sufficiently
> heavy to qualify.)
>
> We would have to figure out which operations are most
> worthwhile doing via the web, balancing the size of data
> transfer involved versus the complexity of the code in
> libsbml that would be saved from reimplementation. I also
> have ideas for how to provide a high-availability facility
> for the web service, so that people wouldn't all have to hit
> a single server sitting under my desk at Caltech :-).
>
> This seems like a workable compromise, no?
>
> Can people try to think about the weaknesses and shot holes
> into this scheme? Likewise, if there are some additional
> clever hacks we could do, please mention them. If we're
> going to write a grant proposal to get more developers to do
> this, we'd better know about possible counter-arguments now.
>
> Footnotes:
> [+] Frank Bergmann already provides a web service system
> exposing much of the libSBML API. The web service proposed
> here would admittedly replicate a significant chunk of that.
> However, it would do it in different ways, so it would not
> be an identical system.
>
> MH
>

I think that providing a web service would be great. This would not only
benefit any Java application it would also benefit any other
application able to communicate with web services. It would definitely
ease the deployment problems Oliver is facing. The drawback of the
need to be connected to the Internet is for his Java web start
environment not existent.

Of course it would be nice if we could have some people providing such
a web service for the general public. To spin this further these
services should be registered it in Biomoby ...

Mike I really like that :)

Thanks,
Stefan


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.edu
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hi Stefan,

I changed the subject because we are diverting from the original question.

Stefan Hoops wrote:
> On Wed, 20 May 2009 09:47:51 +0100
> Nicolas Rodriguez <rodrigue@ebi.ac.uk> wrote:
>
>
>>> Another often mentioned concern is the ability to deal with large
>>> models. I think that java is not the ideal way to address this.
>>>
>>>
>> Again, an other misconception, most applications dealing with
>> terabytes of data developed at EBI are written in Perl or Java.
>> And, the most important point is that java application are tolerant
>> to errors and reliable and performance is not anymore a problem this
>> days.
>>
>
> As long as you stream the data I agree that Perl and java will do a
> sufficiently good task. However, the memory overhead of holding the
> data is far larger than in C (or C++). As far as I recollect is most of
> the EBI terabytes of data in databases and the Perl and java programs
> handle only the return of SQL queries.
>
>
Just for infos, no, the majority is not handle by database but flat files.
The ebi general search (EB-eye) is using XML dump of oracle and mysql DB
and is entirely in java.
All the textmining services, searching medline are also based on flat
file and java.

Nico


____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu

Hello,

I love the pure Java plus web service idea!

(1) VCell is already based on web service, so another web service
would add not much difficulty. Users webstart the client from
vcell.org and connect to the VCell servers.

(2) The stand-alone version of the Systems Biology Linker (SyBiL),
which uses BioPAX to build and annotate SBML models, uses only a small
subset of SBML, which means there is not much need for verification
beyond what the libSBML API already provides. Also SyBiL depends on
the Jena Semantic Web Framework, which includes already XML support
(Xerces), which makes it unfortunate that libSBML needs to bring in
its own XML support.

(3) I expect that in a few years, most users will sit in front of
light-weight terminals and have most of their computational needs
served over the Internet. Applications depending on libSBML -
regardless of which mode or variant, Java or C++ - will run almost
exclusively on servers. Clients will do little more than translating
between user interface, data and communication with the server.

Take care
Oliver

On Thu, May 21, 2009 at 6:23 AM, Nicolas Rodriguez <rodrigue@ebi.ac.uk> wrote:
> Michael Hucka wrote:
>> Let me throw out another idea about this.
>>
>> Suppose (hypothetically speaking :-)) that we were to
>> introduce a web service for libSBML [+], and produce a pure
>> Java version that is *not* a *complete* reimplementation,
>> but instead called on the web service version for certain
>> complex operations such as model validation, unit analysis,
>> etc.  My thinking is that this would address multiple
>> problems:
>>
>> 1) It would permit a pure java implementation
>>
>> 2) It would do it without incurring the implementation and
>>    maintenance cost of reproducing the entire libsbml code
>>    base.  There would still be only one code base for some
>>    of the really hairy bits that are also the most worrisome
>>    from the standpoint of ensuring identical behavior.
>>
>> 3) It would also make the pure java deployable smaller in
>>    size than a full libsbml java implementation would be.
>>
>> Downsides:
>>
>> 1) Some of the libsbml functionality in the pure java
>>    version would require a network connection to use.
>>    We'd be careful to make them only things that have to be
>>    deliberately called, not common operations.
>>
> Great idea to have a web-service, I was about to propose that as well
> but was thinking also to have few native call for these complex operations.
> In fact, we could have both, with some configuration options to use
> either webservice, native or nothing (with some lost of functionalities).
>
> Looking at some JNI documentations, I think there is room for
> improvement if we do few native call but it will still be difficult to
> have something rock solid.
> http://en.wikipedia.org/wiki/Java_Native_Interface#Pitfalls "subtle
> errors in the use of JNI can destabilize the entire JVM in ways that are
> very difficult to reproduce and debug"
> http://java.sun.com/docs/books/jni/html/pitfalls.html#25706
>
>> 2) It wouldn't solve the problem of having to implement
>>    Level 3 packages twice.  (You wouldn't want to implement
>>    them only in the libsbml core and then make all of it
>>    accessible over the web service; the point of the
>>    approach being proposed here is that *most* of the
>>    libsbml functionality would be in the pure java client.
>>    I don't see that L3 packages would not be sufficiently
>>    heavy to qualify.)
>>
>> We would have to figure out which operations are most
>> worthwhile doing via the web, balancing the size of data
>> transfer involved versus the complexity of the code in
>> libsbml that would be saved from reimplementation.  I also
>> have ideas for how to provide a high-availability facility
>> for the web service, so that people wouldn't all have to hit
>> a single server sitting under my desk at Caltech :-).
>>
>> This seems like a workable compromise, no?
>>
>>
> Yes, having the SBML objects as pure java objects, manipulate  the
> objects and the functionalities to read and write SBML files with a
> small jar would be perfect.
>
>> Can people try to think about the weaknesses and shot holes
>> into this scheme?  Likewise, if there are some additional
>> clever hacks we could do, please mention them.  If we're
>> going to write a grant proposal to get more developers to do
>> this, we'd better know about possible counter-arguments now.
>>
> An obvious weakness is having to pass big SBML files trough the network
> that is why, it would be important I think,
> to have a web-service that can be installed locally and/or the
> possibility to call an equivalent interface using native call.
>
> Nico
>
>> Footnotes:
>> [+] Frank Bergmann already provides a web service system
>> exposing much of the libSBML API.  The web service proposed
>> here would admittedly replicate a significant chunk of that.
>> However, it would do it in different ways, so it would not
>> be an identical system.
>>
>>
>
> ____________________________________________________________
> To manage your libsbml-development list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/libsbml-development
>
> For a web interface to the libsbml-development mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the libsbml-development list,
> contact sbml-team@caltech.edu
>
>



--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu