Aug
5
Ten years of "the desktop is dead, web-apps are the only way" makes a great corporate religion. If you're a true believer in this religion, read no further - I'm a non-believer. Requiring a web app should never mean I don't want a desktop - even more.
I want web apps and mobile web apps, sure. But I want the default as a desktop app that can shuffle as much of the computing to the local CPU as is reasonable.
And of course, I want to write the app one time. The platform should be super powerful and fully developed by others. It should update automagically, have superb installers, and a phenomenal list of features, yada yada. An impossible dream.
Oh, and I want full OSGi modularity. No developer should have to see another developer's code, nor share it in the same classpath loader, unless of course it's the same module. APIs, sure. But "Just Say No" to tightly coupled code modules.
Enter: Two mature players that come very close.
- NetBeans, with it's NetBeans Platform and JFx, which allows me to redeploy my key swing components to JFx as a web app.
- Eclipse RCP, with it's RAP for "single sourcing" an app to both desktop and as a web app.
Deciding Factors
There are logical issues, and emotional issues.
EMOTIONAL BIASES.
- I like Swing at the programming and component level. Feels better, snappier, the docs are more widespread, etc. This is strictly personal, of course, not claiming it's really better.
- I like the maturity of the Eclipse platform. I trust it. It feels right. Stuff sticks around and consistent for years, and it's widespread enough to know that it gets plenty of support.
- I'd much rather program in the NetBeans platform than the Eclipse platform. That's platform, not IDE. Either IDE can work with either's code. Have you seen the latest NetBeans Platform tutorials? I've been working with the Eclipse Platform on and off for years and it's always somewhat crusty to me. I can get it to work though.
- I like the simplicity of a JNLP WebStart to Eclipse's horrendous update process, which is only getting worse lately.
- I really really like the NetBeans guys, as humans. They are a fun bunch. I'd like to work with them. Eclipse guys I've been exposed to for years, and there is enough fratricide between players and projects to make it not always fun.
LOGICAL ISSUES
- OSGi vs NetBeans Modules. Standard vs home-grown. Uhhh. I don't think so.
- Larry Ellison. Do I trust him not to cut the cord on NetBeans? No - the simple answer. Of course, no one really knows, probably not even Larry, but Larry is not the dumbest guy in the world. Larry makes business decisions, and funding Netbeans might not be a good business decision two years down the road.
- Who has the momentum of the marketplace behind them? 100s of A-List players, all using, contributing, and depending on the platform? Eclipse the platform. NetBeans has momentum too, but to a vastly lesser degree..
- Swing components are usable whole in JFx.
- E4, RAP, and single-sourcing in Eclipse
There are actually many more issues. But these are enough to mark a clear line.
Netbeans, for Most Shops.
Netbeans is the clear winner for most shops, given the risk/reward profile that each unique shop has. The Netbeans Platform is a low risk, high reward combination for the typical corporate software shop.
Same for me, if I make the decision purely based on feelings, not logic -NetBeans all the way. Decision made.
Weight
Why is my decision different than most? It is my product, my shop, and all my risk. This risk profile is somewhat unique - small shop, long time horizon, and a focused skill set. If I don't make the best long term decision, it could cost me a lot, and for a long time. It's not like a job, where the client is a corporation, decisions are political, and I'm just trying to get invoices paid without pissing off that same guy who approves those invoices. "Oh, you like Flex? Wow! Me too then. Let's do it!".
With this decision, I go retail on a line of software that I have to support for years - and that's me personally. The risk factors outweigh rewards, in this configuration.
Final Factors In The Decision
OSGi vs Netbeans Modules was a big factor, and the knowledge of Larry Ellison's decision making capabilities was too, especially in view of the fact that so many features I need are still in the vaporware stage, in both camps.
The deal maker for me though was Eclipse RAP, E4, and the lure of single-sourcing. A promise that I really can write one set of modules and it works everywhere - web, desktop, mobile?
That, and the momentum of Eclipse, with the Eclipse Foundation behind it, and the quadzillion corporate minions like me that depend on keeping the big machine going.
DECISION: I'm going with Eclipse RCP RAP.
I already feel a tinge of sorrow. Maybe I can still do the occasional swing component inside it? I dunno. Mostly, I'm just sad to not be able to work with the NetBeans team. But you gotta do what you gotta do. Eclipse RCP and RAP, here I come.
Wish me luck, please! I'm sure I'll need it.

NB 6.9 supports osgi
I spent a few hours studying and monkeying with 6.9 OSGi support and here is what I concluded - correctly or incorrectly:
Nothing would delight me more than to be proved wrong on my bet, and Netbeans becomes based on OSGi standards.
What does OSGi as a standard give you, for your modules in a RCP? There's no portability to another container (since, to do anything useful, you have to use eclipse extensions to OSGi). It's always felt to me like more of a marketing checkbox that NB got tired of getting hit over the head with, so they finally said "fine, we support OSGi".
As for RAP, I'll believe it when I'm running real RAP apps on my android phone. It's the same promise java-fx is making, and I'm skeptical of both of them.
Rich:
What does OSGi as a standard give you? Modularity is way too big a topic for me to comment here, but there is so much on the web about modularity that it's probably not necessary to duplicate it in this forum.
For me as a business entity, it's the ability to isolate work in specific modules and only give out that work to a specific developer, but that's a different use case than for most.
As to RAP I'll agree with you all the way. It's a bet, either way. Look how long it took Sun to come up with Java 6 update 10 which cured most of the ills that applets encountered - over a decade, right?
My point wasn't that modularity isn't useful. It was that the OSGi standard doesn't bring any advantages to you that you don't have with the netbeans module system. They're functionally equivalent, but OSGi is a de facto standard. However, that doesn't mean anything at the end of the day. You can't deploy your eclipse modules to any other OSGi container to do anything useful. A standard implemented by only one RCP is no standard at all.
Yeah, but you don't need OSGi for modularity. The NetBeans module system does the same thing and is perfectly fine. So, the only thing you gain from OSGi is the fact that it is a (de facto) standard. And that brings you back to Rich's question: what does it really give you over the NetBeans module system? There's no portability to another container (since, to do anything useful, you have to use eclipse extensions to OSGi). It's always felt to me like more of a marketing checkbox that NB got tired of getting hit over the head with, so they finally said "fine, we support OSGi".
Personally, I'm way more committed to OSGi than to either the Netbeans Platform or the Eclipse Platform.
My original plan was to do neither platform, and go straight OSGi. I would still do this if necessary, though I cannot claim that it is a logical decision. Being able to do OSGi and Netbeans Platform or Eclipse Platform is just a boost.
The Netbeans guys seem to have done a simpler job of integrating modularity than the Eclipse guys, but I would still have to have OSGi.
I'm just curious, but why?
Why the commitment to OSGi? As stated above, that's too big a question for a comments section. After being in software for a couple decades, BigBallOfMud is the predominant anti-pattern, and OSGi is one of several necessary antidotes.
I've seen so many software projects fail when they pass a critical mass stage. This is my stake in the ground that says it doesn't have to happen in my shop, even if I see it happen all around me.
Nothing says that it will succeed any better than the many corporate projects that make up my idea of the anti-pattern. But I gotta start somewhere.
In other words, OSGi seems necessary, if not sufficient, to challenge the anti-pattern of BigBallOfMud.
Again, you're not really understanding my question. I agree that usage of a module system addresses the BigBallOfMud anti-pattern. However, there are several module systems, including the netbeans module system, which address this. What makes OSGi, specifically, an absolute requirement for you, as opposed to NBM? There's no real functional difference between them.
They both isolate modules into their own classpaths. They both provide ways of registering inter-module communication points (actually, OSGi doesn't, but the eclipse extension points do).
Yes, OSGi is a "standard". But the only RCP to implement it is eclipse! You could just as easily say that NBM is the "standard" for swing-based RCPs!
You've made the statement that OSGi is necessary, but your reasoning is all about modularity being necessary. Something doesn't fit here in your logic.
Rich
Ah, now I understand your question.
My application is almost devoid of UI, the critical parts are computational and on the model side. For that, all of the other OSGi offerings such as but not limited to the spring OSGi frameworks - these are where I look to the value add, and there is actually a lot of work going on in this area which I enjoy using for many reasons.
I have seen virtually no major players supporting Netbeans Modules other than Netbeans itself, whereas almost the entire Java ecosystem is moving [slowly] to OSGi. So it's a "reading the tea leaves" kind of thing. I myself rarely use the best technology over the most standard technology, just a personal thing.
Hope that at least answers your question, even if it doesn't make sense from your perspective.
"I have seen virtually no major players supporting Netbeans Modules other than Netbeans itself..."
http://platform.netbeans.org/screenshots.html
Some pretty big players in that list, including the top 5 military/defence organizations in the world (e.g., Northrop and Boeing).
Once again my choice of words is not so good.
What I should have said is that I have seen no major tool vendors supporting Netbeans modules other than Netbeans itself. I also include in that group app servers that use OSGi under the covers (Glassfish, JBoss, JOnAS, WebLogic, WebSphere ...)
I'm not saying Netbeans Modules are not better, indeed they seem well designed. Rather, it's silly for me to swim against the stream when the entire rest of the industry seems to be moving (slowly) towards OSGi.
One could say the same about swing vs swt, and that will likely have a lot more impact on your actual work with the rcp.
Look at it this way. You're much more likely to wind up saying "there's this swing library i'd like to use. darn, I wish I was using swing" than "darn, I wish I was using osgi"
Don't even get me started on how much I wish I could use swing libraries easily within RCP. It is still possible but it is fraught with challenges. I'm sick about this loss, but again, most of my work is on the model side, not the UI side, so I'll just take my losses. (and weep).
You can use OSGi in NetBeans RCP...
On the other hand, does it really matter to you that NetBeans RCP enables you to use OSGi? Had you started this series of blogs knowing that it would end the way that it did regardless of the feedback you would be receiving to your blog entries?
Ouch! "Had you started this series of blogs knowing that it would end the way that it did regardless of the feedback you would be receiving to your blog entries?"
I had finished the entire series before I received much of any feedback, but my motive in doing the series was to show my thought processes, regardless of outcome. I'm also especially interested in spreading the word about a great Netbeans Platform despite my own unwillingness to commit to it given my very peculiar circumstances.
As I stated above "Netbeans is the clear winner for most shops". In my situation it's a confluence of many factors, probably fear of Larry Ellison and his management team being the largest one - that tilted me away from Netbeans despite it's clear advantages. I am microscopic shop, my sensitivity to platform longevity is much greater than most shops.
You are right that Netbeans supports OSGi. The support is not as mature as I would like yet, but I expect that to come.
"The support is not as mature as I would like yet, but I expect that to come."
What does that mean? What is missing, what would you like the NetBeans Platform to do in terms of OSGi that it currently doesn't already do?
"it's a confluence of many factors, probably fear of Larry Ellison and his management team being the largest one - that tilted me away from Netbeans despite it's clear advantages."
Even though Oracle's own customers use the NetBeans RCP as the basis of their applications and even though Ted Farrell, VP of tools has publicly stated: "The NetBeans Platform is very important to a lot of our customers, who are actually building their products on top of the NetBeans Platform. We want to make that the best platform that we can for doing that for you."
So, you're suggesting, despite all of that, that Oracle will dump the NetBeans RCP, even though its customers are creating their applications on top of it and even though they have publicly stated that they support the NetBeans RCP going forward?
Larry Ellison scares the holy heck out of me.
I do not suspect any specific action on his part. It is fear of the unknown that gets me. This may not be rational on my part, but that's the best explanation I can come up with. Please do not hold me to a standard of making sense on this issue, I would not be able to live up to that standard.
Since you are anonymous I can only guess as to your own position, but I sense by your posts that I've probably done a terrible job of supporting the message that I intended, which is that Netbeans deserves all the usage it can get, despite my own weird choices. That is regrettable - for me for me to fail in this attempt.
Post new comment