Chris has posted 8 posts at DZone. View Full User Profile

Gosling, OSGi, Jigsaw and Shenanigans

06.22.2009
| 12003 views |
  • submit to reddit

I read an article where James Gosling comments on OSGi and Jigsaw, here’s what I found:

James Gosling and OSGi

According to James, OSGi is:

  • from a different universe
  • kind of huge
  • doesn’t play well in the smaller spaces

So… I’m sorry, all due respect to James but I’m going to have to call shenanigans on this one.

Why? Well, let’s go through his three points.

First, Gosling claims that OSGi is from a different universe. I’m not sure which universe he’s referring to, but OSGi has been around since 1999 (in fact, the OSGi Alliance was founded in March 1999). OSGi initially targeted things like set top boxes, mobile, automotive and the home automation market. If you look at the OSGi membership, you see the diversity of companies involved. About 5 years ago, OSGi moved into the desktop application space via Eclipse and the Rich Client Platform (RCP). Now you see companies building applications on top of OSGi. Here are some examples:

A couple years ago, OSGi started to move into the server and enterprise space. Now, I can’t find any major application server that doesn’t use OSGi under the covers. From IBM’s Websphere, GlassFish to SpringSource’s dmServer.

So on the contrary James, I believe OSGi is well entrenched in the universe we live in. In fact, OSGi has continued to evolve since its inception, the specification didn’t come out of nowhere.

Second, James claims that OSGi is kind of huge. I’m not sure what he means by this, there are various flavors of OSGi that come in different sizes based on your needs:

I wouldn’t call any of these implementations huge. If OSGi was huge, you wouldn’t see companies like BugLabs power their BUG device to enable modularity for building cool little devices:

BUG

Finally, James claims that OSGi doesn’t play well in the smaller space. Well, as we saw with the BUG example above, that’s obviously not true. If you look at the history of OSGi, James’ statement is ludicrous as OSGi’s initial mission focused on the mobile and embedded space. Nokia and Sprint have shipped phones running OSGi technology. There are even companies like Band XI running Equinox OSGi-based applications on embedded devices like the Catalyst EC:

EC Catalyst

Heck, you can even plug a device into your wall socket that runs OSGi.

I can go on and on… so what’s my point?

If James wants to talk about OSGi, he should learn more about it first, otherwise he perpetuates misconceptions that help no one. I think we all agree that modularity is a good thing for the software industry and we should be working together to push that concept forward.

On a side note, James, if you want to learn more about OSGi and its history, I would gladly set some time aside to chat. I’m sure people like Peter Kriens and BJ Hargrave would do the same. You’re also welcome to attend a free OSGi mini-course that Jeff McAffer and I are giving on Equinox and OSGi in a couple of weeks.

From http://aniszczyk.org/

Published at DZone with permission of its author, Chris Aniszczyk.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bob Smith replied on Mon, 2009/06/22 - 9:08am

I really don't understand why there have been two pro-OSGi blogs in JavaLobby in less than a week.    I smell a pro-Eclipse anti-Sun bias.  It all comes down to the same flawed arguments in favour of Eclipse vs. Netbeans (it's the standard, Netbeans will fragment the market, Eclipse was first, etc, etc).

First of all, OSGi may have multiple deployments, but they're all based on the Eclipse ecosystem.  Sure, Glassfish uses it, but that's as far as the ecosystem goes.  OSGi is widely used mainly because something like the Java module system doesn't already exist.

Second of all, OSGi is not integrated into the Java language.  It's essentially a hack based on working around the limitations of the jar format by hard-coding text into each jar's MANIFEST.MF file.   There's no static typing (compile-time verification).   It relies solely on convention.

The new Java module system, on the other hand, will be built directly into the JVM.   jars will be more intelligent.  Packages will be more intelligent.  It will be possible for third party packaging systems such as Linux package managers to integrate with it (Does any Linux distro use OSGi?  Is it techincally possible for them to?).  It will aid in making Java smaller and more modular and improving performance. 

So, from an architectural standpoint, the new Java module system, assuming all the kinks and implementation details are worked out, will be more sound and reliable than OSGi.

Besides, I trust Sun's engineers far more than I trust IBM's (yes, I know that Eclipse is supposedly independent of IBM, but that company still exerts tremendous influence).

Johan Compagner replied on Mon, 2009/06/22 - 10:21am in response to: Bob Smith

isnt this a bit unfair to say that the Java Module System can be way more reliable and sound then OSGi...

Yeah if i can just alter the jvm itself, i could also do way more cool things.. OSGi had to work with what they have and get..

"Jars/Packages will be more intelligent" where will that be stored? How can a jar that is a container format be more intelligent? Ofcourse it can be wait. just store something in your meta data file... 

I dont know if trust Suns/Oracle engineers more the IBM. It will not be the first time that sun does come up with something eventually that is already long there and working perfectly as an open source project (for example logging. Sun should just look at what is now working on the market, and work with those to come up with a perfact combined solution.Do not reinvent the wheel again and again (thats what sun really is in my eyes, the list is so huge, asp -> jsp, ASP.NET -> JSF, Flash -> JavaFX, and this list can go on and on) 

Sebastian Mueller replied on Mon, 2009/06/22 - 11:26am

So just because there are OSGI implementations that can run on a netbook-sized device you say that OSGI is not huge? Linux and even Windows is running on these kind of devices, so they are not huge either, eh?!

I don't think by 'huge' James meant the size of the processor OSGI can be run on.

1.1MB of Equinox code is HUGE, compared to what it actually *does*. Compare that to the size of the Java runtime and its components (the initial swingall.jar (javax.swing.* and all look and feel implementations) was less than 2MB!)

If Jigsaw will increase the size of the JDK download by one MB I would say it failed. Because AFAIK that was one of the goals of project Jigsaw.

But apart from the actual byte size, maybe James also meant the conceptual size; the concepts, the spec and the API.

Re: From another universe. You are writing that OSGI was invented in 1999 and five years ago it came to the desktop. If my maths are correct this results in 5 years living in the non-desktop area. So I think one *can* agree that OSGI comes from another (the non-desktop) universe.

You could have written something useful by actually comparing the two technologies, instead.

Khurram Shakir replied on Mon, 2009/06/22 - 11:38am in response to: Johan Compagner

I am surprised, you are accusing SUN to come up something which compete on ASP and ASP.NET, what should SUN do, instead making a runtime for ASP and ASP.NET in java :)

Bob Smith replied on Mon, 2009/06/22 - 12:07pm

@Johan Compagner

 There are some factual errors in your post, namely:

1) JavaFX is not a feature-for-feature copy of Flash.  It's much more.  It integrates seamlessly into the JVM/Java server-side code, which Flash does not.  It has a mobile component and common APIs (not Flash-lite), which Flash does not.   It has full access to the Java API on the client side, which Flash does not.  I could go on.

2) The point of my post was not to criticise OSGi for "working with what they had".  For all the hacks that went into it, OSGi accomplished a lot.  The point is that the Java Module System is a better technology because it doesn't need those hacks and promises to do much more than OSGi, including integrating into Linux distro package systems and doing compile-time checking.

3) "Where will the information be stored?"  Well, in compiled Java binaries which are far more compact and statically-checked.  DUH!  That's the whole point.  There won't be any need for a fat text file to be checked only at runtime.

4) If "reinventing the wheel" is a crime, then let's do away with the following technologies:

A) Mac OS X and Linux, since both "reinvent" Windows' desktop operating system.

B) Firefox/Safari/Chrome.  IE was already available.

C) PC clones.  The IBM PC was already available.

D) The World Wide Web.  Protocols like Gopher and ARCHIE were already available.

I could go on.   Maybe Sun didn't always improve upon existing technologies, but at least they tried.  By your reasoning, they should have never started TestNG since Junit was good enough, right?

Alex(JAlexoid) ... replied on Mon, 2009/06/22 - 12:20pm

@ChrisAniszczyk:

 While writing your reaction to Goesling's words , you shot yourself in the foot.

You are saying that it's not from a different universe. while giving examples of how OSGi is from different univerese, as opposed to Java and JVM.

And as someone said, it's fat because it's a hack over existing system. Nothing more, nothing less.

Oleg Zhurakousky replied on Mon, 2009/06/22 - 12:43pm

@WordWarrior

Saying that all OSGi deployments are "based on the Eclipse ecosystem" is not true. There are several popular non-eclipse (non-Equinox) based implementations of OSGi (e.g., Knophlerfish, Felix etc. . .)

"Second of all, OSGi is not integrated into the Java language" - true. In fact, there are many frameworks, products and projects in the OS space that are not integrated in Java. AOP is one example. The question I like to ask is why? Why does the mind of the few (SUN) continues to put up a struggle with the world of a millions? Following your analogy, everything that is not part of JDK is a hack. IMHO I think it is a poor choice of words. It looks more like a true democracy :-) in the IT community where one can refuse to follow SUN's dictatorship and look ahead by following and using frameworks that define conventions that are more useful, powerful and therefore more productive and popular then anything fake-JCP process has produced in the past.

"The new Java module system, on the other hand, will be built directly into the JVM" - looking at the history of innovation from SUN, by the time it is built it will already be outdated.

"It will aid in making Java smaller and more modular and improving performance" - right. . . it's already been done by OSGi.

"Besides, I trust Sun's engineers far more than I trust IBM's" - the same engineers that insist on making today's Java backward compatible with Java 1? The same engineers that keep all deprecated artifacts, making API bloated with useless classes and methods in the off chance that someone is running multibillion dollar system developed on Java 1? The same engineers that created JDBC API and checked exceptions? In fact although I do represent OS community I trust IBM more then SUN for several reasons. First, their constant contribution to OS. Second, in the past 10 years there is much more innovation that came out of IBM (although proprietary and closed source), then from SUN.

And btw, its Oracle engineers now, so some of these guys are actually pretty good and coincidentally major contributors to OSGi. . . so may be we'll finally see some innovation after all.

Bob Smith replied on Mon, 2009/06/22 - 1:27pm

@Oleg

Fine, but OSGi is most commonly associated with Eclipse, with some exceptions.

I have no problem with frameworks that don't hack around the JVM so brazenly.  Examples are ant, junit, log4j Spring, GWT, among others.  All these frameworks play well with the static typing of Java, and don't hack Java by innondating their frameworks with incomprehensible configuration files.  What's more, they've each attempted to either develop or allow the development of open and usable tooling or allow easy development of unit testing.   Any framework that attempts to alter Java to either intentially or unintentionally take on the characteristics of a dynamic language with runtime checking, in my opinion, fails this test.  Another example I can think of that fails this test is Struts, which overkills configuration with multiple .properties and .xml files with not even a cursory attempt at compile-time checking, tooling, or even permit testing of components via unit testing (and, yes, I'd probably include JSF as well, but I confess not to have worked with it enough to form an opinion).   OSGi fails because it's a hack with loose tooling and runtime checking.   A good framework leverages the strengths of the JVM and doesn't work against it.

If Sun is so dictatorial, then why have these third party tools flourished?

When I look at Sun's history with Java, I see them developing a framework that is arguably *the* enterprise solution.  I see an IDE that is arguably the best free IDE on the market.  I see what is arguably the best free application server (Glassfish).  I see a solid set of APIs that have saved developers untold years in developing enterprise applications.   JPA 2.0 will extend the concept of static typing to database access. With JavaFX, I see a company that has learned from its mistakes and decided to discard the legacy baggage of Swing and AWT to "put right what once went wrong".  What's more, I see efficiency and solid design.  Granted, Sun can be overly prudent with some of their decisions.  However, the fact that the ecosystem that created ant, junit, Spring, etc is proof that Sun did a lot that was right where others went horribly wrong.

As for being outdated, perhaps you can explain to me how Glassfish, Netbeans, and JavaFX are "outdated".

How is OSGi small and efficient?  It's based on large text files interpreted at runtime. 

Java *has* to be backwards compatible for the same reason Windows does.  Sun is not a charity.  It's a business that has customers.  Those customers have requirements.  Any sane business doesn't tell its customers to go screw themselves, as you seem to be happy to tell Sun to do.  Why do you think Sun invented the Java Module System and JavaFX?   They want to make all those old APIs optional modules and deprecate Swing and AWT, respectively.   The JDBC is based on solid object oriented design principles, and it's extensible enough to allow frameworks to be built around it.   Was there anything remotely better in the early 1990's?   What the hell is wrong with checked exceptions?   How the hell am I supposed to communicate conditions beyond the client's control such as IO/networking/database/etc problems that they need to take into account?    IBM only contributes to open source when it's in their best interest.  How crippled and useless was base Eclipse before it had to compete with Netbeans?  Remember when you had to pay for MyEclipse to get any JEE functionality?   When was the last time IBM innovated?   Almost all software they sell (Rational, Lotus Notes, etc) was acquired, even the IBM JDK came from another company.

Liam Knox replied on Mon, 2009/06/22 - 5:49pm

I can understand what OSGi is addressing but have seen about zero usage in my area. I think the reasons for this are 2 fold. 1. What it is addressing is still predominantly only of use on vms hosting multiple services, people seem to think Java == Web in too many articles. 2. It is still pretty complex to use and get upto speed with. It is also very big as a technology and not just a module system

If the Java module system brings more simplicity to the table as well addressing concerns that modularization should be done through out the entire stack I am all for it. I would thank OSGi for bootstrapping this innitiative from Sun.

Lukas Krecan replied on Tue, 2009/06/23 - 2:05am

The trouble with all the Jigsaw thing consist of two parts. First of all, it's quite important language change. It's not just a library change that you can ignore, it's real language change, so you would have to use it. Secondly, Sun engineers pretend that they know it all, that they don't need to cooperate with anyone, that they are able to create a module system that was never done before, (it can handle both compile and runtime dependencies at once). Moreover, the communication is quite bad. You can read Mark Reinhold's blog that has not been updated for 6 months. So it's not surprising that people are afraid. At least I am. Btw. if you want to read about my fears, you can read my article on InfoQ.

Mladen Girazovski replied on Tue, 2009/06/23 - 3:55am

One reason why Java is so popular is that is has a huge community that drives the development of it, it's not Sun that drives Java.

Just think of all the opensource libs/APIs/frameworks that are used in your daily work, they are all not part of the language and all of them were not planned by Sun.

In fact, i'm afraid that we have to live with again a suboptimal solution from Sun instead of the preferable (if it wasn't for political reasons) implementations that are already availablein the opensource segment.

That already happened with java.util.logging, log4j is superior, but Sun insisted on it's own implementation, and today we have a real (and ridiculous) "logging scene", with almost religous fights over what logging to use and way to many options with all possible problems.

Bob Smith replied on Tue, 2009/06/23 - 8:11am

Have any of you seen the slides for the Java module system?  The framework is easy to understand, implement, and is quite clean.

I have no problem with Sun coming up with competing implementations of open source ideas.  Hibernate was the first open source ORM to gain traction.  Instead of accepting Hibernate as the "open source ORM standard", they implemented JPA.  Now that Gavin King has moved onto Seam and Hibernate is stagnating (still stable and reliable, just nothing new being added to it), it's a good thing that Sun did.  JPA 2.0 is potentially better than Hibernate, since it introduces static type checking to database operations.   If such initiatives mean I have to choose among 2 or 3 different logging frameworks, all the better!   Choice is good.

As for all the open source libraries build around Java, this doesn't reflect negatively on Sun.   It means that Sun engineers built a solid base upon which open source frameworks can build.    Despite all the R&D and IT companies out there, there are only two programming runtimes that are widely deployed by the enterprise, one of which is Java.   That's not an accident, and people don't realize what a feat of engineering the JVM is.

Tom Wheeler replied on Tue, 2009/06/23 - 1:27pm

Just so we better understand the source, is the original poster the same person who is an evangelist for EclipseSource?

If so, I'm certainly not implying that you can't make good arguments in favor of OSGi, just that I think readers would benefit from knowing that there might be motivation beyond simply making sure that Jigsaw provides the best possible solution to Java modularity.

BTW, it's really a deficiency of JavaLobby that the "full user profile" is so weak -- I typed in a couple of paragraphs about myself but they're simply not shown in the UI.  Perhaps you did the same and it's likewise just not evident to readers.

And in the interest of full disclosure, I am an active NetBeans Platform developer. Consequently I've always wondered why NetBeans' own module system (which is excellent though not a de facto standard like OSGi) wasn't considered as the basis for Jigsaw.

Chris Aniszczyk replied on Tue, 2009/06/23 - 4:07pm in response to: Tom Wheeler

My goal was to simply point out all the misconceptions in Gosling's interview. When a lot of people talk about OSGi, they don't realize the history and the development that has gone into the specification. Oh, I've been working with OSGi long before it become popular... in the dungeons of IBM labs ;) Tom, I co-lead the Plug-in Development Environment (PDE) at Eclipse. PDE is where all the OSGi tooling is done at Eclipse. I currently work for EclipseSource. If you recall history, Eclipse had its own "modular" system before OSGi about 5 years ago. We reviewed the state of the art at the time and decided to go with OSGi because it worked for us.

Chris Aniszczyk replied on Tue, 2009/06/23 - 4:11pm in response to: Bob Smith

"Have any of you seen the slides for the Java module system? The framework is easy to understand, implement, and is quite clean." How can you claim stuff like this when it's not even out... not really used by anyone. The framework isn't even in good enough shape to be analyzed by the general public. The module layer in Jigsaw is already bigger than the OSGi core API... in OSGi... there's only 27 classes... OSGi has been around for many years, gone through many iterations to get a lot of things right. Building a module system is hard and impossible to get right in the beginning. Even with OSGi, we aren't there yet, but we continue to evolve based on people's needs.

Johan Compagner replied on Tue, 2009/06/23 - 4:12pm in response to: Bob Smith

I dont care what JavaFX can do more then flash. Communicate with java on the client which flash cant? Why should flash want to do that? It has its own runtime. i find that a very bad example But thats not the point i made. I just say that Sun is so many times playing catch up. Always trying to do something that just WAS hot.. Common there latest thing... Java App Store. What the hack???? Because apple has a store and nokia also creates one (and all the mobile os's do follow) Sun has to make a Java App Store, who does come up with that? its ridicules .. So the information is compiled into java binaries/classes? Huh? But wait it was given a an example that linux couldnt use the packages system of osgi.. But thats just a simple text file inside a jar. But now it is compiled into. something so you really have to know or read binary stuff? By the way, you do know why eclipse does everything in plugin.xml and now in the manifest.mf file right? Because first they had much more in classes. But that didnt scale 1 bit. They had to externalize as much as possible into xml/manifest files so that the plugins classes didnt have to be hit. I am not a big fan of xml (commiter of the wicket web framework because of the xml free stuff and compile time safety of everything) but i guess if you are as big and want to scale out as big as eclipse wants to be you have to. But maybe sun makes this a bit better so that we can have both worlds. But as a said before this isnt something osgi could because they have no control of the java spec. But this by far doesnt mean that sun should just discard osgi.. that would be soo stupid. Work together, there are loads of very experienced guys on both ends and already a working system. Now improve that by introducing changes into the java vm together!

Tom Wheeler replied on Tue, 2009/06/23 - 7:32pm

Yes, I do recall Eclipse's previous module system as I predominantly used Eclipse IDE back then. 

Of course the direction may have changed since December, but Mark's Reinhold's blog seemed to indicate that their ultimate path was leaning in the direction of OSGi and that Jigsaw was a tactical measure in the meantime.  I don't know whether they've followed through with their plans to "work directly with the OSGi Alliance" nor whether that will change with the Oracle acquisition.

Mark Thornton replied on Wed, 2009/06/24 - 9:33am

"I believe OSGi is well entrenched in the universe we live in"

 In the desktop sector, Eclipse appears to be the only example anyone has heard of. So as most of my work is in desktop applications and I don't use Eclipse, I have not yet seen OSGI in action at all. From a desktop point of view OSGI has a lot of spadework to do before "entrenched" could be considered an apt description.

Bob Smith replied on Thu, 2009/06/25 - 8:56am

@Chris

-----

"Have any of you seen the slides for the Java module system? The framework is easy to understand, implement, and is quite clean." How can you claim stuff like this when it's not even out.

-----

You obviously haven't seen the slides:

http://openjdk.java.net/projects/jigsaw/doc/ModulesAndJavac.pdf

Take a look and let me know if it makes more sense to include modularity in binary form with compile-time checking, or in text that has to be interpreted at runtime?  Should this be managed by an add-on, or by the Java framework itself?   Should modularity be ecouraged in order to trim down the monolythic runtime to manageable layers (which, BTW, will be essential for Java and JavaFX to succeed against Flash and Silverlight).

If you can propose a way in which OSGi can be added to the language itself and can accomplish all that Jigsaw is designed to accomplish, then feel free to make your case for how this can be accomplished technically.   If you can find a way to use OSGi to cut down the Java runtime to manageable piece and make Java run faster on the client side, then I'm all ears.

If you can't, then I'll support Jigsaw over OSGi.   Until then, OSGi does not meet Sun/Oracle's objectives, and that's pretty much a fact.

 

 

Denis Robert replied on Thu, 2009/07/02 - 7:07am

WOW! the message passed fast amongst the Sun crowd! Let's all bash OSGi! OSGi is a very successful technology. Whenever Sun has attempted to put out an also-ran technology, it has pretty much failed (As one commentor pointed out, logging is one glaring example). When it's decided to work with its partners, instead of attempting to trash them, it's succeeded (JPA).

So please, Sun. Look around you: OSGi is here to stay. You can either accept that, and work with it, or shoot yourselves in the foot one more time with Jigsaw. Who did what first, or theoretical technical superiority (as opposed to actual implementations) mean *nothing* in the real world.  Jigsaw will end up being a Sun-only technology, since everyone else has already invested too much in OSGi to reverse course. So just like NetBeans, you guys will be wasting your time continuously re-inventing the wheel, and screaming at the top of your lungs: "But It's So Much Better!!!!!!!!!!!!!". 

As for size, I really have no problem with even Equinox' size. Sun's people are comparing apples and oranges, that is: a simple container model vs a container model PLUS a bunch of runtime services. It's not honest, and you look like either idiots or politicians pushing that line (I don't know which is worse). But it's certainly not professional. And if you want a pared-down implementation of OSGi that will fit on a smart-card, I'm sure someone out there will oblige. Equinox is big because it's targeted towards full-blown processors and large RAM. 

As for the IBM vs Sun thing, once again: CUT IT THE HELL OUT! We developers are really, I mean REALLY tired of that bullfunky. We want solutions, not turf wars. 

Alex(JAlexoid) ... replied on Tue, 2009/07/07 - 5:01am in response to: Denis Robert

 

As for the IBM vs Sun thing, once again: CUT IT THE HELL OUT! We developers are really, I mean REALLY tired of that bullfunky. We want solutions, not turf wars. 

We, in non Microsoft land, want options, not "one true way" solutions.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.