NetBeans & Eclipse RCP
Pär Dahlberg
for that to happend) and are thinking about using either NetBeans RCP
or Eclipse RCP. I've been using the NetBeans IDE for small
Java-projects at home every now and then for a few years and recently
I've tried some NetBeans module tutorials, but I have no experience of
Eclipse IDE/RCP. I've seen and heard talks about the difference between
these IDEs, but I have no idea of the differences when it comes to
developing an application on these RCPs.
Anyone here who might enlighten me? Would be interesting to hear if
someone got experience from development with both of these RCPs. It
would also be fun to here the posse talk about this on the podcast :)
/Pär
Werner Schuster (murphee)
> Anyone here who might enlighten me? Would be interesting to hear if
> someone got experience from development with both of these RCPs. It
> would also be fun to here the posse talk about this on the podcast :)
>
http://www.amazon.com/Eclipse-Rich-Client-Platform-Addison-Wesley/dp/0321334612/sr=8-1/qid=1161344360/ref=pd_bbs_1/002-3158870-9476030?ie=UTF8&s=books
http://www.amazon.com/Eclipse-Building-Commercial-Quality-Plug-ins-2nd/dp/032142672X/sr=8-3/qid=1161344360/ref=pd_bbs_3/002-3158870-9476030?ie=UTF8&s=books
Not to mention that there's a large community out there that has years
of experience and can give you a hand with everything.
It also has the best tools for developing plugins (an Eclipse RCP app is
just a bunch of plugins),
mostly because the whole Eclipse system is built with them - and the
developers made
sure they have the best tools around in the Eclipse PDE (shipped with
the Eclipse SDK).
If you're not convinced, see this:
http://www.eclipse.org/community/rcp.php
for a list of companies that have decided to base their apps on Eclipse
RCP (of course, this is just a partial list).
It includes companies like Adobe, etc.
And of course: Eclipse plugins give you proper modularization and
versioning _today_ because they're built on OSGi.
(If you don't know what that brings you, see this
http://www.jroller.com/page/murphee?entry=osgi_usage_increasing ).
So, you have state of the art documentation, best tool support around,
are in good company, and can use technology of the future today (OSGi
gives you things that the future JSR277 doesn't even promise yet). And
if that's not enough: Eclipse (RCP) is the base of _many_ products,
which means it'll be developed and supported simply because there's a
lot of interest in Eclipse (RCP) being a great system.
Oh: another argument for management: there are a lot of developers with
Eclipse plugin development experience out there, which should make
hiring future developers easy.
I don't know what your app will do, but there are a lot of mature
Eclipse projects that you can use in your Eclipse RCP app, like BIRT
http://www.eclipse.org/birt/phoenix/ for reporting.
murphee
--
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/
Curt Cox
look at JSR-296. It has been in the initial release any-day-now
status for about two months. The Eclipse and NetBeans platforms are
both large APIs with a relatively steep learning curves. If your
application fits its restrictions, you may want to consider a more
targeted framework like JMatter.
Please post about your experiences with any conversion tools or
libraries you use. It would be interesting to see how well they
handle real-world projects.
"Projects Semplice, OpenOffice.org & PaNaSeaM: Supporting classic VB"
http://weblogs.java.net/blog/panaseam/archive/2006/10/projects_sempli.html
Alexis Moussine-Pouchkine
NetBeans Platform and Eclipse RCP are both very capable.
-Alexis
Werner Schuster (murphee)
> It's too bad you take this opportunity to bash JSR 277.
> NetBeans Platform and Eclipse RCP are both very capable.
>
easily bundle various versions of libs and split up the program into
modules. This is good practice and very useful. Not just that: it's a
way to structure a program even outside of Eclipse RCP (OSGi != Eclipse;
there are various OSGi runtimes that you can use in your app, and they
are not restricted to GUIs, but can be any type of app you like).
Why did I mention JSR 277? Because it'll provide some of the OSGi
features I just described sometime when Java 7 comes out - ie. this
won't be usable until sometime 2009, when Java 7 adoption _might_ start.
Modularization and Versioning is something that should have been
available decades ago, and now it is with OSGi bundles, something that
comes free with Eclipse RCP usage.
Pär asked for experience with the platforms, I reported mine.
Werner Schuster (murphee)
> It's too bad you take this opportunity to bash JSR 277.
> NetBeans Platform and Eclipse RCP are both very capable.
>
easily bundle various versions of libs and split up the program into
modules. This is good practice and very useful. Not just that: it's a
way to structure a program even outside of Eclipse RCP (OSGi != Eclipse;
there are various OSGi runtimes that you can use in your app, and they
are not restricted to GUIs, but can be any type of app you like).
Why did I mention JSR 277? Because it'll provide some of the OSGi
features I just described sometime when Java 7 comes out - ie. this
won't be usable until sometime 2009, when Java 7 adoption _might_ start.
Modularization and Versioning is something that should have been
available decades ago, and now it is with OSGi bundles, something that
comes free with Eclipse RCP usage.
Pär asked for experience with the platforms, I reported mine.
murphee
Dick Wall
love to take this chance to ask a question. Putting on my software
architect and developer lead hat for a moment, one of the things that I
believe might be holding OSGi back is a description of what it does for
me - I mean specifically what pain points does it solve right now. I am
all for good design and modularisation, but to date I have not seen
anyone write an OSGi white paper specifically stating how this
technology will revolutionize my life, or even make my job easier.
At present, working with either Swing or Web Applications, I don't have
a whole lot of problems just dealing with jars and rolling releases up
with ant into either zip files or EAR files. I understand that OSGi is
pushed as a better way, but what I want to know (and I am seeking a
true answer, not troll) is what OSGi really does for this goal - dammit
people I want examples.
On the subject of eclipse and netbeans RCPs, I need to check the state
of the art in eclipse GUI building. I really like Matisse and find it a
very quick way to put together java GUIs (there was a time when I would
never have written something like Flubber in Java because the GUI would
have taken too long for such a simple tool). When using the full RCP,
the advantage of a really slick GUI builder is less, but still there. I
have been meaning to look into the latest GUI stuff from Calisto so
maybe I will have a look at this today and see if it is equivalent to
Matisse now. If not, Matisse is about the closest I have seen to
something as easy as VB GUI building for Java (in fact VB6 guys seem to
take to it like a duck to water)
Cheers
Dick
Curt Cox
The original OSGi book is still very readable and you can currently
get it for $0.16 + S&H used at Amazon.
The future of Java is probably going to be both modules and OSGi. I
think JSR-277 and JSR-291 have some common members. It wouldn't
surprise me to see both approaches converge over time. When language
and bytecode changes are made to support modules (JSR-294), will OSGi
use or ignore them?
With all that said, all three JSRs should be more open and well
formulated concerns should be publicly adressed:
"JSR 277 Review"
http://www.osgi.org/blog/2006/10/jsr-277-review.html
Tool support is going to be important. All of the IDEs could use
better OSGi support right now.
I think 2009 is pessimistic for usable Dolphin (or 1.7 if that makes
you happier) releases. The Mustang releases have been rock solid for
quite some time. Module support will probably be among the the first
things added to Dolphin, since JRE developers will want to use it and
the implementors will want to make it as well tested as possible.
Finally, everyone has said that modules won't be available for
anything before Dolphin. Until more details about JSR-277 and JSR-294
become available, I will continue to doubt that. Sun won't support
them, but they might well get backported.
mmelli...@gmail.com
Eclipse RCP? Eclipse has a lot of momentum. IBM did Lotus Notes for
Linux with it, for example. Since learning either one well will take a
lot of time, I'd think the Eclipse RCP would be the way to go, if
Netbeans was only marginally better.
-Mike
> "Projects Semplice, OpenOffice.org & PaNaSeaM: Supporting classic VB"http://weblogs.java.net/blog/panaseam/archive/2006/10/projects_sempli...
Dick Wall
http://blogs.sun.com/geertjan/entry/eclipse_platform_vs_netbeans_platform
(an interview with Kai Todter who is a Siemens guy I know who really
likes and knows the Eclipse RCP, talking about the Netbeans RCP - it's
an honest article and well worth a read to get an idea of the
differences)
Also
http://www.netbeans.org/kb/50/netbeans-plugin-dev-for-eclipse-users.html
Highlights some of the similarities and differences for implementing
plugins in the two IDEs
Hope that helps
Dick
Werner Schuster (murphee)
> architect and developer lead hat for a moment, one of the things that I
> believe might be holding OSGi back is a description of what it does for
> me - I mean specifically what pain points does it solve right now.
Does this blog entry answer the question:
http://www.jroller.com/page/murphee?entry=osgi_usage_increasing
It has an example of library dependencies that can be solved by this. If
it's not clear, please ask again.
Mind you: this isn't something that'll help you with something the size
of Flubber, which probably won't contain tons of code and libraries.
It's also not something for Servlets or EJBs, which come with their own
package systems.
> I am all for good design and modularisation, but to date I have not seen
> anyone write an OSGi white paper specifically stating how this
> technology will revolutionize my life, or even make my job easier.
>
One thing it allows to do is that it allows to keep
classes/packages/namespaces local to an OSGi bundle (think of this as
something like an Eclipse plugin).
This means: you don't pollute the complete class space with a library if
you don't want.
Say one component C uses library FooParser, version 1.x. Great, no problem.
But then, you'd like to integrate another component N that someone
wrote, but that _neeeeeds_ FooParser 2.x with the new Flubmeister
functionality.
Problem: all of them live in org.fooparser.*, except that version 1.x
and version 2.x aren't really compatible, so component C won't work with
version 2.x.
What do you do in such a case?
OSGi allows component C to bundle and use FooParser 1.x. If you don't
export the org.fooparser.* package, it'll only be visible in component C.
Component N bundles FooParser 2.x and since the 1.x versions are only
visible to component C, component N will happily use 2.x classes.
(My kingdom for a whiteboard...).
Basically: you know how Servlet webapps are seperated with classloaders?
It's the same thing. But this wasn't available for general Java apps.
Use a OSGi runtime, and you'll get that - ie. it'll do all the
classloader magic so you don't have to. And since OSGi is already quite
old and mature,
it's also configurable to all kinds of situations.
Again: it's boring technology, nothing to get excited about. BUT: it
means it's another thing I don't have to worry about.
Versioning of bundles also something that OSGi solves: a component can
say it wants to use a particular version of a bundle. You _can't_ do
that with Jars nowadays; once the Jar is on the CLASSPATH, it's used and
that's that. With OSGi you can have component A using Component D 1.1,
and component B using Component D 1.2 with no problem.
There are other things, like dynamic bundle loading/unloading, but
that's something to another day.
The word "Component" is a regular guest on the Javaposse - but it's
not something that is a reality in Java today. We don't have cleanly
seperated components, and it's mostly for a lack of a nice architecture.
OSGi allows this, with the features I described.
Werner Schuster (murphee)
> Finally, everyone has said that modules won't be available for
> anything before Dolphin. Until more details about JSR-277 and JSR-294
> become available, I will continue to doubt that. Sun won't support
> them, but they might well get backported.
>
for Java 7, so I wouldn't bet on using it on Mustang (unless some
serious Retroweaving is possible...).
Curt Cox
"Why Developers Should Not Write Programs That Call 'sun' Packages"
http://java.sun.com/products/jdk/faq/faq-sun-packages.html
The things holding Java modularity (OSGi now) back are lack of
language and tool support. If the bookkeeping gets too hard, people
consider telling people not to use the public APIs to be a solution.
It's not really.
Casper Bang
my experiences.
SUN's RCP was impossible to find online but was only something you
could hear Tor talk about in the Posse. I evaluated Eclipse but it used
SWT and if you start on this path, you are hardly much more platform
independent than you were in VB6. SWT and Swing generally did not mix
well and you had to distribute native dll/so files. Today, with Matisse
AND an official SUN RCP the choice would be simple! I however, ended up
rolling my own with the result that I am pretty much the only one who
can maintain these 35.000 LOC. http://www.brunata.com/ptd/endresult.png
> The word "Component" is a regular guest on the Javaposse - but it's
> not something that is a reality in Java today. We don't have cleanly
> seperated components, and it's mostly for a lack of a nice architecture.
> OSGi allows this, with the features I described.
Haven't heard of OSGi, but it sounds interesting. Ironically, there is
currently much more components over JSF than in Swing, the latter which
seems to have been a great lesson in too-high-coupling at too low a
level. I fear it may go with JSR-277 as with java.beans and
java.util.jar.Pack200. Its there, but few if any actually uses it.
Curt Cox
> for Java 7, so I wouldn't bet on using it on Mustang (unless some
> serious Retroweaving is possible...).
It has already been demonstrated that serious Retroweaving is
possible, so why not more? For the sake of precision, JSR-277 will
rely on some kind of binary artifact, like bytecodes, class file
formats, etc... rather than language changes. The language changes
will be the Java mechanism for producing the binary artifacts, but
there are lots of languages on the JVM.
Casper Bang
Unless we want to invent the wheel constantly, sometimes we are just
too tempted to do it. Trivial example:
PHP has base64_encode(), .NET has Convert.ToBase64String(), Ruby has
Base64.encode64() and Java has... well sun.misc.BASE64Encoder! :(
Alexis Moussine-Pouchkine
@ Murphee: do you think the NetBeans Platform has been waiting for something like JSR 277? I agree that now the answer is most likely RCPs, but I wouldn't rule out JSR 277 & 296 just yet.
@ Dick: yes IMO Matisse is still a plus when considering RCPs and this brings us to one big different between RCP: NetBeans Platform is Swing based, Eclipse RCP builts on SWT and in both cases these APIs do surface to the developer (can't ignore them).
RCPs (OSGi-based or not) start to show their strength if you need to structure you development efforts between different teams (modules will have specification and implementation versions and dependencies). A module can also hide Java 'public' artifacts to other modules which gives you a more granular say at what the component contract is (the equivalent JSR would be super-packages I guess). While window managers also exist as standalone modules (NetBeans' is here), RCPs provide one. Auto-update, file-system abstraction, wizards are also reasons for using an RCP.
Being able to pick and choose features from the bigger platform/IDE is also nice (a editor, a property sheet, graph library etc.). This is nicely shown in this NetBeans Platform presentation.
As this was already written, RCP come at a price: a steep learning curve, so yes JSR 296 (Application Framework) should be nice when it is made available and integrated in IDEs.
While both Eclipse and NetBeans can be used on the server-side, I believe it applies more to pluggable services rather straight to business logic (but then it depends on the application you're building).
cheers,
-Alexis
Curt Cox
"Make sun.misc.BASE64{De,En}coder classes public"
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4235519
BASE64{De,En}coder is a best-case scenario.
I know better than to use SunToolkit.getDefaultToolkit(), but I could.
Casper Bang
OMFG. Submitted on 05-MAY-1999. No wonder why there now is a JSR for
improving the JCP.
Dick Wall
from the eclipse intro videos we talked about in episode 89) that to my
mind, for VB replacement (which is what we are talking about here),
Matisse would be a bigger deal than OSGi. If we are just looking at
taking someone from VB6 and plonking them into Java GUI development,
then I do believe Matisse is the way to go. You might be able to get
this with the MyEclipse matisse port for eclipse, but then would you be
able to use the Eclipse RCP? (Seriously I would like to know - I don't
know if using Swing/Matisse/GroupLayout precludes using the eclipse RCP
as intended, and I would like to know the answer to that).
Cheers
Dick
On Oct 20, 12:57 pm, "Alexis Moussine-Pouchkine" <alexis...@gmail.com>
wrote:
> (started writing this a couple of hours back, got distracted. Sorry if it's
> out of sync with the thread)
>
> @ Murphee: do you think the NetBeans Platform has been waiting for something
> like JSR 277? I agree that now the answer is most likely RCPs, but I
> wouldn't rule out JSR 277 & 296 just yet.
>
> @ Dick: yes IMO Matisse is still a plus when considering RCPs and this
> brings us to one big different between RCP: NetBeans Platform is Swing
> based, Eclipse RCP builts on SWT and in both cases these APIs do surface to
> the developer (can't ignore them).
>
> RCPs (OSGi-based or not) start to show their strength if you need to
> structure you development efforts between different teams (modules will have
> specification and implementation versions and dependencies). A module can
> also hide Java 'public' artifacts to other modules which gives you a more
> granular say at what the component contract is (the equivalent JSR would be
> super-packages I guess). While window managers also exist as standalone
> modules (NetBeans' is here <https://jdocking.dev.java.net/>), RCPs provide
> one. Auto-update, file-system abstraction, wizards are also reasons for
> using an RCP.
>
> Being able to pick and choose features from the bigger platform/IDE is also
> nice (a editor, a property sheet, graph library
> <http://graph.netbeans.org/>etc.). This is nicely shown in this
> NetBeans
> Platform presentation <http://www.javalobby.org/eps/netbeans_platform>.
>
> As this was already written, RCP come at a price: a steep learning curve, so
> yes JSR 296 (Application Framework) should be nice when it is made available
> and integrated in IDEs.
>
> While both Eclipse and NetBeans can be used on the server-side, I believe it
> applies more to pluggable services rather straight to business logic (but
> then it depends on the application you're building).
>
> cheers,
> -Alexis
>
Werner Schuster (murphee)
> then I do believe Matisse is the way to go. You might be able to get
> this with the MyEclipse matisse port for eclipse, but then would you be
> able to use the Eclipse RCP? (Seriously I would like to know - I don't
> know if using Swing/Matisse/GroupLayout precludes using the eclipse RCP
> as intended, and I would like to know the answer to that).
>
course you'd miss out on a lot of the GUI parts (Update manager, simple
Preferences dialogs, predefined Command infrastructure, Help Browser, etc).
What you could do is use Eclipse RCP, but build your GUI components in
Swing and put them inside the SWT/JFace based Frame you get. Of course,
the LnF differences would make this look odd, and it's probably not the
way to go.
Mind you: the "customers" of a the former VB program would probably
like to get their good old native components, which does favor SWT/JFace
(yes, I know about Windows LnF, but I don't care).
I'm very happy with VE for building SWT GUIs. I particularly find it
marvelous, since it helps to learn how the GUI toolkit works because VE
builds the source code for the visual model you drag together. This is
particularly good for novices because they'll just drag their GUI
together with VE, and simultaneously learn what drives the code. That's
how I learned a lot about building up SWT GUIs without ever cracking
open a manual, ie. learning by doing.
Curt Cox
I don't expect OSGi to hold any value for the average VB
developer--beyond any value it might have as an enabling technology
for component based development. The average VB developer is a
component consumer. The Java component marketplace is comparatively
anemic. (Hey, Tor, how do I get the JSR-273 RI?)
"You might be able to get this with the MyEclipse matisse port for
eclipse, but then would you be able to use the Eclipse RCP?"
Yes. Like OSGi, I doubt either the Eclipse or NetBeans platforms will
appeal much to the average VB developer. (Hans, how do I get the
JSR-296 RI?)
"Seriously I would like to know - I don't know if using
Swing/Matisse/GroupLayout precludes using the eclipse RCP as intended,
and I would like to know the answer to that."
Eclipse RCP depends on OSGi and SWT. Other than that Eclipse RCP,
OSGi, Swing and SWT are all independent. You can use either Swing or
native SWT for Eclipse RCP. The native Windows port of SWT is
currently far less buggy than the Swing one, but given the rate of
recent improvement and the number of Swing developers, I don't expect
that too last long.
Hopefully this thread will continue long enough that I can mention all
of the JSRs that I want to see in Dolphin. (Carl, how do I get the
JSR-203 RI?)
Jesse Eichar
Around 2 years ago our company had to make the same comparison.
Obviously the landscape has changed some since then but I think some
of the issues remain the same.
We decided to use Eclipse for a couple of reasons.
1. SWT. We really liked how Eclipse RCP applications integrate with
the other applications on all platforms. The consideration here is
what platforms you want to run on. SWT work great on all the common
platforms. MAC, Linux, WIndows 64 and 32 bit versions. One of the
big problems I found with Swing is that it always behaves slightly
different then other programs on the same platform. Look at the file
dialog as an example of this.
2. Tools. The tool support for developing RCP apps is brilliant.
Eclipse is a very powerful IDE and was developed using its own PDE
which is used to develop RCP apps so the PDE (Plugin Development
Environment) is excellent.
3. Documentation. There is TONS of excellent documentation.
Eclipse Rich Client Platform is an excellent book as well as Eclipse:
Building Commercial-Quality Plug-ins.
4. Eclipse based frameworks and plugins. There are numerous useful
plugins and Eclipse frameworks that can be used to enrich your
application (not just your IDE). For example: BIRT, EMF, DTP, DSDP,
uDig, etc.. You can see many of them here: http://www.eclipse.org/
projects/
5. OSGI. Don't undervalue the benefits of having a good plugin
framework. At a basic level OSGI is very useful. Once you get
better it is invaluable. Being able to define extension points, what
package to export, whether to lazy load the plugin.
6. Update Manager. Not much to say about that.
There were other considerations but those were the big items that
persuaded us to use eclipse RCP. And it has been very rewarding and
we haven't found any issues that hindered us in a big way. We are
building a RCP application with lots of UI elements, dialogs, wizards
etc... JFace is a wonderful toolkit IMHO.
I saw a mention that Swing/AWT doesn't work with SWT and I can say
from experience that this isn't such a big issue. Although it is
possible that the AWT_SWT bridge may not work on some platforms like
SPARC or something. Again, all the main ones are working fine (Mac,
Linux,-32&64-bit versions, Windows- 32&64-bit versions).
Personally I think both are good platforms. The GUI building may not
be Matisse but it is pretty good on eclipse and if you want to use
matisse you can always embed the Swing components in SWT using the
AWT_SWT Bridge, or even use Swing/AWT instead of SWT.
From a feature-feature POV they are probably pretty close. I would
be interested in seeing the stats between the number of Eclipse RCP
apps vs the number of NetBeans RCP apps. I have no idea about that.
Our application is a application/Framework and it alone has a few
dozen application that are based on it. I image the many of the
other frameworks have at least as many apps build on them as well.
So as a RCP it is well tested and very stable.
Cheers,
Jesse
Neil Swingler
> Hi Pär, I was looking for a RCP almost a year ago as well and here are
> my experiences.
> SUN's RCP was impossible to find online but was only something you
> could hear Tor talk about in the Posse. I evaluated Eclipse but it used
> SWT and if you start on this path, you are hardly much more platform
> independent than you were in VB6. SWT and Swing generally did not mix
> well and you had to distribute native dll/so files. Today, with Matisse
> AND an official SUN RCP the choice would be simple! I however, ended up
> rolling my own with the result that I am pretty much the only one who
> can maintain these 35.000 LOC. http://www.brunata.com/ptd/endresult.png
>
sorted but SWT (regardless of it's technical merits) is a real barrier
to adoption. If Eclipse had used Swing, every non trivial java desktop
app would now be built on the Eclipse RCP.
- Neil
Tor Norbye
Let me just make a couple of random comments.
First, Murphee has been writing at length about the benefits of using
Eclipse and OSGI. Let me just say that all the stuff you're listing --
the ability to include multiple different versions of the same library
and have different clients consume different versions, the ability to
have multiple update centers and have these things updated by the
users, etc. etc. ALL that is supported by NetBeans, and has been, for
several years. Just because the Java platform has not had a module
system, has not stopped OSGI - and NetBeans - from developing something
on top of it. NetBeans has a strong module concept too. When you create
a module, you can choose exactly which packages to expose to clients.
Plugin development for NetBeans is also getting really strong. Yes,
this was difficult in the past, but from version 5.0 and on things work
really well. You probably saw this thread a year ago, and things have
not stood still:
http://eclipsezone.com/eclipse/forums/t44963.html
Finally, this point has been made a couple of times in this thread but
I think it can be repeated: If you choose NetBeans, you can use Swing.
That makes it a lot easier to integrate existing libraries (which tend
to use Swing), and you can use Matisse to design further forms.
Somebody stated above that SWT works everywhere just fine now. That
doesn't seem to be universally agreed upon. MyEclipse still doesn't
support Matisse on the Mac.
Somebody said there has been nothing about the NetBeans RCP except for
when I talked about it on the Posse in the last year; I'm pretty sure
http://platform.netbeans.org has been there for a couple of years. It's
the "RCP" moniker that might be new, but the idea that NetBeans would
host non-IDE applications has been there architecturally from early on,
and there were several adopters of the NetBeans platform starting back
at the beginning.
-- Tor
Werner Schuster (murphee)
> First, Murphee has been writing at length about the benefits of using
> Eclipse and OSGI. Let me just say that all the stuff you're listing --
> the ability to include multiple different versions of the same library
> and have different clients consume different versions, the ability to
> have multiple update centers and have these things updated by the
> users, etc. etc. ALL that is supported by NetBeans, and has been, for
>
never mentioned Netbeans in my emails
and I've never implied that it's module system was incapable of doing
these things.
BTW, fun OSGi fact for today: Did you know OSGi bundles can run on just
about anything, OSGi has very basic minimum requirements:
See: http://wiki.eclipse.org/index.php/Execution_Environments (scroll
down)
Or: http://wiki.eclipse.org/index.php/Equinox_-_Demos
Ie. if your OSGi bundle only uses J2ME classes, you can even deploy it
to your phone and get all the goodies of OSGi.
Eclipse RCP also has eRCP: http://www.infoq.com/news/eclipse-rcp-version1.0
but since there are many OSGi runtimes
(http://www.aqute.biz/OSGi/Resources) you're not restricted to that.
Dick Wall
I think Tor might be referring to your blog where you mention that JSR
277 is just OSGi without the 8 years of experience, and some of the
articles you quote/link to seem to indicate that the eclipse camp
believes that OSGi should be a shoe-in defacto standard simply by
seniority, despite the fact that the JCP allows everyone to have a
voice, and those voices should be heard. Before condemning the JCP for
forking the Java community versus OSGi, I think it is important to
consider that Netbeans *was* doing it first, and that I don't believe
the JCP feeds any desire from Sun to give in to a NIH philosophy, nor
could I disagree more strongly that the JCP is like Jackass.
BTW - anyone who is interested and hasn't read this blog entry and the
comments might want to check it out
http://jroller.com/page/murphee?entry=jsr_277_vs_osgi_here
Personally I can't want to see what luminaries like Jason Van Zyl and
Doug Lea, and companies like Google, BEA, Oracle and Red Hat can bring
to the table. I *want* to hear what these guys have to add - I don't
want to settle for OSGi without exploring the alternatives, and if the
OSGi guys want to bring that 8 years of experience to help the JSR, I
am sure they would be welcomed with open arms (heck, OSGi could have
been put into the JCP several years ago come to that, so why wasn't
it?)
Cheers
Dick
On Oct 23, 5:37 pm, "Werner Schuster (murphee)"
<werner.schus...@gmail.com> wrote:
> Tor Norbye wrote:
> > First, Murphee has been writing at length about the benefits of using
> > Eclipse and OSGI. Let me just say that all the stuff you're listing --
> > the ability to include multiple different versions of the same library
> > and have different clients consume different versions, the ability to
> > have multiple update centers and have these things updated by the
> > users, etc. etc. ALL that is supported by NetBeans, and has been, forI'm not sure why you and Alex M-P. feel the need to point this out - I
Curt Cox
"Before condemning the JCP for forking the Java community versus OSGi,
I think it is important to consider that Netbeans *was* doing it
first, and that I don't believe the JCP feeds any desire from Sun to
give in to a NIH philosophy, nor could I disagree more strongly that
the JCP is like Jackass."
I know little of this Jackass of which you speak. The chronology,
however, is murky at best.
"I know that in 1998 we managed to release "classpath" modules - e.g. sources
were separated as modules, but everything was on flat classpath. So the
intention was there, the technology was not.
In 1999 we managed to rewrite the module system to use own classloader(s) and
parse manifests for necessary information. So the technology was there, but
in pretty poor state. For example lifecycle management was not really
supported.
Then Jesse did rewrite of the runtime container to assign one classloader to
one module, add reasonably good support for lifecycle management, etc.
Basically similar to what we have now. I am not sure if that was 2000 or
2001. That would in my opinion be the day when NetBeans module system got
mature."
http://openide.netbeans.org/servlets/ReadMsg?list=dev&msgNo=21674
"PALO ALTO, Ca. -- October 1, 1998 -- Sun Microsystems, Inc. today
announced the commercial availability of Java[tm] Embedded Server, a
small footprint network server that enables real-time deployment and
installation of applications to remote embedded devices."
http://www.sun.com/smi/Press/sunflash/1998-10/sunflash.981001.1.xml
Some of us are concerned that issues raised here:
"JSR 277 Review"
http://www.osgi.org/blog/2006/10/jsr-277-review.html
won't be answered, because issues raised here weren't:
"JSR47 vs. log4j"
http://www.ingrid.org/jajakarta/log4j/jakarta-log4j-1.1.3/docs/critique.html
If the expert group would address those issues, my concerns might go
away. I can't help but think that JSR47 would have supplanted log4j
by now, if had changed things like its bogus levels.
"JSR 47 defines the levels ALL, SEVERE, WARNING, INFO, CONFIG, FINE,
FINER, FINEST and OFF. Experience shows that the levels ALL and OFF
are never needed. The SEVERE and CONFIG levels are unique to JSR47.
Having three debugging levels FINE, FINER, FINEST could seem like a
good idea. However, you will soon discover that even when by yourself,
it is hard to decide when to use which level. It is plain impossible
in groups.
Log4j in contrast has a limited but self-evident set of priorities:
FATAL, ERROR, WARN, INFO and DEBUG."
- Curt
Werner Schuster (murphee)
> articles you quote/link to seem to indicate that the eclipse camp
> believes that OSGi should be a shoe-in defacto standard simply by
> seniority,
Peter Kiens' review of JSR 277 (
This is a list of problems he finds with JSR 277 )
http://www.osgi.org/blog/2006/10/jsr-277-review.html
and it's not just some appeal to seniority, but a long list of arguments.
There _is_ the fact that OSGi has 8 years of experience, but then
this mostly uses the idea that Version 1.0 of anything is bad and in
need of work.
Examples:
- Windows < 3 was useless,
- Java 1 was a prototype, Java 1.1, was incremental change, Java 1.2
was the first complete Java.
- EJB < 5 ... no comment, EJB >= 5 ... well, I'll just trust the
Javaposse's ravings about it;
- etc.
> despite the fact that the JCP allows everyone to have a
> voice, and those voices should be heard. Before condemning the JCP for
> forking the Java community versus OSGi,
>
Just a second... you _did_ read the comments for JSR 277:
http://jcp.org/en/jsr/results?id=3238
(they're for creation, as far as I understand).
I'd say they were already very skeptical _before the spec was even
started_, particularly Google's comment.
> consider that Netbeans *was* doing it first, and that I don't believe
> the JCP feeds any desire from Sun to give in to a NIH philosophy,
Erm... the fact that they go out and create a completely _new_ system
despite the fact that there are some around ... well... isn't that the
definition of NIH?
> nor could I disagree more strongly that the JCP is like Jackass.
>
http://en.wikipedia.org/wiki/Metaphor
Sigh... I should stop trying my hands at metaphors, they're usually
misunderstood.
What I'm trying to say "It's like watching a train wreck happening in
slowmotion" (or whatever english idiom is fitting),
I see the work on JSR 277 going on and there's no way this will be
avoided. ( _I_ believe it's not a good thing,
personal opinion, so nobody get offended again).
> to the table. I *want* to hear what these guys have to add - I don't
> want to settle for OSGi without exploring the alternatives, and if the
> OSGi guys want to bring that 8 years of experience to help the JSR, I
> am sure they would be welcomed with open arms (heck, OSGi could have
> been put into the JCP several years ago come to that, so why wasn't it?)
>
It's there,
the Wikipedia article gives a list of JSRs mentioning OSGi
http://de.wikipedia.org/wiki/OSGi
And there's JSR 291
http://www.osgi.org/blog/2006/02/jsr-291-dynamic-component-support-for.html
And about the question why OSGi advocates aren't on the JSR 277 team:
http://www.aqute.biz/Blog/2005-08-11
As I probably mentioned: I think all of this module stuff (whether it's
JSR 277 or OSGi or Maven) is boring as hell.
That's why I just want it solved now. .NET has all of this solved in 1.0
("assemblies", proper versioning, strong naming),
and this has been around since the _start of the decade_. With JSR 277 I
have to wait until the _next_ decade to use it
(Java 7 release late 2008, if Java 5 can aid as comparison, we'll have
to consider a 1-2 year period before we can use it - especially since
Java 7's changes will be _massive_, presumably more so than Java 5 ).
Tor Norbye
> I'm not sure why you and Alex M-P. feel the need to point this out - I
> never mentioned Netbeans in my emails
> and I've never implied that it's module system was incapable of doing
> these things.
Uhm. This is a thread asking for advice in choosing NetBeans versus
Eclipse. You then wrote a long e-mail arguing he should use Eclipse
because of the OSGI module concept, explaining modularity etc. etc.
This is all offered by NetBeans as well, and is therefore not a reason
to choose Eclipse. I therefore think pointing this out is highly
relevant to the discussion.
-- Tor
robilad
Werner Schuster (murphee) wrote:
> > nor could I disagree more strongly that the JCP is like Jackass.
> >
> http://en.wikipedia.org/wiki/Metaphor
> Sigh... I should stop trying my hands at metaphors, they're usually
> misunderstood.
> What I'm trying to say "It's like watching a train wreck happening in
> slowmotion" (or whatever english idiom is fitting),
> I see the work on JSR 277 going on and there's no way this will be
> avoided. ( _I_ believe it's not a good thing,
> personal opinion, so nobody get offended again).
Jackass is an awesome metaphor for the JCP.
The idea behind the Jackass TV show is that the viewer is continuously
kept stunned watching stunt experts try to hurt themselves in weird
ways. There is little or no justification for the unorthodox acts of
masochism presented, it all seems to happen because of a hunch: someone
thought getting tasered is a great idea, so it gets filmed.
>From the outside, the JCP is largely like that: apparently very nice
and intelligent people, experts in what they are doing , perfoming
seemingly painful stunts without much rationale or explanation given.
cheers.
dalibor topic
J. McConnell
>
> > nor could I disagree more strongly that the JCP is like Jackass.
> >
> http://en.wikipedia.org/wiki/Metaphor
> Sigh... I should stop trying my hands at metaphors, they're usually
> misunderstood.
Ummm ... no offense, but:
http://en.wikipedia.org/wiki/Simile
- J.
Curt Cox
Process". It's more polite, more descriptive, and points the way
toward improvement. In defense of the JCP, spec leads are allowed to
follow an open process, most of them just choose not to. JSR 166, for
example, was mostly developed in the open.
- Curt
"The Java Gated Community Process"
http://www.cafeaulait.org/editorials/jcp.html
"Effort on the edge, Part 2
A fact-based analysis of the JCP's effectiveness"
http://www.javaworld.com/javaworld/jw-01-2003/jw-0131-jcp.html
"Concurrency JSR-166 Interest Site"
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html
Curt Cox
(see Joseph Kelly's The Seagull Reader (2005), pages 377-379); in this
case, metaphor is the umbrella term for making comparisons between
unlike concepts, and simile describes the figure where one makes the
comparison explicit."
"Metaphor and Simile"
http://en.wikipedia.org/wiki/Metaphor
If you continue derailing this thread, I will never be able to
properly enumerate all the JSRs that should go in Dolphin.
Pär Dahlberg
to read different peoples preferences and what they think is important
in the environment and platform. Now, I'm not the one making the
decision but I'll surely bring this thread to the attention of the
others in the project.
I really wish I had the time (or that my boss told me to take the time
:) to sit down and build a real application based on both of these
RCPs.
Beeing able to separate the program in modules that can function
independently or as one program to the user is very important. The way
NetBeans modules work seem to be quite nice and there seems to be no
doubt that OSGi provides all that is needed on the Eclipse side. I do
get the feeling though that if one is building a quite large
application nicely structured with different types of business objects
in different modules, a bunch of different "screens" etc. there will be
loads of NB modules and because of that loads of NB projects. That
sounds a bit difficult to manage after some time. I might be wrong
about this or it might not be a problem to manage at all. Anyone got
experience of manageing a quite large application based on the NB RCP?
Is it like this in the Eclipse RCP?
What I am most worried about is the GUI part. I know Swing and after
some initial trouble with it I think it's quite easy to use. I used
Swing before I got hired as a VB programmer and even with the crazy
GridBagLayout I like Swing GUI building a lot better than VB. And now
with Matisse it's very easy to create a consistent good looking GUI. I
remember back in university when a few classmates really hated Java GUI
programming thanks to the layout managers that didn't let them position
the components as they wanted and made them feel like the layout
manager worked against them instead of providing the excellent support
that they do provide. That was compared to Delphi, but I would hate to
see people beeing put of by Java thanks to complicated GUI building.
Another thing that got to be positive about Swing these days is the
look and feel. I don't see why people hunt for the platform look all
the time. Sure, sometimes it's better if it looks like the other
applications or at least that it's not standing out in an ugly way. But
I think that today people are used to so many different GUIs thanks to
the web, that as long as a good graphical design is not hindering the
user to actually use the application it's only positive. I have a link
to a really good example somewhere, but I can't find it now. Someone
posted a very good looking screenshot of their LnF in a
comment/forum/blog, which were to be used as part of the branding of
their software. It looked very good and I bet that it's drawing some
extra attention to their product. I've never heard or read anything
about SWT in regards to this and I would guess that thanks to it's
nature it's the platform LnF you get. Anyone got anything on this? Is
it easy to spice up a GUI in SWT?
I've somewhat gotten the impression that when it comes to the question
of RCP many tend to look at the IDE first. Of course the working
environment should be as good as possible, but aren't both Eclipse and
NetBeans IDE *very* good? What I would like the most of a comparison of
these RCPs is answers to questions like "what sort of problems will we
face a couple of years down the line with this RCP - if any"? Of course
that's difficult to answer but I think that's more interesting than
comparing IDEs :)
Pär Dahlberg
> libraries you use. It would be interesting to see how well they
> handle real-world projects.
We're not converting the old VB project but instead rewriting it. A
conversion to .Net was the main plan for quite some time until it was
decided that it would probably be best to redesign the whole structure
instead of moving bad design decisions to a new platform. When that had
been decided we of course didn't need to stick to .Net any longer, but
could instead go after something better :)
Dick Wall
Google's (which you quote) -
On 2005-06-27 Google Inc. voted Yes with the following comment:
Google believes it is critical that the JSR-277 expert group focus on
the linguistic aspects of this design. If done well, this JSR has the
potential for great improvement to the platform; if done poorly it has
the potential for great harm.
I think that would go for any of the important JSRs, any of the ones
worth really putting some effort into anyway. No reward without some
risk, and so forth.
Also, Sun's comment seems pretty reasonable:
On 2005-06-22 Sun Microsystems, Inc. voted Yes with the following
comment:
To briefly clarify a couple of points:
Sun intends to create a diverse expert group for this JSR.
We intend to accommodate a variety of viewpoints and (among
others) will be happy to include any J2SE/J2EE EC members
who wish to participate.
It has been pointed out that OSGi R4 addresses some of the
concerns expressed about OSGi R3. Happiness. We will
be happy to treat OSGi as one of the inputs to this JSR.
- Graham
I think the key there is that they wish to accomodate a variety of
viewpoints. Adopting OSGi as is would hardly be accomodating a variety
of viewpoints. They comment that OSGi R4 fixes some of the problems
with R3, and say they will treat it as one of the inputs? That strikes
me as pretty fair and balanced, given that there are a number of
parties on this JSR that have had little or no input to OSGi
Am I missing something here?
Cheers
Dick
On Oct 24, 11:52 am, "Werner Schuster (murphee)"
<werner.schus...@gmail.com> wrote:
> Dick Wall wrote:
> > articles you quote/link to seem to indicate that the eclipse camp
> > believes that OSGi should be a shoe-in defacto standard simply by
> > seniority,I don't know which articles you refer to, but I'd like to point out
> Peter Kiens' review of JSR 277 (
> This is a list of problems he finds with JSR 277 )http://www.osgi.org/blog/2006/10/jsr-277-review.html
> and it's not just some appeal to seniority, but a long list of arguments.
>
> There _is_ the fact that OSGi has 8 years of experience, but then
> this mostly uses the idea that Version 1.0 of anything is bad and in
> need of work.
> Examples:
> - Windows < 3 was useless,
> - Java 1 was a prototype, Java 1.1, was incremental change, Java 1.2
> was the first complete Java.
> - EJB < 5 ... no comment, EJB >= 5 ... well, I'll just trust the
> Javaposse's ravings about it;
> - etc.
>
> > despite the fact that the JCP allows everyone to have a
> > voice, and those voices should be heard. Before condemning the JCP for
> > forking the Java community versus OSGi,Just a second... you _did_ read the comments for JSR 277:http://jcp.org/en/jsr/results?id=3238
> (they're for creation, as far as I understand).
> I'd say they were already very skeptical _before the spec was even
> started_, particularly Google's comment.
>
> > consider that Netbeans *was* doing it first, and that I don't believe
> > the JCP feeds any desire from Sun to give in to a NIH philosophy,Erm... the fact that they go out and create a completely _new_ system
> despite the fact that there are some around ... well... isn't that the
> definition of NIH?
>
> > nor could I disagree more strongly that the JCP is like Jackass.http://en.wikipedia.org/wiki/Metaphor
> Sigh... I should stop trying my hands at metaphors, they're usually
> misunderstood.
> What I'm trying to say "It's like watching a train wreck happening in
> slowmotion" (or whatever english idiom is fitting),
> I see the work on JSR 277 going on and there's no way this will be
> avoided. ( _I_ believe it's not a good thing,
> personal opinion, so nobody get offended again).
>
> > to the table. I *want* to hear what these guys have to add - I don't
> > want to settle for OSGi without exploring the alternatives, and if the
> > OSGi guys want to bring that 8 years of experience to help the JSR, I
> > am sure they would be welcomed with open arms (heck, OSGi could have
> > been put into the JCP several years ago come to that, so why wasn't it?)It's there,
> the Wikipedia article gives a list of JSRs mentioning OSGihttp://de.wikipedia.org/wiki/OSGi
> And there's JSR 291http://www.osgi.org/blog/2006/02/jsr-291-dynamic-component-support-fo...
J. McConnell
Wow, I apologize for derailing the thread ... I don't think I realized
there was a thread to derail at this point ;)
In my defense, further on in the same article you link to:
"Although in practice their use is often synonymous, in a rigorous
sense, their meanings can be understood to be quite different. Whereas
simile explicitly describes a comparison, metaphor asserts an
identity."
Seriously though, my post was meant to be taken in a light-hearted
manner. I do apologize if anyone took it differently.
- J.
pkriens
I have been working with the OSGi since inception and I tried to get
into JSR 277 from day 1, obviously. Not to get OSGi accepted wholesale,
but to provide the experience and insight we gained.
I was refused.
I asked several large companies and persons on the EC to help me, who
were astonished that I was rejected. I was still refused.
If you do a JSR you have the duty to explore alternative solutions and
I would have been happy to provide our knowledge. I also think the JSR
has the duty to not gratuitously do tihngs different when there is a
standard out there that is quite popular. Why choose B if A is virtual
the same but compatible?
The JSR could have been exciting because it could have addressed some
(well many) of the deficiencies of the Class Loader model. I would have
loved to work on that. However, the EDR is just a small subset of OSGi,
they just made the syntax incompatible.
So I do not think JSR 277 even remotely tried to take the OSGi
experiences into account, nor did they intent to do that.
Kind regards,
Peter Kriens