No-Fluff-Just-Stuff founder, Jay Zimmerman, likes to refer to what he
calls the WOO factor - window of opportunity - when talking about the
dynamics of our software development industry.
For me, Adobe Flex is a case in point of the WOO factor that he talks
about. It's a technology that was ready and in position at the right
time to become a dominant RIA solution. In contrast Java was caught
with nothing to show in the RIA space. It missed the WOO.
Right now, I have a server-side project that will be built on OSGi.
It's here today, has a proven track record (Eclipse), and solves the
problems of project size scalability that we need to grapple with over
product life time.
Once again, just as EJB3 missed the WOO and has been eclipsed by
Spring Framework, whatever standard that Sun will end up backing via a
JSR to address this space will miss the WOO.
Why am I writing this as though I'm lamenting a sad development? I
guess that's a good question. There's really nothing to be down about.
Great software solutions on the Java platform exist outside of JSR
land. Indeed, maybe the very best software used in Java circles has
been the non JSR stuff.
In coming to the Java community I've never had a problem sidestepping
the nonsense being peddled and instead adopted what made sense. With
JEE I completely ignored session and entity beans and just used JMS
MDBs and Hibernate. So in 2003/2004 I built a distributed system
system on principals that the SOA dudes are all crowing about now.
More recently I've completely ignored MVC web frameworks on the server-
side and instead went with RIA + SOA where MVC is completely done on
the client-side. (Doing MVC on the server-side in defiance of the
Fallacies of Distributed Computing was wrong headed from the get go.)
So here we stand today poised to fish or cut bait on this matter of
large scale SOA-based development on the server-side - and we badly
need a modularity solution for Java.
This is the moment of the WOO and here stands OSGi.
----- Original Message -----
From: javaposse@googlegroups.com <javaposse@googlegroups.com>
To: The Java Posse <javaposse@googlegroups.com>
Sent: Fri Jan 25 00:22:39 2008
Subject: [The Java Posse] OSGi on the Server Side and the matter of the WOO
No-Fluff-Just-Stuff founder, Jay Zimmerman, likes to refer to what he
calls the WOO factor - window of opportunity - when talking about the
dynamics of our software development industry.
For me, Adobe Flex is a case in point of the WOO factor that he talks
about. It's a technology that was ready and in position at the right
time to become a dominant RIA solution. In contrast Java was caught
with nothing to show in the RIA space. It missed the WOO.
Right now, I have a server-side project that will be built on OSGi.
It's here today, has a proven track record (Eclipse), and solves the
problems of project size scalability that we need to grapple with over
product life time.
Once again, just as EJB3 missed the WOO and has been eclipsed by
Spring Framework, whatever standard that Sun will end up backing via a
JSR to address this space will miss the WOO.
Why am I writing this as though I'm lamenting a sad development? I
guess that's a good question. There's really nothing to be down about.
Great software solutions on the Java platform exist outside of JSR
land. Indeed, maybe the very best software used in Java circles has
been the non JSR stuff.
In coming to the Java community I've never had a problem sidestepping
the nonsense being peddled and instead adopted what made sense. With
JEE I completely ignored session and entity beans and just used JMS
MDBs and Hibernate. So in 2003/2004 I built a distributed system
system on principals that the SOA dudes are all crowing about now.
More recently I've completely ignored MVC web frameworks on the server-
side and instead went with RIA + SOA where MVC is completely done on
the client-side. (Doing MVC on the server-side in defiance of the
Fallacies of Distributed Computing was wrong headed from the get go.)
So here we stand today poised to fish or cut bait on this matter of
large scale SOA-based development on the server-side - and we badly
need a modularity solution for Java.
This is the moment of the WOO and here stands OSGi.
"What's new, and very much in the cards for 2008 is Eclipse moving
into the server side, into an even more tooling and framework position
for the Java world."
"At the core of their strategy is OSGi"
Then there is the Spring Framework itself that is making an OSGi move
with a v1.0 release:
* IBM WebSphere Application Server is already based on an OSGi runtime
(specifically Eclipse Equinox).
* BEA committed a while back to developing ALL of their new products
on OSGi. In their marketing literature they refer to the BEA "micro
Services Architecture" or mSA, which is essentially OSGi plus some
utilities on top. An internal source at BEA told me that eventually
their flagship product, WebLogic Application Server, would probably be
converted to OSGi.
* BEA's strategy is unlikely to change after the acquisition by
Oracle, since Oracle are also strong supporters of OSGi. They are on
the OSGi Enterprise Expert Group, and their EclipseLink product offers
persistence services for OSGi.
* JBoss uses OSGi in their ESB platform. Another open source ESB,
Mule, is aiming to convert to OSGi in a future version.
* As you noted, SpringSource/Interface21 are supporters. In his blog,
Rod Johnson stated his intention to push the JEE 6 expert group
towards the use of OSGi for delivering modularity in JEE.
* Last year, even Sun joined the OSGi Alliance. In fact they RE-
joined, since they were founding members.
However, I wouldn't say that these developments are negative for the
"JSR crowd". Remember that OSGi R4.1 has been standardised under the
JCP via JSR 291 (for Java SE) and JSR 232 (for Java ME). OSGi itself
began life as JSR 008.
Regards
Neil
On Jan 26, 1:14 am, RogerV <rog...@qwest.net> wrote:
> Intimations that the WOO for OSGi may indeed be 2008:
> Michael Coté, an industry analyst with RedMonk, reports that the
> Eclipse foundation is targeting moving OSGi into the server
> application environment:
> "What's new, and very much in the cards for 2008 is Eclipse moving
> into the server side, into an even more tooling and framework position
> for the Java world."
> "At the core of their strategy is OSGi"
> Then there is the Spring Framework itself that is making an OSGi move
> with a v1.0 release:
On Jan 26, 12:55 am, Neil Bartlett <njbartl...@gmail.com> wrote:
> However, I wouldn't say that these developments are negative for the
> "JSR crowd". Remember that OSGi R4.1 has been standardised under the
> JCP via JSR 291 (for Java SE) and JSR 232 (for Java ME). OSGi itself
> began life as JSR 008.
I rather suspected (or vaguely remembered) that OSGi had some
associated JSR(s). These days, though, doesn't look like OSGi fate
necessarily rest on the glacial JSR process.
It's now coming down to a matter of what will become the defacto
modularity solution for the Java platform. OSGi is well on its way to
achieving that status.
This happens over and over.
A significant number of Java developers used log4j and yet Sun went
and invented a different logging solution for the JSE.
J2EE/EJB2.x started collapsing under its own weight. Developers
started gravitating toward Spring Framework. JEE5/EJB3 is failing to
woo back the defectors. In contrast, Spring Framework adoption
continues to accelerate. It would now be very interesting (if one were
a Java app server provider) to build an app server entirely around
Spring. It would be one by nature that would be entirely modular (as
opposed to "kitchen sink" monolithic the way JEE servers are). It
would be modular and have an Isolates capability. It would completely
supplant the Apache-web-server/multi-instance-Tomcat combos and be
pure Java. Yet Sun would never do something innovative like that with
their Grizzly underpinned Glassfish code base.
Sun chose to push Ruby as the pre-eminent scripting language for the
JVM, while the Java developer community (who were not necessarily Ruby
language aficionados - as Sun seemed to posit that they all were)
tended to better like Groovy as it was crafted especially to be a
companion scripting language to Java on the JVM. (Groovy syntax is
very friendly to Java programmers and just uses the existing class
libraries - with a wee bit of enhancement for closure-style
programming.)
I've attended a number of NFJS conferences by now and believe I've
detected a current of underlying against amongst that body of Java
attendees and presenters in regard to attitudes held toward Sun. In
reflection over the years, I see the reason why. Sun repeatedly seems
to choose the path that defies the Java community at large. If Sun
isn't holding onto the rudder, then they don't want anything to do
with it.
My money says Sun will attempt to also ignore OSGi and push an
alternative modularity solution through the JSR process - despite what
the greater Java developer community decides to embrace. They can't
help themselves - it's in their corporate DNA to behave this way.
--- RogerV <rog...@qwest.net> wrote: > I've attended a number of NFJS conferences by now and believe I've > detected a current of underlying against amongst that body of Java > attendees and presenters in regard to attitudes held toward Sun. In > reflection over the years, I see the reason why. Sun repeatedly seems > to choose the path that defies the Java community at large. If Sun > isn't holding onto the rudder, then they don't want anything to do > with it.
I'm not sure I see it quite that way. Look at the example of log4j. Is it not true that the java.util.logging framework is implementation agnostic and JSE in fact ships with a log4j implementation of it. Similarly, I could see the same thing happening with a modularity framework -- Sun can have their perceived rudder by having a top-level framework that ships with JEE, but underneath uses OSGi by default. And given the nature of the beast, it probably shouldn't be all that bad to write adapters for things to work in a variety of modularity frameworks. I'm not seeing a big problem here.
Well, despite the way my tone perhaps comes across in this discussion
thread, you must know I'm a secret admirer of Sun Microsystems. I just
don't always see eye to eye with how they could be innovating (and
embracing innovation) themselves on their own platform that they
invented.
It frustrates me to no end to see companies approach the world with
self-imposed blinders. Self-imposed handicaps.
On Jan 26, 1:07 pm, Alexey Zinger <inline_f...@yahoo.com> wrote:
> --- RogerV <rog...@qwest.net> wrote:
> > I've attended a number of NFJS conferences by now and believe I've
> > detected a current of underlying against amongst that body of Java
> > attendees and presenters in regard to attitudes held toward Sun. In
> > reflection over the years, I see the reason why. Sun repeatedly seems
> > to choose the path that defies the Java community at large. If Sun
> > isn't holding onto the rudder, then they don't want anything to do
> > with it.
> I'm not sure I see it quite that way. Look at the example of log4j. Is it not
> true that the java.util.logging framework is implementation agnostic and JSE in
> fact ships with a log4j implementation of it. Similarly, I could see the same
> thing happening with a modularity framework -- Sun can have their perceived
> rudder by having a top-level framework that ships with JEE, but underneath uses
> OSGi by default. And given the nature of the beast, it probably shouldn't be
> all that bad to write adapters for things to work in a variety of modularity
> frameworks. I'm not seeing a big problem here.
I can't comment on the osgi stuff (since I honestly don't know anything about it) but I do know that we focused on Ruby as our next JVM language because that's where the numbers are. Ruby on Rails is growing quickly so we wanted JRuby to be the best Ruby implementation out there.
- Josh, on the go
On Jan 26, 2008, at 1:06 PM, RogerV <rog...@qwest.net> wrote:
> On Jan 26, 12:55 am, Neil Bartlett <njbartl...@gmail.com> wrote: >> However, I wouldn't say that these developments are negative for the >> "JSR crowd". Remember that OSGi R4.1 has been standardised under the >> JCP via JSR 291 (for Java SE) and JSR 232 (for Java ME). OSGi itself >> began life as JSR 008.
> I rather suspected (or vaguely remembered) that OSGi had some > associated JSR(s). These days, though, doesn't look like OSGi fate > necessarily rest on the glacial JSR process.
> It's now coming down to a matter of what will become the defacto > modularity solution for the Java platform. OSGi is well on its way to > achieving that status.
> This happens over and over.
> A significant number of Java developers used log4j and yet Sun went > and invented a different logging solution for the JSE.
> J2EE/EJB2.x started collapsing under its own weight. Developers > started gravitating toward Spring Framework. JEE5/EJB3 is failing to > woo back the defectors. In contrast, Spring Framework adoption > continues to accelerate. It would now be very interesting (if one were > a Java app server provider) to build an app server entirely around > Spring. It would be one by nature that would be entirely modular (as > opposed to "kitchen sink" monolithic the way JEE servers are). It > would be modular and have an Isolates capability. It would completely > supplant the Apache-web-server/multi-instance-Tomcat combos and be > pure Java. Yet Sun would never do something innovative like that with > their Grizzly underpinned Glassfish code base.
> Sun chose to push Ruby as the pre-eminent scripting language for the > JVM, while the Java developer community (who were not necessarily Ruby > language aficionados - as Sun seemed to posit that they all were) > tended to better like Groovy as it was crafted especially to be a > companion scripting language to Java on the JVM. (Groovy syntax is > very friendly to Java programmers and just uses the existing class > libraries - with a wee bit of enhancement for closure-style > programming.)
> I've attended a number of NFJS conferences by now and believe I've > detected a current of underlying against amongst that body of Java > attendees and presenters in regard to attitudes held toward Sun. In > reflection over the years, I see the reason why. Sun repeatedly seems > to choose the path that defies the Java community at large. If Sun > isn't holding onto the rudder, then they don't want anything to do > with it.
> My money says Sun will attempt to also ignore OSGi and push an > alternative modularity solution through the JSR process - despite what > the greater Java developer community decides to embrace. They can't > help themselves - it's in their corporate DNA to behave this way.
On Jan 27, 3:54 am, Joshua Marinacci <jos...@gmail.com> wrote:
> I can't comment on the osgi stuff (since I honestly don't know
> anything about it) but I do know that we focused on Ruby as our next
> JVM language because that's where the numbers are. Ruby on Rails is
> growing quickly so we wanted JRuby to be the best Ruby implementation
> out there.
> - Josh, on the go
Yeah, Josh, I'm fully aware that Sun went with Ruby because they paid
attention to the hype band-wagon of the Ruby crowd. Yet strangely I
don't think the Java community at large has been as infected with
Rubism as Sun strategic planners were. Instead, most in the Java
community didn't really feel inclined to abandon Java and move to
Ruby, but were content to learn (or pay attention to) good ideas from
Ruby and Rails.
So when RoR mania first hit the scene, the Ruby legion was in full
force at NFJS conferences (Dave Thomas, Bruce Tate, et al). RoR
dominated a lot of hallway conversation that year.
Yet next year, those folks weren't much around. Instead Groovy and
Grails was the dominate subject matter in terms of alternative
languages for the JVM. Even sessions not directly on Groovy or Grails
had a tie in to Groovy. One on using Java 6 to integrate a scripting
language into a Java application featured doing that with Groovy.
Another on rules engines used Groovy as the rules engine scripting
language. Yet another on test driven development featured using
Groovy. The panel discussions, when the subject came up of what would
be a big factor in Java for the coming year - Groovy became a major
item that was brought up by panelist.
Groovy uptake was so apparent in the Java community that the NFJS
folks themselves felt compelled to get involved in supporting its
development (this after Sun strangely opted for Ruby instead).
So perhaps folks are thinking the NFJS attendees are perhaps just a
bunch of odd balls and aren't really representative of the "Java
community".
Just how out of the mainstream are the NFJS crowd? Well, the NFJS
faction is certainly well known for its uptake of Spring Framework,
and the NFJS organization is heavily involved in doing Spring
Framework conferences as well.
Which has greater momentum in the Java community today? Spring or
Sun's JEE5/EJB3?
Spring momentum continues to accelerate while JEE5/EJB3 is rather
languishing:
Everywhere I look these days there's something on OSGi. By next
January, it will be fair to look back on 2008 and dub it the year of
OSGi.
All the app servers or frameworks are somehow incorporating OSGi -
that's including the JEE app servers. Eclipse is looking to parley
their success with OSGi for their IDE as something to be used for
server-side development now.
Really all that's left to be done is have a JSR that ratifies OSGi as
THE module solution for the Java programming platform.
Any attempt at this point in time in pursing alternative module
solutions than OSGi will be just another vain effort in an exercise of
futility and irrelevance.
Indeed, it would be fair to say that continuing a non-OSGi JSR effort
at this point would amount to a deliberate attempt to sow
fragmentation of the Java community into different variant forks.
Instead, graciously admit defeat and move on. No one entity any longer
has the ability to impose what will be pervasive for Java computing
and community acceptance.
I found the Software Engineering podcast on OSGi that someone on this pointed out very interesting in understanding OSGi and JSR 277 and 294. They are tackling different problems to me (but I am basing this purely on my understanding of what the interview said - not on real experience).
Here is my current understanding:
OSGi is a very dynamic thing, with lots of plugin support. You have to design the interfaces of how all the different "bundles" fit together. You have to work out all the contracts about what interactions can occur across boundaries. Existing third party libraries cannot just become a bundle - do get all the benefit from OSGi you really want their APIs designed to fit in with the OSGi model. You have to add manifests to control the visibility across bundle boundaries. This is ideal for things like Eclipse where Eclipse wants to define a framework that other people plug in to. Everything is dynamic, you can turn bits on and off while everything is running, Eclipse define all the contracts that everyone else conform to, etc.
Then there are the other two JSRs.
JSR 294 deals with introducing better scope of visibility than just the package level scope. It allows me to break a complex set of classes into multiple packages, but still control what to make 'public' to consumers of the code I develop. Its a language level thing, improving on the current public/protected/package scope stuff. It is not dynamic. It does not require interfaces to be defined and contracts to be agreed to on how all the different bits are going to play together. It does not require any change to deal with existing third party libraries. It is useful to me even if I use OSGi.
JSR 277 is a static module system. It is not infrastructure for dynamically pluggable components. It does not require all parties to agree to contracts on how everything is going to plug together with interfaces defined for all the APIs. It is more of a static organizational thing.
I really like OSGi and am planning to use it Real Soon Now on a project I am doing. This is because I really need a dynamic pluggable framework and I can define all the contracts between the plugins. JSR 294 feels nice to me - better ability to control visibility is nice for internal code management. JSR 277 I don't think I have a personal need for. My understanding is it imposes less constraints and has less I have to do to use it, but for my particular current need I don't think it will give me any benefit. (This does not mean its not useful to others.)
But it is clearer in my mind that they are not tackling the same problem. Overlapping problem space yes, but they are not the same thing.
Alan
Disclaimer: I have not used any of these technologies. Just my understanding based on the SE podcast I listened to.
RogerV wrote: > Any attempt at this point in time in pursing alternative module > solutions than OSGi will be just another vain effort in an exercise of > futility and irrelevance.
> Indeed, it would be fair to say that continuing a non-OSGi JSR effort > at this point would amount to a deliberate attempt to sow > fragmentation of the Java community into different variant forks. > Instead, graciously admit defeat and move on. No one entity any longer > has the ability to impose what will be pervasive for Java computing > and community acceptance.
> Everywhere I look these days there's something on OSGi. By next
> January, it will be fair to look back on 2008 and dub it the year of
> OSGi.
> All the app servers or frameworks are somehow incorporating OSGi -
> that's including the JEE app servers. Eclipse is looking to parley
> their success with OSGi for their IDE as something to be used for
> server-side development now.
> Really all that's left to be done is have a JSR that ratifies OSGi as
> THE module solution for the Java programming platform.
> Any attempt at this point in time in pursing alternative module
> solutions than OSGi will be just another vain effort in an exercise of
> futility and irrelevance.
> Indeed, it would be fair to say that continuing a non-OSGi JSR effort
> at this point would amount to a deliberate attempt to sow
> fragmentation of the Java community into different variant forks.
> Instead, graciously admit defeat and move on. No one entity any longer
> has the ability to impose what will be pervasive for Java computing
> and community acceptance.
I don't think the idea was that lots of developers were leaving in droves to Ruby (though a few high profile people were, as I recall). The idea is to expand the scope of the Java platform and bring in more new developers. JRuby was low hanging fruit. It already existed, Ruby had a growing community, and the JRuby project itself needed some support. So we hired the JRuby guys so they could work on it full time. Sounds good to me!
Next is PHP which will have NetBeans support in NB 6.1.
I believe a Groovy plugin for NB is underway as well, but I don't know it's status.
> On Jan 27, 3:54 am, Joshua Marinacci <jos...@gmail.com> wrote: >> I can't comment on the osgi stuff (since I honestly don't know >> anything about it) but I do know that we focused on Ruby as our next >> JVM language because that's where the numbers are. Ruby on Rails is >> growing quickly so we wanted JRuby to be the best Ruby implementation >> out there.
>> - Josh, on the go
> Yeah, Josh, I'm fully aware that Sun went with Ruby because they paid > attention to the hype band-wagon of the Ruby crowd. Yet strangely I > don't think the Java community at large has been as infected with > Rubism as Sun strategic planners were. Instead, most in the Java > community didn't really feel inclined to abandon Java and move to > Ruby, but were content to learn (or pay attention to) good ideas from > Ruby and Rails.
> So when RoR mania first hit the scene, the Ruby legion was in full > force at NFJS conferences (Dave Thomas, Bruce Tate, et al). RoR > dominated a lot of hallway conversation that year.
> Yet next year, those folks weren't much around. Instead Groovy and > Grails was the dominate subject matter in terms of alternative > languages for the JVM. Even sessions not directly on Groovy or Grails > had a tie in to Groovy. One on using Java 6 to integrate a scripting > language into a Java application featured doing that with Groovy. > Another on rules engines used Groovy as the rules engine scripting > language. Yet another on test driven development featured using > Groovy. The panel discussions, when the subject came up of what would > be a big factor in Java for the coming year - Groovy became a major > item that was brought up by panelist.
> Groovy uptake was so apparent in the Java community that the NFJS > folks themselves felt compelled to get involved in supporting its > development (this after Sun strangely opted for Ruby instead).
> So perhaps folks are thinking the NFJS attendees are perhaps just a > bunch of odd balls and aren't really representative of the "Java > community".
> Just how out of the mainstream are the NFJS crowd? Well, the NFJS > faction is certainly well known for its uptake of Spring Framework, > and the NFJS organization is heavily involved in doing Spring > Framework conferences as well.
> Which has greater momentum in the Java community today? Spring or > Sun's JEE5/EJB3?
> Spring momentum continues to accelerate while JEE5/EJB3 is rather > languishing:
> --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com > To unsubscribe from this group, send email to javaposse-unsubscribe@googlegroups.com > For more options, visit t
Even better would be full ECMAScript 4 implementation - but isn't the
Rhino project moving on to ECMAScript 4 compliance?
Plain JavaScript I find less than interesting. But ECMAScript 4
running on the JVM would be quite interesting.
BTW, somewhere along the way I recall recently hearing of a case where
Forth was being used in a new system. I can't recall the context of
use, though. Surely it was some manner of embedded system.
I was previously under the impression that Forth had gone completely
out of vogue so it was interesting to hear of a new system using it.
On Feb 12, 2:05 pm, Casper Bang <c...@brunata.dk> wrote:
>> Next is PHP which will have NetBeans support in NB 6.1.
> How about JavaScript? I heard Gregg Sporar hint about that Tor is > prototyping support for this.
> /Casper > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com > To unsubscribe from this group, send email to javaposse-unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/javapo
> Even better would be full ECMAScript 4 implementation - but isn't the > Rhino project moving on to ECMAScript 4 compliance?
> Plain JavaScript I find less than interesting. But ECMAScript 4 > running on the JVM would be quite interesting.
> BTW, somewhere along the way I recall recently hearing of a case where > Forth was being used in a new system. I can't recall the context of > use, though. Surely it was some manner of embedded system.
> I was previously under the impression that Forth had gone completely > out of vogue so it was interesting to hear of a new system using it.
> On Feb 12, 2:05 pm, Casper Bang <c...@brunata.dk> wrote: >>> Next is PHP which will have NetBeans support in NB 6.1.
>> How about JavaScript? I heard Gregg Sporar hint about that Tor is >> prototyping support for this.
> Even better would be full ECMAScript 4 implementation - but isn't the > Rhino project moving on to ECMAScript 4 compliance?
> Plain JavaScript I find less than interesting. But ECMAScript 4 > running on the JVM would be quite interesting.
> BTW, somewhere along the way I recall recently hearing of a case where > Forth was being used in a new system. I can't recall the context of > use, though. Surely it was some manner of embedded system.
> I was previously under the impression that Forth had gone completely > out of vogue so it was interesting to hear of a new system using it.
> On Feb 12, 2:05 pm, Casper Bang <c...@brunata.dk> wrote: > > > Next is PHP which will have NetBeans support in NB 6.1.
> > How about JavaScript? I heard Gregg Sporar hint about that Tor is > > prototyping support for this.
> Why is ECMAScript 4 interesting and Javascript isn't?
No doubt I'll get some stones cast my way for saying this, but I
really have never liked JavaScript.
ActionScript3, which is based on ECMAScript 4 spec, I pretty much
like.
If I still lived the world of day to day development (these days am
just a dev-mgr/architect - yeah, another reason for a stoning), I
could see myself getting along just fine with AS3.
Classes, interfaces, namespace scoping, are all first class in the
language. AC3 compiles with static type checking as the default
behavior. That I like about AS3, as I fall on the side of the fence of
being a fan of static type checking. AS3 still has some JavaScript
goodness, such as closures, and that works very naturally with such as
async programming.
If tomorrow all the javac compilers all just got devoured by a runaway
anti-Java virus, yet left the JVM unscathed, and all there were was an
ECMAScript 4 Rhino to run on the JVM, well - I could imagine a worse
apocalypse.
So it sounds like the difference isn't the languages, but that Adobe (maker of ActionScript3) provides you with a strict compiler. Are the languages themselves different?
>> Why is ECMAScript 4 interesting and Javascript isn't?
> No doubt I'll get some stones cast my way for saying this, but I > really have never liked JavaScript.
> ActionScript3, which is based on ECMAScript 4 spec, I pretty much > like.
> If I still lived the world of day to day development (these days am > just a dev-mgr/architect - yeah, another reason for a stoning), I > could see myself getting along just fine with AS3.
> Classes, interfaces, namespace scoping, are all first class in the > language. AC3 compiles with static type checking as the default > behavior. That I like about AS3, as I fall on the side of the fence of > being a fan of static type checking. AS3 still has some JavaScript > goodness, such as closures, and that works very naturally with such as > async programming.
> If tomorrow all the javac compilers all just got devoured by a runaway > anti-Java virus, yet left the JVM unscathed, and all there were was an > ECMAScript 4 Rhino to run on the JVM, well - I could imagine a worse > apocalypse.
----- Original Message -----
From: javaposse@googlegroups.com <javaposse@googlegroups.com>
To: javaposse@googlegroups.com <javaposse@googlegroups.com>
Sent: Tue Feb 12 19:32:21 2008
Subject: [The Java Posse] Re: OSGi on the Server Side and the matter of the WOO
So it sounds like the difference isn't the languages, but that Adobe
(maker of ActionScript3) provides you with a strict compiler. Are the
languages themselves different?
- Josh
On Feb 12, 2008, at 7:22 PM, RogerV wrote:
>> Why is ECMAScript 4 interesting and Javascript isn't?
> No doubt I'll get some stones cast my way for saying this, but I
> really have never liked JavaScript.
> ActionScript3, which is based on ECMAScript 4 spec, I pretty much
> like.
> If I still lived the world of day to day development (these days am
> just a dev-mgr/architect - yeah, another reason for a stoning), I
> could see myself getting along just fine with AS3.
> Classes, interfaces, namespace scoping, are all first class in the
> language. AC3 compiles with static type checking as the default
> behavior. That I like about AS3, as I fall on the side of the fence of
> being a fan of static type checking. AS3 still has some JavaScript
> goodness, such as closures, and that works very naturally with such as
> async programming.
> If tomorrow all the javac compilers all just got devoured by a runaway
> anti-Java virus, yet left the JVM unscathed, and all there were was an
> ECMAScript 4 Rhino to run on the JVM, well - I could imagine a worse
> apocalypse.
> Isn't JBoss 5 supposed to have some modularity features? Are they using OSGi, the official JSR, both, or neither?
> -James
> ----- Original Message -----
> From: javaposse@googlegroups.com <javaposse@googlegroups.com>
> To: The Java Posse <javaposse@googlegroups.com>
> Sent: Fri Jan 25 00:22:39 2008
> Subject: [The Java Posse] OSGi on the Server Side and the matter of the WOO
> No-Fluff-Just-Stuff founder, Jay Zimmerman, likes to refer to what he
> calls the WOO factor - window of opportunity - when talking about the
> dynamics of our software development industry.
> For me, Adobe Flex is a case in point of the WOO factor that he talks
> about. It's a technology that was ready and in position at the right
> time to become a dominant RIA solution. In contrast Java was caught
> with nothing to show in the RIA space. It missed the WOO.
> Right now, I have a server-side project that will be built on OSGi.
> It's here today, has a proven track record (Eclipse), and solves the
> problems of project size scalability that we need to grapple with over
> product life time.
> Once again, just as EJB3 missed the WOO and has been eclipsed by
> Spring Framework, whatever standard that Sun will end up backing via a
> JSR to address this space will miss the WOO.
> Why am I writing this as though I'm lamenting a sad development? I
> guess that's a good question. There's really nothing to be down about.
> Great software solutions on the Java platform exist outside of JSR
> land. Indeed, maybe the very best software used in Java circles has
> been the non JSR stuff.
> In coming to the Java community I've never had a problem sidestepping
> the nonsense being peddled and instead adopted what made sense. With
> JEE I completely ignored session and entity beans and just used JMS
> MDBs and Hibernate. So in 2003/2004 I built a distributed system
> system on principals that the SOA dudes are all crowing about now.
> More recently I've completely ignored MVC web frameworks on the server-
> side and instead went with RIA + SOA where MVC is completely done on
> the client-side. (Doing MVC on the server-side in defiance of the
> Fallacies of Distributed Computing was wrong headed from the get go.)
> So here we stand today poised to fish or cut bait on this matter of
> large scale SOA-based development on the server-side - and we badly
> need a modularity solution for Java.
> This is the moment of the WOO and here stands OSGi.
|
