My notes about project Jigsaw from JavaOne
6 views
Skip to first unread message
Augusto Sellhorn
Jun 11, 2009, 11:17:46 PM6/11/09
to The Java Posse
In case anybody is interested, I wrote a summary of the Jigsaw/Java
Modularity discussions at this year's JavaOne:
http://sellmic.com/blog/2009/06/11/classpath-hell-just-froze-over/
I'm kind of surprised there's not a lot more discussion around Jigsaw
since it includes such fundamental changes, and there's till the whole
controversy around Sun not leveraging OSGi.
Anyways, in the last part of that blog post I put some notes regarding
the Java Modularity Q&A / BOF. Carl, I noticed you were among the
audience, I wonder what your impressions of the discussion were.
Modularity discussions at this year's JavaOne:
http://sellmic.com/blog/2009/06/11/classpath-hell-just-froze-over/
I'm kind of surprised there's not a lot more discussion around Jigsaw
since it includes such fundamental changes, and there's till the whole
controversy around Sun not leveraging OSGi.
Anyways, in the last part of that blog post I put some notes regarding
the Java Modularity Q&A / BOF. Carl, I noticed you were among the
audience, I wonder what your impressions of the discussion were.
Augusto
Jun 12, 2009, 12:19:35 AM6/12/09
to The Java Posse
Whoops, I meant to say I saw Dick Wall at the Q&A and not Carl. If
often get the Java Posse members confused, you know, because of those
big hats and all :-)
On Jun 11, 11:17 pm, Augusto Sellhorn <augusto.sellh...@gmail.com>
wrote:
often get the Java Posse members confused, you know, because of those
big hats and all :-)
On Jun 11, 11:17 pm, Augusto Sellhorn <augusto.sellh...@gmail.com>
wrote:
Steve
Jun 17, 2009, 8:05:42 PM6/17/09
to The Java Posse
On Jun 12, 1:17 pm, Augusto Sellhorn <augusto.sellh...@gmail.com>
wrote:
>
- modularity inside Java itself is obviously a good thing
- if OSGi was not an appropriate choice for that, then Sun coming up
with their own module system is fine for the task of modularising the
jvm
- bringing the concept of modules to the language itself is also a
good thing
The issue is when Jigsaw is positioned as something *application*
developers might want to leverage, I can't see how that cannot result
in fragmentation (for example, finding 3rd party libraries with OSGi
metadata is already difficult, asking developers to support OSGi *and*
Jigsaw is not going to endear them to the cause of java modularity).
The podcast interview was good (they always are:) however the guys
should have nailed them more on why we need another module system
targeted at application developers (as opposed to intra-vm stuff).
wrote:
>
> I'm kind of surprised there's not a lot more discussion around Jigsaw
> since it includes such fundamental changes, and there's till the whole
> controversy around Sun not leveraging OSGi.
>
My ill-informed take on this is:
> since it includes such fundamental changes, and there's till the whole
> controversy around Sun not leveraging OSGi.
>
- modularity inside Java itself is obviously a good thing
- if OSGi was not an appropriate choice for that, then Sun coming up
with their own module system is fine for the task of modularising the
jvm
- bringing the concept of modules to the language itself is also a
good thing
The issue is when Jigsaw is positioned as something *application*
developers might want to leverage, I can't see how that cannot result
in fragmentation (for example, finding 3rd party libraries with OSGi
metadata is already difficult, asking developers to support OSGi *and*
Jigsaw is not going to endear them to the cause of java modularity).
The podcast interview was good (they always are:) however the guys
should have nailed them more on why we need another module system
targeted at application developers (as opposed to intra-vm stuff).
Steve
Jun 17, 2009, 8:12:36 PM6/17/09
to The Java Posse
> I'm kind of surprised there's not a lot more discussion around Jigsaw
> since it includes such fundamental changes, and there's till the whole
> controversy around Sun not leveraging OSGi.
>
> since it includes such fundamental changes, and there's till the whole
> controversy around Sun not leveraging OSGi.
>
Reinier Zwitserloot
Jun 19, 2009, 7:35:18 PM6/19/09
to The Java Posse
I think the jigsaw team spelled it out pretty well:
1. There are things OSGi can't do that we deem important.
Specifically:
- Run different modules into the same classloader if you so choose.
(OSGi being incapable of doing this annoys me to no end - low level
operations can get really thrown off if you can't do this, and the jvm
core is obviously filled to the brim with these)
- Move modularization into the runtime (OSGi's modularization support
is awkward and annoying at runtime, through no fault of their own,
because java just doesn't support it in v1.6 and down!) - WITHOUT
needing to wait for OSGi to get with the program. This is a bit more
contentious, perhaps, but java moving fast for a change - I can't
really bring myself to complain about it.
- Keep things simpler by excluding e.g. lifecycle management. Simpler
is another one of those things.
I also believe the jigsaw guys made a decent case that OSGi can
probably adapt quite easily to be able to work flawlessly with jigsaw
modules (but not the other way around, as OSGi is a lot heavier in
certain areas). I'm not _certain_ this is true, of course, and the
sheer vitriol and whine spilling out of the OSGi camp makes me think
they might just be juvenile enough to obstinately refuse to write
support for jigsaw modules into OSGi (seriously, OSGi people, grow
up!). Nevertheless I hold high hopes that this will happen, and that
it won't require that much work for the OSGi camp. Therefore, the
'this will split the java world in twain' argument is FUD.
1. There are things OSGi can't do that we deem important.
Specifically:
- Run different modules into the same classloader if you so choose.
(OSGi being incapable of doing this annoys me to no end - low level
operations can get really thrown off if you can't do this, and the jvm
core is obviously filled to the brim with these)
- Move modularization into the runtime (OSGi's modularization support
is awkward and annoying at runtime, through no fault of their own,
because java just doesn't support it in v1.6 and down!) - WITHOUT
needing to wait for OSGi to get with the program. This is a bit more
contentious, perhaps, but java moving fast for a change - I can't
really bring myself to complain about it.
- Keep things simpler by excluding e.g. lifecycle management. Simpler
is another one of those things.
I also believe the jigsaw guys made a decent case that OSGi can
probably adapt quite easily to be able to work flawlessly with jigsaw
modules (but not the other way around, as OSGi is a lot heavier in
certain areas). I'm not _certain_ this is true, of course, and the
sheer vitriol and whine spilling out of the OSGi camp makes me think
they might just be juvenile enough to obstinately refuse to write
support for jigsaw modules into OSGi (seriously, OSGi people, grow
up!). Nevertheless I hold high hopes that this will happen, and that
it won't require that much work for the OSGi camp. Therefore, the
'this will split the java world in twain' argument is FUD.
Neil Bartlett
Jun 20, 2009, 5:33:49 AM6/20/09
to The Java Posse
Hello Reinier,
Some responses inline below. I consider myself in the so-called OSGi
"camp", though I am not an OSGi Alliance member nor do I speak for the
Alliance or any of its members.
On Jun 20, 12:35 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> I think the jigsaw team spelled it out pretty well:
I haven't seen these requirements stated directly by the Jigsaw team
(if indeed there is a team, I thought it was just Mark Reinhold).
Nevertheless it's useful to see *something* in terms of requirements,
I'd appreciate it if you could point me to where you read them.
> 1. There are things OSGi can't do that we deem important.
> Specifically:
>
> - Run different modules into the same classloader if you so choose.
> (OSGi being incapable of doing this annoys me to no end - low level
> operations can get really thrown off if you can't do this, and the jvm
> core is obviously filled to the brim with these)
OSGi certainly can do this. Bear in mind that without a classloader
for the module, it's not really a module because it has no enforced
separation from any other code sharing the same classloader. But since
an OSGi bundle is just a JAR plus metadata, you can add that JAR to
your bundle classpath, or load it dynamically using a URLClassLoader.
I'm not sure why this is a requirement since it just drags you back
down to the old non-modular classpath-based approach (and the same
will be true for Jigsaw when they do this... the classpath lives!),
but nevertheless it's there if you need to do it.
> - Move modularization into the runtime (OSGi's modularization support
> is awkward and annoying at runtime, through no fault of their own,
> because java just doesn't support it in v1.6 and down!) - WITHOUT
> needing to wait for OSGi to get with the program. This is a bit more
> contentious, perhaps, but java moving fast for a change - I can't
> really bring myself to complain about it.
This is quite funny. Of course OSGi cannot move into the runtime
(presumably you mean the JRE) without co-operation from Sun, because
Sun owns the JRE. If Sun choses to implement the OSGi specification
within the JRE then voila, OSGi is in the JRE.
If OSGi needs technical changes to make that work, then Sun should
just go ahead make those changes. Hopefully they would then come back
to the OSGi Alliance and tell the other members what had to be
changed, so those changes could be incorporated into the specification
for future releases. That would be very welcome, and it would not need
to slow down the development of Java at all. However instead of
starting from OSGi and changing it where it needed to be changed, Mark
has chosen to write a whole new module system from scratch, thus
delaying the release of Java 7 still further... and he won't explain
why.
> - Keep things simpler by excluding e.g. lifecycle management. Simpler
> is another one of those things.
Remove chapters 4, 5, and 8 from the OSGi core specification: you now
have a module system specification without lifecycle management. How's
that for simplicity?
OSGi is specified in layers. You don't want to think about dynamics
and lifecycle, then don't use them. You can benefit from the
modularity layer of OSGi without ever needing to learn about
lifecycle, if you so chose.
> I also believe the jigsaw guys made a decent case that OSGi can
> probably adapt quite easily to be able to work flawlessly with jigsaw
> modules (but not the other way around, as OSGi is a lot heavier in
> certain areas).
We would very much like to work with Jigsaw, if it comes into
existence and if we possibly can, and we would also like to help
Jigsaw interoperate with OSGi. The channels of communication are open,
but it takes two to tango.
Why is OSGi heavier? 29 core classes, of which 14 are interfaces.
> I'm not _certain_ this is true, of course, and the
> sheer vitriol and whine spilling out of the OSGi camp
Point me at some vitriol or whining and I will go and tell off the
author. That is, if I agree with you that it's vitriolic or whining.
If not, I implore YOU to stop whining.
> makes me think
> they might just be juvenile enough to obstinately refuse to write
> support for jigsaw modules into OSGi (seriously, OSGi people, grow
> up!).
Here's how support for Jigsaw or anything else can get into OSGi.
First an RFP (Request for Proposal) is written by somebody who is
interested in doing so. Anybody can do this, it is just a simple
requirements document. Then the OSGi core platform expert group (of
which Sun is a member) will vote on whether to create an RFC, which is
a work-in-progress specification document. Only OSGi members can work
on RFCs, but again, Sun is a member so they can participate fully.
Finally the RFC is written into the specification and implementers
such as Eclipse Equinox and Apache Felix can build the support.
No individual member company of OSGi can "obstinately refuse" to
support Jigsaw (unlike the JCP, no member has any special veto), and
if Jigsaw support is defined by the core specification then no OSGi
implementation can leave it out and remain a compliant implementation.
So, which member would you like to "grow up"? IBM? Oracle? Red Hat?
SAP? Sun...?
> Nevertheless I hold high hopes that this will happen, and that
> it won't require that much work for the OSGi camp. Therefore, the
> 'this will split the java world in twain' argument is FUD.
I believe you are being over-optimistic about the chances for
interoperability, but let's see. Even if they interoperate, it will
suck if developers have to understand two or more module systems and
work with them in parallel in the same application.
Some responses inline below. I consider myself in the so-called OSGi
"camp", though I am not an OSGi Alliance member nor do I speak for the
Alliance or any of its members.
On Jun 20, 12:35 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> I think the jigsaw team spelled it out pretty well:
(if indeed there is a team, I thought it was just Mark Reinhold).
Nevertheless it's useful to see *something* in terms of requirements,
I'd appreciate it if you could point me to where you read them.
> 1. There are things OSGi can't do that we deem important.
> Specifically:
>
> - Run different modules into the same classloader if you so choose.
> (OSGi being incapable of doing this annoys me to no end - low level
> operations can get really thrown off if you can't do this, and the jvm
> core is obviously filled to the brim with these)
for the module, it's not really a module because it has no enforced
separation from any other code sharing the same classloader. But since
an OSGi bundle is just a JAR plus metadata, you can add that JAR to
your bundle classpath, or load it dynamically using a URLClassLoader.
I'm not sure why this is a requirement since it just drags you back
down to the old non-modular classpath-based approach (and the same
will be true for Jigsaw when they do this... the classpath lives!),
but nevertheless it's there if you need to do it.
> - Move modularization into the runtime (OSGi's modularization support
> is awkward and annoying at runtime, through no fault of their own,
> because java just doesn't support it in v1.6 and down!) - WITHOUT
> needing to wait for OSGi to get with the program. This is a bit more
> contentious, perhaps, but java moving fast for a change - I can't
> really bring myself to complain about it.
(presumably you mean the JRE) without co-operation from Sun, because
Sun owns the JRE. If Sun choses to implement the OSGi specification
within the JRE then voila, OSGi is in the JRE.
If OSGi needs technical changes to make that work, then Sun should
just go ahead make those changes. Hopefully they would then come back
to the OSGi Alliance and tell the other members what had to be
changed, so those changes could be incorporated into the specification
for future releases. That would be very welcome, and it would not need
to slow down the development of Java at all. However instead of
starting from OSGi and changing it where it needed to be changed, Mark
has chosen to write a whole new module system from scratch, thus
delaying the release of Java 7 still further... and he won't explain
why.
> - Keep things simpler by excluding e.g. lifecycle management. Simpler
> is another one of those things.
have a module system specification without lifecycle management. How's
that for simplicity?
OSGi is specified in layers. You don't want to think about dynamics
and lifecycle, then don't use them. You can benefit from the
modularity layer of OSGi without ever needing to learn about
lifecycle, if you so chose.
> I also believe the jigsaw guys made a decent case that OSGi can
> probably adapt quite easily to be able to work flawlessly with jigsaw
> modules (but not the other way around, as OSGi is a lot heavier in
> certain areas).
existence and if we possibly can, and we would also like to help
Jigsaw interoperate with OSGi. The channels of communication are open,
but it takes two to tango.
Why is OSGi heavier? 29 core classes, of which 14 are interfaces.
> I'm not _certain_ this is true, of course, and the
> sheer vitriol and whine spilling out of the OSGi camp
author. That is, if I agree with you that it's vitriolic or whining.
If not, I implore YOU to stop whining.
> makes me think
> they might just be juvenile enough to obstinately refuse to write
> support for jigsaw modules into OSGi (seriously, OSGi people, grow
> up!).
First an RFP (Request for Proposal) is written by somebody who is
interested in doing so. Anybody can do this, it is just a simple
requirements document. Then the OSGi core platform expert group (of
which Sun is a member) will vote on whether to create an RFC, which is
a work-in-progress specification document. Only OSGi members can work
on RFCs, but again, Sun is a member so they can participate fully.
Finally the RFC is written into the specification and implementers
such as Eclipse Equinox and Apache Felix can build the support.
No individual member company of OSGi can "obstinately refuse" to
support Jigsaw (unlike the JCP, no member has any special veto), and
if Jigsaw support is defined by the core specification then no OSGi
implementation can leave it out and remain a compliant implementation.
So, which member would you like to "grow up"? IBM? Oracle? Red Hat?
SAP? Sun...?
> Nevertheless I hold high hopes that this will happen, and that
> it won't require that much work for the OSGi camp. Therefore, the
> 'this will split the java world in twain' argument is FUD.
interoperability, but let's see. Even if they interoperate, it will
suck if developers have to understand two or more module systems and
work with them in parallel in the same application.
Reinier Zwitserloot
Jun 20, 2009, 6:34:59 PM6/20/09
to The Java Posse
Responses inline.
On Jun 20, 11:33 am, Neil Bartlett <njbartl...@gmail.com> wrote:
> I haven't seen these requirements stated directly by the Jigsaw team
> (if indeed there is a team, I thought it was just Mark Reinhold).
Listen to the podcast. The 'team' is Buckley and Reinhold, and the
requirements were said on the podcast.
>
> OSGi certainly can do this. Bear in mind that without a classloader
> for the module, it's not really a module because it has no enforced
> separation from any other code sharing the same classloader.
Of course its a module. Just because they have no enforced *RUNTIME*
separation makes them not a module? You can't take the english word
'module', tack an arbitrary definition on top of this, and them point
at other people using the word and say they are doing it wrong.
If I create 10 eclipse projects, and carefully orchestrate the project
dependencies of these eclipse projects, I just rolled myself a module
system. It's a compile-time only module system, certainly, but it is
nevertheless a module system. Projects larger than a manyear or two
that aren't split up like this (handrolled as such, or via e.g. OSGi),
are going to become unmaintainable very very quickly, so this isn't
just a little 'gimmick' - it's of crucial importance.
This was a big part of the spiel by Reinhold and Buckley: A module
system is something that exists both at compile/write/deploy time, and
at runtime, and the concerns are very different between those two
modes of operation. From what I heard, jigsaw does an excellent job in
being flexible enough to serve for any situation. Nice case in point:
There are *PLENTY* of times when I really, -really- do not need *ANY*
runtime module separation, but it would be nice if I could roll up
some module spec that mijn build tools and IDEs all understand, and
that will cause them to automatically go ahead and find dependencies.
Jigsaw can more or less do this. So can OSGi, but OSGi also FORCES
various other concerns on me, many of which are related to runtime
separation.
> I'm not sure why this is a requirement since it just drags you back
> down to the old non-modular classpath-based approach (and the same
> will be true for Jigsaw when they do this... the classpath lives!),
> but nevertheless it's there if you need to do it.
What are you talking about?
The classpath has two crucial properties: 1) a method which finds
classes (and data files) by scanning through a list of file system
locations, and 2) This list is effectively global for that instance of
the JVM.
This just isn't true for jigsaw, even when using local deps. The idea
behind a local dep is that you use N compile-time modules to construct
1 runtime module. There are lots of situations where this is
*CRUCIAL*, and I find your inability to grok this very telling for
what I'm hearing form the OSGi camp (namely: They are sticking their
fingers in their ears and yelling loudly).
As Reinhold and Buckley specifically mentioned: In jigsaw, quite
unlike OSGi, 'split packages' is perfectly fine. This is excellent
news, because you can modularize not just vertically, but also
horizontally.
Example:
java.nio.Buffer has support for OS lowlevel directly linked buffers
for e.g. networking. There are plenty of uses for those, such as
rapidly reading out files, using an OS level shared buffer (you use
those on e.g. mac os x to share e.g. raw video data, as on mac os x
you can't just hand your window ID to another app and let them write
in your window; mac os x doesn't allow that for security reasons. This
is how the mplayer frontend works - it fires up an mplayer instance
and blits video data through a shared buffer!) - or, of course
networking. The shared buffer stuff should probably be a separate
module, and should probably exist as a unique module per target OS.
I can easily imagine that there are useful package private methods in
java.nio.Buffer that such implementations need. OSGi just makes this
needlessly complicated. Jigsaw just lets you get to work.
>
> This is quite funny. Of course OSGi cannot move into the runtime
> (presumably you mean the JRE) without co-operation from Sun, because
> Sun owns the JRE. If Sun choses to implement the OSGi specification
> within the JRE then voila, OSGi is in the JRE.
Isn't that just what I said? I only added that sun chose to roll their
own because they presumed it was going to be faster than working with
OSGi. Given the political storm OSGi's been cooking up, so far they
appear to be in the right on that topic. Still, you're right, on this
singular aspect they probably could have worked with OSGi just as well
or better. However, in light of the other requirements that OSGi
doesn't meet, the decision to roll their own makes more sense.
>
> If OSGi needs technical changes to make that work, then Sun should
> just go ahead make those changes.
You're saying : Sun ought to have forked OSGi.
Who gives a crap? Seriously - that's an implementation detail.
Neither you, nor I, nor anybody in the OSGi camp could possibly know
which strategy would lead to the best implementation in the least
amount of time. It could very well be that forking OSGi appeared to
cause more complexity than it would solve.
> starting from OSGi and changing it where it needed to be changed, Mark
> has chosen to write a whole new module system from scratch, thus
> delaying the release of Java 7 still further... and he won't explain
> why.
Mark was quite adamant that attempting to work with OSGi would have
caused far more of a delay than rolling his own.
>
> Remove chapters 4, 5, and 8 from the OSGi core specification: you now
> have a module system specification without lifecycle management. How's
> that for simplicity?
>
But then it wouldn't be OSGi. Which would be confusing. So they called
it jigsaw.
>
> We would very much like to work with Jigsaw, if it comes into
> existence and if we possibly can, and we would also like to help
> Jigsaw interoperate with OSGi. The channels of communication are open,
> but it takes two to tango.
>
It takes two to tango? Seriously? Man, you OSGi people get on my
nerves. Do you not see how presumptuously arrogant this looks? It's
the OSGi camp that's been insulting any attempt by sun to create a
module system that doesn't involve saying "We'll copy and paste OSGi
verbatim into the JRE". If I was sun, I would have stopped giving a
care in the world about OSGi a long long time ago. The jigsaw team is
still trying to communicate with OSGi. See e.g.
http://www.osgi.org/blog/2008/12/project-jigsaw.html - and the OSGi
team is talking back. It's the fanboys like yourself that are still
militant.
>
> Point me at some vitriol or whining and I will go and tell off the
> author. That is, if I agree with you that it's vitriolic or whining.
> If not, I implore YOU to stop whining.
>
Google around for any blog post about OSGi and jigsaw. See above link
where an OSGi alliance member himself raises the word 'violently' to
describe OSGi fan reaction to the versioning scheme (which is another
nice point: Jigsaw's is clearly superior; the decision in OSGi that
text implies a newer version is ridiculous).
Here's a troll that suggests using OSGi could _get you fired_. Holy
crap. That's quite a statement. Not to mention that it asks the user a
false choice:
http://neilbartlett.name/blog/2009/03/25/using-suns-jigsaw-may-get-you-fired/
I have a nagging feeling you're going to side with the author on that
one, for some strange reason :P
> So, which member would you like to "grow up"? IBM? Oracle? Red Hat?
> SAP? Sun...?
The fanboy crowd, actually.
On Jun 20, 11:33 am, Neil Bartlett <njbartl...@gmail.com> wrote:
> I haven't seen these requirements stated directly by the Jigsaw team
> (if indeed there is a team, I thought it was just Mark Reinhold).
requirements were said on the podcast.
>
> OSGi certainly can do this. Bear in mind that without a classloader
> for the module, it's not really a module because it has no enforced
> separation from any other code sharing the same classloader.
separation makes them not a module? You can't take the english word
'module', tack an arbitrary definition on top of this, and them point
at other people using the word and say they are doing it wrong.
If I create 10 eclipse projects, and carefully orchestrate the project
dependencies of these eclipse projects, I just rolled myself a module
system. It's a compile-time only module system, certainly, but it is
nevertheless a module system. Projects larger than a manyear or two
that aren't split up like this (handrolled as such, or via e.g. OSGi),
are going to become unmaintainable very very quickly, so this isn't
just a little 'gimmick' - it's of crucial importance.
This was a big part of the spiel by Reinhold and Buckley: A module
system is something that exists both at compile/write/deploy time, and
at runtime, and the concerns are very different between those two
modes of operation. From what I heard, jigsaw does an excellent job in
being flexible enough to serve for any situation. Nice case in point:
There are *PLENTY* of times when I really, -really- do not need *ANY*
runtime module separation, but it would be nice if I could roll up
some module spec that mijn build tools and IDEs all understand, and
that will cause them to automatically go ahead and find dependencies.
Jigsaw can more or less do this. So can OSGi, but OSGi also FORCES
various other concerns on me, many of which are related to runtime
separation.
> I'm not sure why this is a requirement since it just drags you back
> down to the old non-modular classpath-based approach (and the same
> will be true for Jigsaw when they do this... the classpath lives!),
> but nevertheless it's there if you need to do it.
The classpath has two crucial properties: 1) a method which finds
classes (and data files) by scanning through a list of file system
locations, and 2) This list is effectively global for that instance of
the JVM.
This just isn't true for jigsaw, even when using local deps. The idea
behind a local dep is that you use N compile-time modules to construct
1 runtime module. There are lots of situations where this is
*CRUCIAL*, and I find your inability to grok this very telling for
what I'm hearing form the OSGi camp (namely: They are sticking their
fingers in their ears and yelling loudly).
As Reinhold and Buckley specifically mentioned: In jigsaw, quite
unlike OSGi, 'split packages' is perfectly fine. This is excellent
news, because you can modularize not just vertically, but also
horizontally.
Example:
java.nio.Buffer has support for OS lowlevel directly linked buffers
for e.g. networking. There are plenty of uses for those, such as
rapidly reading out files, using an OS level shared buffer (you use
those on e.g. mac os x to share e.g. raw video data, as on mac os x
you can't just hand your window ID to another app and let them write
in your window; mac os x doesn't allow that for security reasons. This
is how the mplayer frontend works - it fires up an mplayer instance
and blits video data through a shared buffer!) - or, of course
networking. The shared buffer stuff should probably be a separate
module, and should probably exist as a unique module per target OS.
I can easily imagine that there are useful package private methods in
java.nio.Buffer that such implementations need. OSGi just makes this
needlessly complicated. Jigsaw just lets you get to work.
>
> This is quite funny. Of course OSGi cannot move into the runtime
> (presumably you mean the JRE) without co-operation from Sun, because
> Sun owns the JRE. If Sun choses to implement the OSGi specification
> within the JRE then voila, OSGi is in the JRE.
own because they presumed it was going to be faster than working with
OSGi. Given the political storm OSGi's been cooking up, so far they
appear to be in the right on that topic. Still, you're right, on this
singular aspect they probably could have worked with OSGi just as well
or better. However, in light of the other requirements that OSGi
doesn't meet, the decision to roll their own makes more sense.
>
> If OSGi needs technical changes to make that work, then Sun should
> just go ahead make those changes.
Who gives a crap? Seriously - that's an implementation detail.
Neither you, nor I, nor anybody in the OSGi camp could possibly know
which strategy would lead to the best implementation in the least
amount of time. It could very well be that forking OSGi appeared to
cause more complexity than it would solve.
> starting from OSGi and changing it where it needed to be changed, Mark
> has chosen to write a whole new module system from scratch, thus
> delaying the release of Java 7 still further... and he won't explain
> why.
caused far more of a delay than rolling his own.
>
> Remove chapters 4, 5, and 8 from the OSGi core specification: you now
> have a module system specification without lifecycle management. How's
> that for simplicity?
>
it jigsaw.
>
> We would very much like to work with Jigsaw, if it comes into
> existence and if we possibly can, and we would also like to help
> Jigsaw interoperate with OSGi. The channels of communication are open,
> but it takes two to tango.
>
nerves. Do you not see how presumptuously arrogant this looks? It's
the OSGi camp that's been insulting any attempt by sun to create a
module system that doesn't involve saying "We'll copy and paste OSGi
verbatim into the JRE". If I was sun, I would have stopped giving a
care in the world about OSGi a long long time ago. The jigsaw team is
still trying to communicate with OSGi. See e.g.
http://www.osgi.org/blog/2008/12/project-jigsaw.html - and the OSGi
team is talking back. It's the fanboys like yourself that are still
militant.
>
> Point me at some vitriol or whining and I will go and tell off the
> author. That is, if I agree with you that it's vitriolic or whining.
> If not, I implore YOU to stop whining.
>
where an OSGi alliance member himself raises the word 'violently' to
describe OSGi fan reaction to the versioning scheme (which is another
nice point: Jigsaw's is clearly superior; the decision in OSGi that
text implies a newer version is ridiculous).
Here's a troll that suggests using OSGi could _get you fired_. Holy
crap. That's quite a statement. Not to mention that it asks the user a
false choice:
http://neilbartlett.name/blog/2009/03/25/using-suns-jigsaw-may-get-you-fired/
I have a nagging feeling you're going to side with the author on that
one, for some strange reason :P
> So, which member would you like to "grow up"? IBM? Oracle? Red Hat?
> SAP? Sun...?
Josh Suereth
Jun 20, 2009, 10:24:40 PM6/20/09
to java...@googlegroups.com
Can we stop the name-calling? On the scala list serves, I usually reserve pictures of fluffy,furry, cute and cuddly kittens to help quell heated pointless arguments.
If you listen to the podcast again, you'll notice they specifically say that they didn't feel Sun could afford the time waiting for the OSGi-alliance to update themselves based on Sun's requirements. To this extent I do agree that Java really needs modularity. However it is also understandable how this would make the OSGi camp feel. Sun is basically saying, "Although you may have a good product, we can't affrod to wait around for your standards committee. We're going to do what we need and let OSGi follow along." This is far different from Sun's previous approaches (think EJB).
The good news is that it sounds like the Jigsaw + OSGi folks are at least talking. I don't think a merged approach to modularity will take long to follow the release of JDK 7. That is of course, assuming Jigsaw succeeds.
I think the biggest complaint coming from OSGi users (myself included) is that I don't want to have to deal with the complexity of 2 modularity tools. It's painful enough dealing with 2-3 different logging mechanisms accross 4-5 libraries. Competition is good, but integration is hard.
I'm just waiting for the modularity communities to start making "abstract modules" that define services that can be implemented by venders. Anyone remember CORBA?
- Josh
If you listen to the podcast again, you'll notice they specifically say that they didn't feel Sun could afford the time waiting for the OSGi-alliance to update themselves based on Sun's requirements. To this extent I do agree that Java really needs modularity. However it is also understandable how this would make the OSGi camp feel. Sun is basically saying, "Although you may have a good product, we can't affrod to wait around for your standards committee. We're going to do what we need and let OSGi follow along." This is far different from Sun's previous approaches (think EJB).
The good news is that it sounds like the Jigsaw + OSGi folks are at least talking. I don't think a merged approach to modularity will take long to follow the release of JDK 7. That is of course, assuming Jigsaw succeeds.
I think the biggest complaint coming from OSGi users (myself included) is that I don't want to have to deal with the complexity of 2 modularity tools. It's painful enough dealing with 2-3 different logging mechanisms accross 4-5 libraries. Competition is good, but integration is hard.
I'm just waiting for the modularity communities to start making "abstract modules" that define services that can be implemented by venders. Anyone remember CORBA?
- Josh
Massimo
Jun 21, 2009, 12:22:15 AM6/21/09
to The Java Posse
Interview and link in OP were very helpful.
I have a few simple Jigsaw questions:
How much (if any) of Project Jigsaw is usable in the current JDK 7
milestone?
What's a general ballpark time frame for when this stuff will be ready
to play with?
Maven is gaining lots of traction and wide usage and has related
modularity goals. Does Project Jigsaw overlap with Maven? Is it
reasonable to expect future Maven releases to adopt Project Jigsaw or
is that completely up in the air.
BTW, IMO command-line Java apps are fine speed wise (I write many of
these). The much bigger problem (as the Mr Reinhold pointed out) is
that they aren't native OS executables and you have to run them as
"java -jar ...".
I have a few simple Jigsaw questions:
How much (if any) of Project Jigsaw is usable in the current JDK 7
milestone?
What's a general ballpark time frame for when this stuff will be ready
to play with?
Maven is gaining lots of traction and wide usage and has related
modularity goals. Does Project Jigsaw overlap with Maven? Is it
reasonable to expect future Maven releases to adopt Project Jigsaw or
is that completely up in the air.
BTW, IMO command-line Java apps are fine speed wise (I write many of
these). The much bigger problem (as the Mr Reinhold pointed out) is
that they aren't native OS executables and you have to run them as
"java -jar ...".
Message has been deleted
Message has been deleted
Reinier Zwitserloot
Jun 22, 2009, 10:21:53 AM6/22/09
to The Java Posse
So, 'none of the reasons cited are good reasons'. Okay. Says you. That
was a big part of my rant: OSGi folk just piss all over jigsaw without
-EVER- mentioning anything constructive except that tired old bitty of
'There is no point' and 'It will fracture the market'. The podcast
quite clearly explained that jigsaw has overlap with OSGi, but there
are things OSGi can do that jigsaw can't (read: jigsaw is easier in
some respects), *and vice versa* (jigsaw fulfills certain requirements
that OSGi cannot). Hence, there IS a point, and the modularization
(heh) of finding resources means that it won't fracture the market
nearly as much as most OSGi folk think it will.
You say that the OSGi community is very open and welcoming, and yet
your reply is anything but. I've *never* seen anybody involved with
jigsaw throw stones at OSGi. Ever. Quote, please.
On Jun 22, 2:35 pm, Eric <enewco...@gmail.com> wrote:
> I have to say I these strong statements about OSGi are very
> uninformed. Nor does the cleverness of the language improve their
> credibility.
>
> None of the reasons cited are a good reason to invent a new module
> system, i.e. Jigsaw. It would be better for the industry to kill it,
> and the sooner the better:
>
> http://modualrit.blogspot.com/2009/06/kill-project-jigsaw-now-please....
>
> If speed to market is an issue, inventing something new is actually
> slower. Unless of course the argument is that Java is not, and never
> was, a standard but rather a product developed by Sun who can
> therefore do anything they like with it, regardless of any other
> vendor's investment. I have not heard that said before, but perhaps
> that's your position?
>
> OSGi has existed for 10 years, is used in thousands of technologies
> and projects, is mature, widely adopted, and proven to work. Lots of
> people would like new things to become standards, but it's impossible
> to achieve that simply by wishing it to be so. It takes many many
> years for new technologies to become widely adopted. We have two guys
> saying don't worry, we'll take care of all of those external forces by
> ourselves, and get Jigsaw as widely adopted and accepted as OSGi
> already is.
>
> It is also a provable fact that the OSGi Alliance runs an open
> process, and that OSGi folks have participated in JSR 294 from the
> beginning. They would have participated in Jigsaw if they had been
> able to.
>
> Many of the arguments are not in dispute. Everyone acknowledges the
> benefits of including modularity in the language. However, it can also
> be shown that it's infeasible to guarantee consistency of modules
> through the language/compile/runtime/packaging stages. This remains a
> very theoretical argument. In fact what we are seeing is the "theory"
> and "promise" of Jigsaw being compared to the reality of OSGi. The
> problem is not the need for modularity, but the promises since the
> beginning of Jigsaw that the Jigsaw project would work within OSGi to
> ensure compatibility. These have been completely empty words - why
> don't you spend a little time researching the Jigsaw/JSR 294
> statements about their intention to "harmonize" what they're doing
> with the OSGi community, and see if any one of them has done anything
> to back up their statements?
>
> One question: if someone says they're going to do something and they
> do not, is pointing that out a fair criticism?
>
> I take very strong exception to the criticism of the OSGi community.
> Having been a member of that community for nearly three years now, I
> can say for sure that it is the most open and welcoming community I've
> ever participated in (including BTW the JCP). I have personally
> reached out to Sun members on several occasions to encourage them to
> participate more actively but they apparently prefer to sit outside
> and throw stones, and somehow manage to convince others who have
> little or no experience with OSGi to do the same.
>
> Eric
> ...
>
> read more »
was a big part of my rant: OSGi folk just piss all over jigsaw without
-EVER- mentioning anything constructive except that tired old bitty of
'There is no point' and 'It will fracture the market'. The podcast
quite clearly explained that jigsaw has overlap with OSGi, but there
are things OSGi can do that jigsaw can't (read: jigsaw is easier in
some respects), *and vice versa* (jigsaw fulfills certain requirements
that OSGi cannot). Hence, there IS a point, and the modularization
(heh) of finding resources means that it won't fracture the market
nearly as much as most OSGi folk think it will.
You say that the OSGi community is very open and welcoming, and yet
your reply is anything but. I've *never* seen anybody involved with
jigsaw throw stones at OSGi. Ever. Quote, please.
On Jun 22, 2:35 pm, Eric <enewco...@gmail.com> wrote:
> I have to say I these strong statements about OSGi are very
> uninformed. Nor does the cleverness of the language improve their
> credibility.
>
> None of the reasons cited are a good reason to invent a new module
> system, i.e. Jigsaw. It would be better for the industry to kill it,
> and the sooner the better:
>
> http://modualrit.blogspot.com/2009/06/kill-project-jigsaw-now-please....
>
> If speed to market is an issue, inventing something new is actually
> slower. Unless of course the argument is that Java is not, and never
> was, a standard but rather a product developed by Sun who can
> therefore do anything they like with it, regardless of any other
> vendor's investment. I have not heard that said before, but perhaps
> that's your position?
>
> OSGi has existed for 10 years, is used in thousands of technologies
> and projects, is mature, widely adopted, and proven to work. Lots of
> people would like new things to become standards, but it's impossible
> to achieve that simply by wishing it to be so. It takes many many
> years for new technologies to become widely adopted. We have two guys
> saying don't worry, we'll take care of all of those external forces by
> ourselves, and get Jigsaw as widely adopted and accepted as OSGi
> already is.
>
> It is also a provable fact that the OSGi Alliance runs an open
> process, and that OSGi folks have participated in JSR 294 from the
> beginning. They would have participated in Jigsaw if they had been
> able to.
>
> Many of the arguments are not in dispute. Everyone acknowledges the
> benefits of including modularity in the language. However, it can also
> be shown that it's infeasible to guarantee consistency of modules
> through the language/compile/runtime/packaging stages. This remains a
> very theoretical argument. In fact what we are seeing is the "theory"
> and "promise" of Jigsaw being compared to the reality of OSGi. The
> problem is not the need for modularity, but the promises since the
> beginning of Jigsaw that the Jigsaw project would work within OSGi to
> ensure compatibility. These have been completely empty words - why
> don't you spend a little time researching the Jigsaw/JSR 294
> statements about their intention to "harmonize" what they're doing
> with the OSGi community, and see if any one of them has done anything
> to back up their statements?
>
> One question: if someone says they're going to do something and they
> do not, is pointing that out a fair criticism?
>
> I take very strong exception to the criticism of the OSGi community.
> Having been a member of that community for nearly three years now, I
> can say for sure that it is the most open and welcoming community I've
> ever participated in (including BTW the JCP). I have personally
> reached out to Sun members on several occasions to encourage them to
> participate more actively but they apparently prefer to sit outside
> and throw stones, and somehow manage to convince others who have
> little or no experience with OSGi to do the same.
>
> Eric
>
> read more »
Jess Holle
Jun 22, 2009, 10:27:22 AM6/22/09
to java...@googlegroups.com
I think one of the most compelling arguments cited was actually *not*
getting necessary changes worked out through the OSGi standards body.
Standards body == slow.
Given that there are clear things OSGi is missing that Jigsaw needs and the non-goal of Jigsaw replacing OSGi, bypassing it makes sense.
There are other things that really gave me pause (e.g. the emphasis on native packaging to the exclusion of cross-platform portable packaging approaches!!!), but by-passing OSGi seems like a non-issue.
--
Jess Holle
P.S. I'd contrast this with by-passing log4j, for instance, where log4j could have easily been extended to do everything Sun had in mind and had no weighty standards body to contend with.
Eric wrote:
Standards body == slow.
Given that there are clear things OSGi is missing that Jigsaw needs and the non-goal of Jigsaw replacing OSGi, bypassing it makes sense.
There are other things that really gave me pause (e.g. the emphasis on native packaging to the exclusion of cross-platform portable packaging approaches!!!), but by-passing OSGi seems like a non-issue.
--
Jess Holle
P.S. I'd contrast this with by-passing log4j, for instance, where log4j could have easily been extended to do everything Sun had in mind and had no weighty standards body to contend with.
Eric wrote:
This time issue is another false argument that attempts to justify incorrect behavior - and I mean incorrect with regard to the Java community. It takes a lot more time to start something from scratch than to work with something that already exists. I don't just mean the development of something, but its adoption as a standard. Unless, of course, that's not what Jigsaw folks intend. Eric On Jun 20, 10:24 pm, Josh Suereth <joshua.suer...@gmail.com> wrote:
Message has been deleted
Message has been deleted
Lloyd Meinholz
Jun 22, 2009, 12:43:25 PM6/22/09
to java...@googlegroups.com
Being a standard doesn't necessarily make it a good thing. Corba, EJB 1 and 2 are standards. Spring and Hibernate even eclipse are defacto standards, but not official standards. Emphasizing OSGI being a standard doesn't help you argument IMO. I also don't agree that retrofitting OSGI to meet the needs of Jigsaw is quicker. It may be, but not necessarily.
As a total outsider to the modularization stuff, I have to say that my experience is that the OSGI supporters that I see appear to be much more irrational than the Jigsaw supporters. That turns me off and I think hurts adoption of this technology. The same kind of community behaviour is one reason I really don't care for RoR. Yes, I could just grow up and ignore the jerks, but why not work with a group that doesn't include them? There are plenty of interesting things to work on.
Lloyd
As a total outsider to the modularization stuff, I have to say that my experience is that the OSGI supporters that I see appear to be much more irrational than the Jigsaw supporters. That turns me off and I think hurts adoption of this technology. The same kind of community behaviour is one reason I really don't care for RoR. Yes, I could just grow up and ignore the jerks, but why not work with a group that doesn't include them? There are plenty of interesting things to work on.
Lloyd
On Mon, Jun 22, 2009 at 10:34 AM, Eric Newcomer <enew...@gmail.com> wrote:
But this is a completely nonsensical argument. Standardization is slow because developing a standard means that you need to get people to buy into it and adopt it. That takes time. There are no shortcuts. The same will have to be true for Jigsaw. If it really gets adopted it will take a long time.
Are you suggesting it doesn't matter whether Eclipse, IBM, Oracle, Progress, etc. adopt it? If it does matter it will take time.
There is no magic in the world that anyone can use to anoint anything a standard. This is a really false argument on its face. You cannot just wish for something to be adopted and have it happen.
That's why I say we are dealing with a false debate here. We are drawn into a comparison of Jigsaw *as it might become* versus OSGi *as it already is*. OSGi is a standard - Jigsaw is not. We can suppose that Jigsaw might become a standard, but can we really say the time it will take for Jigsaw to be as widely adopted as OSGi would be time well spent?
Eric
Message has been deleted
Reinier Zwitserloot
Jun 22, 2009, 5:32:13 PM6/22/09
to The Java Posse
But they do communicate with the OSGi team.
On Jun 22, 7:43 pm, Eric Newcomer <enewco...@gmail.com> wrote:
> No, the point is that Jigsaw proposes to be a standard. OSGi already is
> one, and I don't mean in the academic sense. I mean that it has been widely
> adopted and used. My point is that the Jigsaw folks are talking about their
> effort as if it were already the equal of OSGi, when it is far from it.
>
> I wish I knew what you guys were all talking about with respect to the OSGi
> supporters vs Jigsaw supporters. To me this sounds like the principal
> arriving in the middle of a fight at the schoolyard, and not knowing who
> started it, can only blame each fighter equally.
>
> If we in the OSGi community invite the Jigsaw folks to participate (and Sun
> is definitely a member of OSGi as well as the relevant expert groups), and
> they say they will, but then they don't, and we complain about that, is that
> a valid compliant or not?
>
> Eric
>
> On Mon, Jun 22, 2009 at 12:43 PM, Lloyd Meinholz
> <meinh...@javabilities.com>wrote:
On Jun 22, 7:43 pm, Eric Newcomer <enewco...@gmail.com> wrote:
> No, the point is that Jigsaw proposes to be a standard. OSGi already is
> one, and I don't mean in the academic sense. I mean that it has been widely
> adopted and used. My point is that the Jigsaw folks are talking about their
> effort as if it were already the equal of OSGi, when it is far from it.
>
> I wish I knew what you guys were all talking about with respect to the OSGi
> supporters vs Jigsaw supporters. To me this sounds like the principal
> arriving in the middle of a fight at the schoolyard, and not knowing who
> started it, can only blame each fighter equally.
>
> If we in the OSGi community invite the Jigsaw folks to participate (and Sun
> is definitely a member of OSGi as well as the relevant expert groups), and
> they say they will, but then they don't, and we complain about that, is that
> a valid compliant or not?
>
> Eric
>
> On Mon, Jun 22, 2009 at 12:43 PM, Lloyd Meinholz
> <meinh...@javabilities.com>wrote:
>
> > Being a standard doesn't necessarily make it a good thing. Corba, EJB 1 and
> > 2 are standards. Spring and Hibernate even eclipse are defacto standards,
> > but not official standards. Emphasizing OSGI being a standard doesn't help
> > you argument IMO. I also don't agree that retrofitting OSGI to meet the
> > needs of Jigsaw is quicker. It may be, but not necessarily.
>
> > As a total outsider to the modularization stuff, I have to say that my
> > experience is that the OSGI supporters that I see appear to be much more
> > irrational than the Jigsaw supporters. That turns me off and I think hurts
> > adoption of this technology. The same kind of community behaviour is one
> > reason I really don't care for RoR. Yes, I could just grow up and ignore the
> > jerks, but why not work with a group that doesn't include them? There are
> > plenty of interesting things to work on.
>
> > Lloyd
>
> > Being a standard doesn't necessarily make it a good thing. Corba, EJB 1 and
> > 2 are standards. Spring and Hibernate even eclipse are defacto standards,
> > but not official standards. Emphasizing OSGI being a standard doesn't help
> > you argument IMO. I also don't agree that retrofitting OSGI to meet the
> > needs of Jigsaw is quicker. It may be, but not necessarily.
>
> > As a total outsider to the modularization stuff, I have to say that my
> > experience is that the OSGI supporters that I see appear to be much more
> > irrational than the Jigsaw supporters. That turns me off and I think hurts
> > adoption of this technology. The same kind of community behaviour is one
> > reason I really don't care for RoR. Yes, I could just grow up and ignore the
> > jerks, but why not work with a group that doesn't include them? There are
> > plenty of interesting things to work on.
>
> > Lloyd
>
Eric Newcomer
Jun 22, 2009, 5:38:44 PM6/22/09
to java...@googlegroups.com
Yes, that's what they keep saying. I'm sure they mean that they speak when they see each other in the hallways at Java One, or after a presentation. Or something like that.
But there is no participation in any OSGi expert group by Jigsaw folks. And there is no Jigsaw JSR for anyone else to participate in.
The Jigsaw folks can say anything they want to anyone informally - and they do say a lot of things - but there is no formal exchange of ideas and proposals. That is the point. Without that, there's no way to bring things together.
Eric
But there is no participation in any OSGi expert group by Jigsaw folks. And there is no Jigsaw JSR for anyone else to participate in.
The Jigsaw folks can say anything they want to anyone informally - and they do say a lot of things - but there is no formal exchange of ideas and proposals. That is the point. Without that, there's no way to bring things together.
Eric
Jess Holle
Jun 22, 2009, 5:51:22 PM6/22/09
to java...@googlegroups.com
All of that formal involvement takes a hell of a lot of time.
As I see it they only had 2 options:
Informal conversations and discourse around approach #2, followed by an attempt to merge the fork back into the main implementation and standard afterwards is about all you possibly could have hoped for. The fact that they took path #1 likely indicates a judgement call that hacking an OSGi implementation down to the subset they actually needed, quality checking every bit thereof, and then adding what it was missing would take longer than just writing what they needed.
I can't really disagree with the decision.
--
Jess Holle
As I see it they only had 2 options:
- The path they took
- Grab an open-source OSGi implementation whose implementation and
license were amenable and bundle and fork it as needed
Informal conversations and discourse around approach #2, followed by an attempt to merge the fork back into the main implementation and standard afterwards is about all you possibly could have hoped for. The fact that they took path #1 likely indicates a judgement call that hacking an OSGi implementation down to the subset they actually needed, quality checking every bit thereof, and then adding what it was missing would take longer than just writing what they needed.
I can't really disagree with the decision.
--
Jess Holle
Eric Newcomer
Jun 22, 2009, 6:33:28 PM6/22/09
to java...@googlegroups.com
And now this conversation is starting to go in circles... There is no shortcut to becoming a standard, which is what Jigsaw is aiming for. Unless you think it doesn't matter whether any other Java vendors support it?
This is also complete supposition on your part. Although I admit it sounds like a reasonable guess, it does not ring true mostly because OSGi is not "big or bloated" -- it is modular, and you can easily subset it.
Now look at this from the other side. Jigsaw is all done - for some reason it had to be done in a complete hurry, never mind the requirement for modularity having been known for years and years, there was some reason for a rush all of a sudden - and now the other Java vendors have to decide whether or not to recode their OSGi implementations to use it. How long will that take? Have we really saved any time?
There are no shortcuts to the adoption of a modularity standard. Everyone has to be involved in the decision. In this case they are not - none of the other vendors were - so we may have a "quick success" with an implementation in the JDK, but then a long slow process while everyone else decides whether or not to adopt it. And this leaves out another important point, which is that the other vendors probably have additional requirements, and will need to make some changes.
Eric
This is also complete supposition on your part. Although I admit it sounds like a reasonable guess, it does not ring true mostly because OSGi is not "big or bloated" -- it is modular, and you can easily subset it.
Now look at this from the other side. Jigsaw is all done - for some reason it had to be done in a complete hurry, never mind the requirement for modularity having been known for years and years, there was some reason for a rush all of a sudden - and now the other Java vendors have to decide whether or not to recode their OSGi implementations to use it. How long will that take? Have we really saved any time?
There are no shortcuts to the adoption of a modularity standard. Everyone has to be involved in the decision. In this case they are not - none of the other vendors were - so we may have a "quick success" with an implementation in the JDK, but then a long slow process while everyone else decides whether or not to adopt it. And this leaves out another important point, which is that the other vendors probably have additional requirements, and will need to make some changes.
Eric
Reinier Zwitserloot
Jun 22, 2009, 10:22:24 PM6/22/09
to The Java Posse
So, if I understand you correctly, Eric:
1) jigsaw's reasoning that OSGi would have been too slow is specious
and downright faulty - from which I can conclude you presume to say
that OSGi's design-by-committee aspects aren't a horrid mess of
bureaucracy and insistence on officiousness, and
2) Sun's open chats with the osgi alliance, as talked about by Peter
Krienz here: http://www.osgi.org/blog/2008/12/project-jigsaw.html aren
too informal.
Of course there is a shortcut in making a standard. You make something
good, and hope the people will flock to it. It helps if you are
building the framework/tool/library/whatever because you have a
specific itch that needs scratching, and any use by others is bonus.
Huh, that sounds kinda familiar, doesn't it? As a rule, designs by
committee are used begrudgingly by that committee, foisted on others
by way of expensive consulting contracts, and despised like the plague
by everyone else, for sucking so much. Not always, and OSGi's been far
less of a disaster than must committee designed hoopla, but you're
touting this 'design by committee' horn as if it's a _good_ thing. Uh,
no.
Let me put it differently: I can take pretty much your entire
argument, grep for 'OSGi', replace it with 'EJB 2.0', and the crux of
your argument would be equally 'valid'. I think we're all happy EJB
2.0 was taken out back and shot. Now, OSGi isn't nearly that bad, but
nevertheless, it shows that your arguments are just not very
convincing.
On Jun 22, 11:38 pm, Eric Newcomer <enewco...@gmail.com> wrote:
> Yes, that's what they keep saying. I'm sure they mean that they speak when
> they see each other in the hallways at Java One, or after a presentation. Or
> something like that.
>
> But there is no participation in any OSGi expert group by Jigsaw folks. And
> there is no Jigsaw JSR for anyone else to participate in.
>
> The Jigsaw folks can say anything they want to anyone informally - and they
> do say a lot of things - but there is no formal exchange of ideas and
> proposals. That is the point. Without that, there's no way to bring things
> together.
>
> Eric
>
1) jigsaw's reasoning that OSGi would have been too slow is specious
and downright faulty - from which I can conclude you presume to say
that OSGi's design-by-committee aspects aren't a horrid mess of
bureaucracy and insistence on officiousness, and
2) Sun's open chats with the osgi alliance, as talked about by Peter
Krienz here: http://www.osgi.org/blog/2008/12/project-jigsaw.html aren
too informal.
Of course there is a shortcut in making a standard. You make something
good, and hope the people will flock to it. It helps if you are
building the framework/tool/library/whatever because you have a
specific itch that needs scratching, and any use by others is bonus.
Huh, that sounds kinda familiar, doesn't it? As a rule, designs by
committee are used begrudgingly by that committee, foisted on others
by way of expensive consulting contracts, and despised like the plague
by everyone else, for sucking so much. Not always, and OSGi's been far
less of a disaster than must committee designed hoopla, but you're
touting this 'design by committee' horn as if it's a _good_ thing. Uh,
no.
Let me put it differently: I can take pretty much your entire
argument, grep for 'OSGi', replace it with 'EJB 2.0', and the crux of
your argument would be equally 'valid'. I think we're all happy EJB
2.0 was taken out back and shot. Now, OSGi isn't nearly that bad, but
nevertheless, it shows that your arguments are just not very
convincing.
On Jun 22, 11:38 pm, Eric Newcomer <enewco...@gmail.com> wrote:
> Yes, that's what they keep saying. I'm sure they mean that they speak when
> they see each other in the hallways at Java One, or after a presentation. Or
> something like that.
>
> But there is no participation in any OSGi expert group by Jigsaw folks. And
> there is no Jigsaw JSR for anyone else to participate in.
>
> The Jigsaw folks can say anything they want to anyone informally - and they
> do say a lot of things - but there is no formal exchange of ideas and
> proposals. That is the point. Without that, there's no way to bring things
> together.
>
> Eric
>
Message has been deleted
Vince O'Sullivan
Jun 23, 2009, 6:20:33 PM6/23/09
to The Java Posse
After reading this rather depressing thread, I can't help but think
"Java is dead.".
Time to get out the Scala book.
"Java is dead.".
Time to get out the Scala book.
Steve
Jun 24, 2009, 5:09:35 AM6/24/09
to The Java Posse
Vince O'Sullivan
Jun 24, 2009, 8:04:18 AM6/24/09
to The Java Posse
Come back VB6. All is forgiven!
Steve
Jun 24, 2009, 8:55:52 AM6/24/09
to The Java Posse
On Jun 24, 10:04 pm, "Vince O'Sullivan" <vjosulli...@gmail.com> wrote:
> Come back VB6. All is forgiven!
>
Please, there's been enough belligerence in this thread, that's just
> Come back VB6. All is forgiven!
>
taking it too far.
phil swenson
Jun 24, 2009, 12:39:06 PM6/24/09
to The Java Posse
> Of course there is a shortcut in making a standard. You make something
> good, and hope the people will flock to it. It helps if you are
> building the framework/tool/library/whatever because you have a
> specific itch that needs scratching, and any use by others is bonus.
> Huh, that sounds kinda familiar, doesn't it? As a rule, designs by
> committee are used begrudgingly by that committee, foisted on others
> by way of expensive consulting contracts, and despised like the plague
> by everyone else, for sucking so much. Not always, and OSGi's been far
> less of a disaster than must committee designed hoopla, but you're
> touting this 'design by committee' horn as if it's a _good_ thing. Uh,
> no.
well said. Standards and committees don't tend to lead to the best
> good, and hope the people will flock to it. It helps if you are
> building the framework/tool/library/whatever because you have a
> specific itch that needs scratching, and any use by others is bonus.
> Huh, that sounds kinda familiar, doesn't it? As a rule, designs by
> committee are used begrudgingly by that committee, foisted on others
> by way of expensive consulting contracts, and despised like the plague
> by everyone else, for sucking so much. Not always, and OSGi's been far
> less of a disaster than must committee designed hoopla, but you're
> touting this 'design by committee' horn as if it's a _good_ thing. Uh,
> no.
solutions. The best solutions tend to be reached by a small number of
very smart people (witness RoR) with no overhead (standards,
committees, bureaucracy).
After listening to the podcast, my guess is that the business decided
that in order to make JavaFX competitive Sun needed to make modularity
a priority (finally!). And they didn't want to be constrained by
outside influences as the time-line wouldn't be predictable if others
were involved in the decision/design process. And in the OSGi option,
the end result wouldn't be guaranteed to solve the problem (modularity
of the JVM).
I can understand why the OSGi advocates are pissed though. These
people have a lot invested in the technology and now it's threatened.
My position is: let the best technology win. I don't see a lot of
discussion about which approach has the best technology.
Message has been deleted
Michael Neale
Jun 24, 2009, 9:28:48 PM6/24/09
to The Java Posse
Christian Catchpole
Jun 24, 2009, 9:49:40 PM6/24/09
to The Java Posse
so... what colour did they choose?
Michael Neale
Jun 25, 2009, 12:27:07 AM6/25/09
to The Java Posse
The beige, the off-white, bone etc...
On Jun 25, 11:49 am, Christian Catchpole <christ...@catchpole.net>
wrote:
On Jun 25, 11:49 am, Christian Catchpole <christ...@catchpole.net>
wrote:
Joe Nuxoll (Java Posse)
Jun 25, 2009, 1:34:36 AM6/25/09
to The Java Posse
I like turtles.
On Jun 22, 3:33 pm, Eric Newcomer <enewco...@gmail.com> wrote:
> And now this conversation is starting to go in circles... There is no
> shortcut to becoming a standard, which is what Jigsaw is aiming for. Unless
> you think it doesn't matter whether any other Java vendors support it?
>
> This is also complete supposition on your part. Although I admit it sounds
> like a reasonable guess, it does not ring true mostly because OSGi is not
> "big or bloated" -- it is modular, and you can easily subset it.
>
> Now look at this from the other side. Jigsaw is all done - for some reason
> it had to be done in a complete hurry, never mind the requirement for
> modularity having been known for years and years, there was some reason for
> a rush all of a sudden - and now the other Java vendors have to decide
> whether or not to recode their OSGi implementations to use it. How long
> will that take? Have we really saved any time?
>
> There are no shortcuts to the adoption of a modularity standard. Everyone
> has to be involved in the decision. In this case they are not - none of the
> other vendors were - so we may have a "quick success" with an implementation
> in the JDK, but then a long slow process while everyone else decides whether
> or not to adopt it. And this leaves out another important point, which is
> that the other vendors probably have additional requirements, and will need
> to make some changes.
>
> Eric
>
>
>
> On Mon, Jun 22, 2009 at 5:51 PM, Jess Holle <je...@ptc.com> wrote:
> > All of that formal involvement takes a hell of a lot of time.
>
> > As I see it they only had 2 options:
>
> > 1. The path they took
> > 2. Grab an open-source OSGi implementation whose implementation and
> ...
>
> read more »
On Jun 22, 3:33 pm, Eric Newcomer <enewco...@gmail.com> wrote:
> And now this conversation is starting to go in circles... There is no
> shortcut to becoming a standard, which is what Jigsaw is aiming for. Unless
> you think it doesn't matter whether any other Java vendors support it?
>
> This is also complete supposition on your part. Although I admit it sounds
> like a reasonable guess, it does not ring true mostly because OSGi is not
> "big or bloated" -- it is modular, and you can easily subset it.
>
> Now look at this from the other side. Jigsaw is all done - for some reason
> it had to be done in a complete hurry, never mind the requirement for
> modularity having been known for years and years, there was some reason for
> a rush all of a sudden - and now the other Java vendors have to decide
> whether or not to recode their OSGi implementations to use it. How long
> will that take? Have we really saved any time?
>
> There are no shortcuts to the adoption of a modularity standard. Everyone
> has to be involved in the decision. In this case they are not - none of the
> other vendors were - so we may have a "quick success" with an implementation
> in the JDK, but then a long slow process while everyone else decides whether
> or not to adopt it. And this leaves out another important point, which is
> that the other vendors probably have additional requirements, and will need
> to make some changes.
>
> Eric
>
>
>
> On Mon, Jun 22, 2009 at 5:51 PM, Jess Holle <je...@ptc.com> wrote:
> > All of that formal involvement takes a hell of a lot of time.
>
> > As I see it they only had 2 options:
>
> > 2. Grab an open-source OSGi implementation whose implementation and
> > license were amenable and bundle and fork it as needed
>
> > Working with standards bodies in this context is a recipe for wasting
> > countless hours of engineer's time and countless schedule delays.
>
> > Informal conversations and discourse around approach #2, followed by an
> > attempt to merge the fork back into the main implementation and standard
> > afterwards is about all you possibly could have hoped for. The fact that
> > they took path #1 likely indicates a judgement call that hacking an OSGi
> > implementation down to the subset they actually needed, quality checking
> > every bit thereof, and then adding what it was missing would take longer
> > than just writing what they needed.
>
> > I can't really disagree with the decision.
>
> > --
> > Jess Holle
>
> > Eric Newcomer wrote:
>
> > Yes, that's what they keep saying. I'm sure they mean that they speak when
> > they see each other in the hallways at Java One, or after a presentation. Or
> > something like that.
>
> > But there is no participation in any OSGi expert group by Jigsaw folks. And
> > there is no Jigsaw JSR for anyone else to participate in.
>
> > The Jigsaw folks can say anything they want to anyone informally - and they
> > do say a lot of things - but there is no formal exchange of ideas and
> > proposals. That is the point. Without that, there's no way to bring things
> > together.
>
> > Eric
>
>
> > Working with standards bodies in this context is a recipe for wasting
> > countless hours of engineer's time and countless schedule delays.
>
> > Informal conversations and discourse around approach #2, followed by an
> > attempt to merge the fork back into the main implementation and standard
> > afterwards is about all you possibly could have hoped for. The fact that
> > they took path #1 likely indicates a judgement call that hacking an OSGi
> > implementation down to the subset they actually needed, quality checking
> > every bit thereof, and then adding what it was missing would take longer
> > than just writing what they needed.
>
> > I can't really disagree with the decision.
>
> > --
> > Jess Holle
>
> > Eric Newcomer wrote:
>
> > Yes, that's what they keep saying. I'm sure they mean that they speak when
> > they see each other in the hallways at Java One, or after a presentation. Or
> > something like that.
>
> > But there is no participation in any OSGi expert group by Jigsaw folks. And
> > there is no Jigsaw JSR for anyone else to participate in.
>
> > The Jigsaw folks can say anything they want to anyone informally - and they
> > do say a lot of things - but there is no formal exchange of ideas and
> > proposals. That is the point. Without that, there's no way to bring things
> > together.
>
> > Eric
>
>
> read more »
Steven Herod
Jun 25, 2009, 6:37:24 AM6/25/09
to The Java Posse
What ever the color was, it was Marvelous
(I reckon no-one knows what we're talking about.)
(I reckon no-one knows what we're talking about.)
Vince O'Sullivan
Jun 25, 2009, 9:19:27 AM6/25/09
to The Java Posse
On Jun 25, 11:37 am, Steven Herod <steven.he...@gmail.com> wrote:
> What ever the color was, it was Marvelous
I disagree and I blame you, too!> What ever the color was, it was Marvelous
Jan Goyvaerts
Jun 25, 2009, 9:22:05 AM6/25/09
to java...@googlegroups.com
FINALLY a constructive conversation on the subject. About time if you ask me. :-D
Steve
Jun 26, 2009, 3:04:53 AM6/26/09
to The Java Posse
On Jun 25, 2:39 am, phil swenson <phil.swen...@gmail.com> wrote:
>
> My position is: let the best technology win. I don't see a lot of
> discussion about which approach has the best technology.
Well "best" depends on what criteria you are using to evaluate the
>
> My position is: let the best technology win. I don't see a lot of
> discussion about which approach has the best technology.
choices. If best means "more features" or "is more mature" then OSGi
is in front, if best means "makes it easier to retrofit modularity
onto a code-base not originally designed with deployment modularity in
mind" then Jigsaw might be a better option. Which "best" is best for
application developers building new apps is the real question.
Either way, I would normally agree with letting the best technology
win, however when one camp can embed their solution into the platform
and the other cannot then I would suggest that the playing field is
not entirely level (anyone heard of Internet Explorer?).
Steven Herod
Jun 26, 2009, 5:32:54 AM6/26/09
to The Java Posse
> I disagree and I blame you, too!
Augusto
Jun 26, 2009, 6:40:36 PM6/26/09
to The Java Posse
This thread is hilarious, who thought modularity could be such a
controversial topic.
Somebody mentioned this, it seems the driver here is JavaFX. Making
the VM smaller, and starting faster and that is why this is needed by
Java 7. With that in mind, it seems reasonable that the Sun folks want
to integrate this sooner rather than later ... and I can see why
working with OSGi might not meet their schedules.
The technical argument has not been clearly made. I couldn't really
find a written document that presented all the technical issues for
choosing one over the other. Maybe that should have been a topic at
the BOF (our fault, maybe we didn't ask for this) or some session at
the conference. To that end, I'm almost tempted to do another follow
up to my original blog post listing the technical arguments so that
they're clearly enumerated. At least in the podcast some of these were
discussed, but it merits writing them down *somewhere*.
One thing, in my blog post;
http://sellmic.com/blog/2009/06/11/classpath-hell-just-froze-over/
It turns out Jigsaw might not solve this problem;
http://sellmic.com/blog/wp-content/uploads/2009/06/module_depencies.jpg
-----
A module system can solve the classpath/jar hell problem by leveraging
the previously mentioned features in order to allow an application to
use the right versions of the set of libraries it requires. In the
diagram shown here, we have an APP module that depends on the A, B and
C modules. But module C also depends on B, however this dependency is
to a different version of B than the one APP needs. A useful module
system would then allow us to have 2 versions of the B module, with
the compatible version and implementation visible to the appropriate
modules (in this case APP and C).
-----
This is a question I asked at the Q&A, but I wasn't sure if I
explained it well. Mark said something to the effect that Jigasaw sort
of supports this with "application contexts" but not in the same
application. I forgot about that (because it wasn't clear), but I got
an email from somebody clarifying it a bit.
This is a big deal to me, because I thought this was a fundamental
issue that a module system needs to solve. I shouldn't have to worry
about different modules using different versions of another library
we're both using at the same time, and this is an issue that OSGi has
already solved.
The problem is of course that Jigsaw is mostly aimed at modularizing
the JDK, but as an application module system ... its still not solving
some of the fundamental problems that are expected to be addressed by
it.
controversial topic.
Somebody mentioned this, it seems the driver here is JavaFX. Making
the VM smaller, and starting faster and that is why this is needed by
Java 7. With that in mind, it seems reasonable that the Sun folks want
to integrate this sooner rather than later ... and I can see why
working with OSGi might not meet their schedules.
The technical argument has not been clearly made. I couldn't really
find a written document that presented all the technical issues for
choosing one over the other. Maybe that should have been a topic at
the BOF (our fault, maybe we didn't ask for this) or some session at
the conference. To that end, I'm almost tempted to do another follow
up to my original blog post listing the technical arguments so that
they're clearly enumerated. At least in the podcast some of these were
discussed, but it merits writing them down *somewhere*.
One thing, in my blog post;
http://sellmic.com/blog/2009/06/11/classpath-hell-just-froze-over/
It turns out Jigsaw might not solve this problem;
http://sellmic.com/blog/wp-content/uploads/2009/06/module_depencies.jpg
-----
A module system can solve the classpath/jar hell problem by leveraging
the previously mentioned features in order to allow an application to
use the right versions of the set of libraries it requires. In the
diagram shown here, we have an APP module that depends on the A, B and
C modules. But module C also depends on B, however this dependency is
to a different version of B than the one APP needs. A useful module
system would then allow us to have 2 versions of the B module, with
the compatible version and implementation visible to the appropriate
modules (in this case APP and C).
-----
This is a question I asked at the Q&A, but I wasn't sure if I
explained it well. Mark said something to the effect that Jigasaw sort
of supports this with "application contexts" but not in the same
application. I forgot about that (because it wasn't clear), but I got
an email from somebody clarifying it a bit.
This is a big deal to me, because I thought this was a fundamental
issue that a module system needs to solve. I shouldn't have to worry
about different modules using different versions of another library
we're both using at the same time, and this is an issue that OSGi has
already solved.
The problem is of course that Jigsaw is mostly aimed at modularizing
the JDK, but as an application module system ... its still not solving
some of the fundamental problems that are expected to be addressed by
it.
Dick Wall
Jun 26, 2009, 7:18:49 PM6/26/09
to The Java Posse
Cross posted from the forked thread about the OSGi vs. Jigsaw vs. The
Java Posse as I believe it effects both discussions.
http://modualrit.blogspot.com/2009/06/jigsaw-posse.html
Wow - what a report. I really couldn't let this one go by without
some
comment.
Some choice pieces from the article:
"defend Jigsaw scathing, cynical, and even insulting comments about
OSGi folks"
From everything (and I mean everything) I have observed so far, the
scathing comes primarily from the OSGi followers, and not the main
camp either, but a noisy group of people who seem to have injected
themselves into the discussion. I certainly didn't pick up anything
scathing in Mark or Alex's answers, nor in all fairness did I pick up
anything from Peter Kriens or B.J. Hargrave when we interviewed them.
As far as I can see, the key players in this game have been
professional throughout. Opinions not matching your own do not
constitute scathing cynicism, or insults, they are merely differing
opinions.
"At first I figured the reason was that the Java Posse is not
actually
a technical forum, but is popular for its entertainment value,
instead. But some of the other threads seemed to treat technical
topics seriously"
You bet - I believe we have amassed a fantastic group of energetic
people who are passionate about all aspects of the Java language,
platform and community. Eric, I really believe you should reserve
such
judgment until you have been a member of the forums a little longer
and joined in on some other threads than Jigsaw/OSGi. I would also
point out that your comments about the forums not being technical but
only for entertainment is a little insulting to the people here,
Again
- it's regrettable if not everyone sees it your way, but really isn't
that just an opportunity to learn from others.
"Finally it occurred to me that the Java Posse is just probably more
of a "lap dog" than a "watch dog""
Right, this is the line that prompted the response, and respond I
will. Firstly, you seem to be claiming insults, scathing and cynicism
from Jigsaw (and us, and the forums), but I believe we have the best
example of all three right here. I am an engineer with 20 years of
experience, I am nobody's lapdog, nor are Carl, Joe and Tor I can
assure you. In fact these are three of the finest professionals I
have
ever had the pleasure to work with - why do you suppose I wanted to
do
a podcast with them in the first place?
I really hope you can back up your statement here. What is it based
on? We do not accept sponsorship (Atlassian beer-for-events
awesomeness aside - but that is the only thing and would anyone
serious begrudge our live audience members that)? I also would point
out that just a few weeks before the Jigsaw interview, we did a
similar interview with Peter and BJ for OSGi. Do you really believe
that it was not fair and balanced to let Mark and Alex respond to
that
criticism (which, as I have mentioned, seemed professional and honest
from both sides). Also, if you really believe we influence what ~3000
developers on this group think, I believe you have overestimated our
reach. The Java Posse Google group is a fantastic discussion forum,
and one of the things I am proudest of from the podcast, but I think
that most people here have made up their own mind on things, and if
you are finding resistance to your "one true way" perhaps that should
be significant.
Thirdly, if you really believe we are "not biting the hand that feeds
us" to get the "scoop" on news or people to interview, I would hope
that common sense would indicate otherwise. Long gone are the days
were we needed to beg for interviews, these days (seriously) it is
all
I can do to stay up to date with the requests (sorry folks, I do get
backed up on this stuff some times because my real job gets in the
way). I believe some of this has come from the fact that we do not
practice gotcha tactics, try and screw people over or put words in
their mouths. We remember who's interview it is and let them have
their say.
I am really disappointed that you would come out of the gate swinging
like this. I believe it doesn't show your cause in a good light
either
- such animosity towards people rarely makes friends. I hope you hang
around long enough to see the value in the community we have built
here, and maybe to work out that we are in fact nobody's lapdog.
Cheers
Dick
Java Posse as I believe it effects both discussions.
http://modualrit.blogspot.com/2009/06/jigsaw-posse.html
Wow - what a report. I really couldn't let this one go by without
some
comment.
Some choice pieces from the article:
"defend Jigsaw scathing, cynical, and even insulting comments about
OSGi folks"
From everything (and I mean everything) I have observed so far, the
scathing comes primarily from the OSGi followers, and not the main
camp either, but a noisy group of people who seem to have injected
themselves into the discussion. I certainly didn't pick up anything
scathing in Mark or Alex's answers, nor in all fairness did I pick up
anything from Peter Kriens or B.J. Hargrave when we interviewed them.
As far as I can see, the key players in this game have been
professional throughout. Opinions not matching your own do not
constitute scathing cynicism, or insults, they are merely differing
opinions.
"At first I figured the reason was that the Java Posse is not
actually
a technical forum, but is popular for its entertainment value,
instead. But some of the other threads seemed to treat technical
topics seriously"
You bet - I believe we have amassed a fantastic group of energetic
people who are passionate about all aspects of the Java language,
platform and community. Eric, I really believe you should reserve
such
judgment until you have been a member of the forums a little longer
and joined in on some other threads than Jigsaw/OSGi. I would also
point out that your comments about the forums not being technical but
only for entertainment is a little insulting to the people here,
Again
- it's regrettable if not everyone sees it your way, but really isn't
that just an opportunity to learn from others.
"Finally it occurred to me that the Java Posse is just probably more
of a "lap dog" than a "watch dog""
Right, this is the line that prompted the response, and respond I
will. Firstly, you seem to be claiming insults, scathing and cynicism
from Jigsaw (and us, and the forums), but I believe we have the best
example of all three right here. I am an engineer with 20 years of
experience, I am nobody's lapdog, nor are Carl, Joe and Tor I can
assure you. In fact these are three of the finest professionals I
have
ever had the pleasure to work with - why do you suppose I wanted to
do
a podcast with them in the first place?
I really hope you can back up your statement here. What is it based
on? We do not accept sponsorship (Atlassian beer-for-events
awesomeness aside - but that is the only thing and would anyone
serious begrudge our live audience members that)? I also would point
out that just a few weeks before the Jigsaw interview, we did a
similar interview with Peter and BJ for OSGi. Do you really believe
that it was not fair and balanced to let Mark and Alex respond to
that
criticism (which, as I have mentioned, seemed professional and honest
from both sides). Also, if you really believe we influence what ~3000
developers on this group think, I believe you have overestimated our
reach. The Java Posse Google group is a fantastic discussion forum,
and one of the things I am proudest of from the podcast, but I think
that most people here have made up their own mind on things, and if
you are finding resistance to your "one true way" perhaps that should
be significant.
Thirdly, if you really believe we are "not biting the hand that feeds
us" to get the "scoop" on news or people to interview, I would hope
that common sense would indicate otherwise. Long gone are the days
were we needed to beg for interviews, these days (seriously) it is
all
I can do to stay up to date with the requests (sorry folks, I do get
backed up on this stuff some times because my real job gets in the
way). I believe some of this has come from the fact that we do not
practice gotcha tactics, try and screw people over or put words in
their mouths. We remember who's interview it is and let them have
their say.
I am really disappointed that you would come out of the gate swinging
like this. I believe it doesn't show your cause in a good light
either
- such animosity towards people rarely makes friends. I hope you hang
around long enough to see the value in the community we have built
here, and maybe to work out that we are in fact nobody's lapdog.
Cheers
Dick
Frederic Simon
Jun 27, 2009, 2:57:32 AM6/27/09
to java...@googlegroups.com
"This thread is hilarious, who thought modularity could be such a
controversial topic." :D
Throwing modules at each other can hurt!
Throwing modules at each other can hurt!
--
JFrog Ltd
5 Habonim st., P.O.Box 8187
Netanya, Israel 42504.
Tel: +972 9 8941444
Fax: +972 9 8659977
http://www.jfrog.org/
http://freddy33.blogspot.com/
http://nothingisinfinite.blogspot.com/
JFrog Ltd
5 Habonim st., P.O.Box 8187
Netanya, Israel 42504.
Tel: +972 9 8941444
Fax: +972 9 8659977
http://www.jfrog.org/
http://freddy33.blogspot.com/
http://nothingisinfinite.blogspot.com/
Augusto
Jun 27, 2009, 4:14:28 PM6/27/09
to The Java Posse
On Jun 27, 2:57 am, Frederic Simon <frederic.si...@gmail.com> wrote:
> Throwing modules at each other can hurt!
Indeed it can.
> Throwing modules at each other can hurt!
BTW, I'm still a bit unclear on Jigsaw supporting different versions
of the same module/library running at the same time in an application.
If anybody else knows a bit more detail about this, please feel free
to pass some of the information. I've gotten a couple of explications
but its not super clear to me yet, and this it seems to me is an
important feature for modularity in applications (not the JDK).
(or if discussions on jigsaw are done here, based on Dick's request, I
guess you can send me email or post another message on the blog)
Thanks!
Dick Wall
Jun 27, 2009, 6:36:07 PM6/27/09
to The Java Posse
My comments should not affect the natural flow of discussion here, we
do not control what goes on this forum (we only block spam, everything
else goes through). Please, please please continue, hopefully we can
all do so with professionalism though ;-).
Cheers
Dick
do not control what goes on this forum (we only block spam, everything
else goes through). Please, please please continue, hopefully we can
all do so with professionalism though ;-).
Cheers
Dick
Reply all
Reply to author
Forward
0 new messages