ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | oscar List | March 2006 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [oscar] Disadvantages

Hi David,

I don't know about other people, but as a developer I do indeed consider
the portability of OSGi bundles to be valuable.  Doing OSGi development,
one becomes a bit spoiled by the ability to develop & test a bundle on the
host, then drop the same JAR on a target (different CPU/OS/JVM, perhaps
even a different OSGi implementation) and have it "just work."

As for protection against decompilation: have you considered reimplementing
the sensitive parts of your bundles as native shared libraries embedded in
the bundles and called via JNI? OSGi makes this pretty straightforward.

Jim Kortge

|         |           David Lindelöf   |
|         |           <david.lindelof@a|
|         |           dhoco.com>       |
|         |                            |
|         |           03/14/2006 01:50 |
|         |           PM               |
|         |                            |
  |       To:       eelco.kurvers@xxxxxxxxx                                   
  |       cc:       oscar@xxxxxxxxxxxxx                                       
  |       Subject:  Re: [oscar] Disadvantages                                 

Hello Eelco,

On Tue, 2006-03-14 at 09:59 +0100, eelco.kurvers@xxxxxxxxx wrote:
> My question to the more frequent users is, what do you consider to be
> the current disadvantages of the OSGi Framework?

>From my own point of view, the single biggest disadvantage of the OSGi
Framework is that runs on Java.

No, I'm not another zealot who will compare Java with C++ or Smalltalk.
I won't bore you to death with benchmarking studies that pretend to
prove something or another. I won't rant about the absence of multiple
inheritance in Java. There's a very real, down-to-earth reason why I
think Java is a bad platform. It's about intellectual property.

I develop a product with a substantial amount of pseudo-AI in it, and we
have finally woken up to the fact that Java bytecode is relatively easy
to decompile. And it is very difficult to prevent file access from
someone who has hardware access. We simply cannot afford the risk of our
unprotected compiled Java classes falling into the hands of the
competition, a risk we would not have with natively compiled code.

Java was marketed on the basis of its portability, but nowhere have I
seen this portability as being an advantage within the OSGi community.
And it is precisely this portability that makes bytecodes so easy to
decompile. So with Java, we have sacrificed "un-decompilability" (and
some performance) for portability, which we never needed in the first

> As posted before I'm currently doing some research on the OSGi
> framework. I've read a lot of documents and soon I will receive some
> books about the subject.

This mailing-list has expressed much interest in an OSGi "reading list".
Would you like to share the titles of the books you have been able to

David Lindelöf
Product Developer
Adhoco AG
Jagerstrasse 2
8406 Winterhur
tel +41-52-203.2903
mob +41-79-415.6641
fax +41-52-203.2904
e-mail david.lindelof@xxxxxxxxxx
url http://www.adhoco.com
weblog http://visnet.ch/~lindelof/smartbuildings/

Home on the Range was originally written in beef-flat.

You receive this message as a subscriber of the oscar@xxxxxxxxxxxxx mailing
To unsubscribe: mailto:oscar-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.