[Biojava-l] Java Resource Management [a semi troll...]

[Schreiber, Mark]

Hi Ewan,

I've never really noticed a problem with settling on a JVM in terms of
bugs. The only problem with settling on a particular JVM for us has been
wishing we could use that really cool feature from the latest release.
We have done various upgrades of JVMs and they seem to be realtively
painless. For production I usually keep a little bit behind the JVM wave
to let them clean up bugs. EG when JDK 1.5 comes out I'll probably wait
for JDK1.5.1 or later. The JDKs always aim to be backward compatable
though buggy parts get deprecated which technically means they may not
be supported in future releases. I'm not aware of anything that has
actually been removed after being deprecated.

As you know biojava is a bit less stable although it has become much
more stable. I actually use biojava-live for some production stuff now
which would have been insane a year ago. Our goal is to make BJ1.3
stable and from then on maintain backwards compatability.

Resource management is a thorny issue. I've never noticed too many
problems but I'm not assembling the human genome. Speed is really not
the issue people think it is. Modern JVMs use JIT compilers that detect
intensive loops and compile and execute that loop natively. This means
that some of the slow parts of your code execute as if you where using
JNI. Because of this it is reccommended that you don't try and optimise
a Java program without using a profiler. Often the parts you expect to
be slow may be quicker than you think.

The biggest hit on performance is bad programming. A well written java
program will execute faster than a poorly written C program. This is
where it pays to have some computer scientists on hand who know the
optimal algorithms for your task.

The other traditional argument for Java over C or C++ is that
development time is generally reduced due to Java not letting you do
some of the stupid mistakes you can make in C. The economic argument
goes that machine time is cheaper than developer time. If you can write
a less buggy program more quickly that is a little bit slower then
you've spent less money.

Portability of C programs can be tricky but that's probably not an issue
for you people.

- Mark


> -----Original Message-----
> From: Ewan Birney [mailto:birney at ebi.ac.uk] 
> Sent: Monday, 10 February 2003 10:24 a.m.
> To: 'biojava-l at biojava.org'
> Subject: [Biojava-l] Java Resource Management [a semi troll...]
> 
> 
> 
> 
> I know... this is a troll.... but it sort of resonates with 
> me about the way Java development works - people have to fix 
> on a JVM version to get real like-a-rock stability and work 
> about bugs in that release, and 
> Java is just dreadful in resource management (in particular memory
> footprint) meaning you have to give it really beefy machines 
> to run on.
> 
> 
> 
http://www.internalmemos.com/memos/memodetails.php?memo_id=1321


This is why I think i have alot of reluctance to move to Java; C is by
far my prefered strongly-typed, "non-scripting" language. But I am a
dinosaur...


For guys who do run Java as part of their production code in
bioinformatics, 

(a) do you have versioning problems over time?

(b) are there resource problems or not?


If so, how do you deal with these?







-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney at ebi.ac.uk>. 
-----------------------------------------------------------------

_______________________________________________
Biojava-l mailing list  -  Biojava-l at biojava.org
http://biojava.org/mailman/listinfo/biojava-l
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================