Joe's component model vision exist already - in Flex
RogerV
team (all Java web developers) working on a Flex-based product.
Well, I just went through sitting in on a week of Flex training that I
had brought in in-house (am a dev mgr) to get a broader group of folks
trained up on Flex.
What was razor sharp clear about Flex is that it is very likely the
leading GUI framework that intrinsically supports/enables a component-
based approach to software development.
If you want to see an OOP language and framework environment that also
has properties and events coupled to a data binding architecture, and
then see how that all gives rise to the ability to live in a software
development universe of off-the-shelf reusable components, check out
Flex.
A sad thing about this deeper dive Flex training experience, though,
is that it made me realize just how backward thinking the Java
community has been and how far off the mark some of Java's engineering
goals have been over its history. Instead of clunky, complex Swing API
there should have been a Flex-like framework for creating portable GUI
apps with the huge leverage, power, and flexibility that that approach
would entail.
Today Flex 2 (and very soon Flex 3) are extremely well tuned to their
intended purpose. JavaFX, by comparison, is not so well tuned. Sun
does not have the grasp of this overall problem space the way Adobe
very clearly does. Sun never really has understood how to take on the
end user facing GUI problem. It's just not in their DNA.
Casper Bang
got me hooked when witnessing the consummation of one of our legacy
webservices with 2 lines of code and no dependency of a 4MB JAR. Adobe
continues to push hard for innovative features that simply work. With
upcoming Thermo RIA layout tool and Hydra GPU acceleration it's
inevitable that Flash/Flex will become even more pervasive and its not
hard to imagine a scenario of Flex completely burying JavaFx like
Flash did with applets.
/Casper
RogerV
4 years ago.
I did not have the "ah hah" experience with C# properties, events, and
delegates that I've had with Flex/MXML/ActionScript component
development enabling features.
Using the C# stuff was fine enough but wasn't revolutionary relative
to what was going on in my Java middle-tier software where those
specific features were missing. C# .NET didn't take it far enough in
order to have a truly adept component-style solution. (I know, this
will sound odd because the discussion going on in the threads has been
posited on the assumption of "add properties and events to the
language and presto - component-based development".)
The point is that there needs to be a well thought out end-to-end
underlying framework coupled to language features before component-
based development reaches critical mass. So there are a number of
ingredients that go into that mix.
Casper Bang
that to C# it wouldn't have been the general purpose "Java done right"
language they were going for. It all depends on the point of view,
Java people argue C# goes too far, you argue it doesn't go far enough.
In any event, components are the way forward... we can't continue to
build more and more complex systems with means like sub classing,
adding listeners, writing renders, setting L&F's and all the other
peripheral crap you have to deal with in Swing. Flex is therefore one
of the most interesting technologies to follow these days in my
opinion (along with LINQ).
/Casper
Curt Cox
What does component mean to you? Can you give a testable definition,
or perhaps a list of requirements that are necessary if not
sufficient? Would Flex be the best model you know of?
- Curt
Joe Nuxoll (Java Posse)
properties and events. I also am enjoying the notion that several
folks understand what I mean when I describe "component library" vs.
"class library" based software development. From what I've read so
far - Casper has the cleanest grasp on my points. Thanks Casper for
helping folks understand what I'm talking about.
Now, to the point of *this* thread - I am very well aware that "my
component model vision" already exists! It's not mine! This concept
has been around for a very long time, but early developers of Java
just didn't believe us when we explained that they were starting
things out on the wrong foot. The "component-oriented" software stuff
spawned in the Windows market over 10 years ago - and those
formulating Java (early JavaSoft) were all Unix-heads. No joke. If
it came from Windows land, they just didn't want to hear about it.
It took major teeth-pulling just to get the first JavaBeans spec in
place, and that was a tremendous compromise as a convention rather
than a language change. Carl Quinn (fellow Posse member) was actually
a *major* pusher for the component-oriented stuff early on. In
fact... if you look closely at all the source code in
java.awt.event.* you might just see a familiar name. He wrote the
JavaBeans event model while we were prototyping the first version of
JBuilder ("Latte" at the time - but apparently that means "boner" in
German, so we changed to "JBuilder"). He is also an author on the
original JavaBeans spec.
So... yes, this concept has existed for quite a while.
Unfortunatley, it never got pushed quite hard enough to get into the
language idioms itself. It's always just been a pattern/convention,
which is often ignored. Thus - you need to ramp up your learning on
each new task you try to approach if you're going to use Java. There
is very minimal leverage between different problem spaces.
- Joe
RogerV
I guess folks tend to credit Visual Basic with getting the component
band wagon going in a serious and credible manner. Two strikes against
VB, though:
1.) VB didn't have OOP language features until VB.NET (so could do
reusable components but could not apply OOP design techniques).
2) The encapsulation module was based on COM, as particularly embodied
by ActiveX.
I dealt with a major application written as VB COM components and that
was run in a Citrix Metaframe cluster. The component capabilities of
VB were not of any sufficient advantage to overcome the legion of
problems that I had to overcome due to problematic VB architecture
(and problematic COM/Windows architecture).
So given a choice between VB and components or Java and OOP (and the
ability Java has to construct such things as app servers that can so
readily have modules loaded at runtime), I'd definitely opt for Java.
To me the component capability of VB was not at all sufficient to make
up for its deficiencies.
As I was pointing out to Casper in a previous post in this thread,
even though C# .NET has had properties, events - and is an OOP
language - it wasn't until my encounter with Flex that I've seen what
is a truly viable component-based approach to software development.
Flex uses an OOP language, ActionScript3, and has properties and
events. However, Flex has other features and characteristics that
blend with properties and events so as to facilitate component
development. I've not really spelled out what I think these other
factors are in explicit detail on purpose.
The JavaFX and Silverlight guys should have to figure things out for
themselves.
As far as I'm concerned Adobe has definitely earned their leading
position in web RIA and I applaud their ingenuity of getting the
architecture just right.
On Oct 14, 1:04 pm, "Joe Nuxoll (Java Posse)" <jnux...@gmail.com>
wrote:
Casper Bang
Well that's where it gets tricky, the word component has been applied
in so many contexts and abstracts that it probably means something
different to us all.
To me at least, a component is a contained and versioned facade
over... whatever (classes, enums, render kits etc.) designed
specifically to solve a problem but out of context. That sounds like
an oxymoron, but what I mean is that the component performs its duties
and interactions regardless of the hosting environment it has been
placed in.
I read a hardware analogy many years ago which I only vaguely remember
(I studied electronics before discovering computers could be rewired
much cheaper). It made a comparison towards IC's. I.e. if you need to
hook up a legacy record player to your A/D converter, you are going to
need a pre-amplifier like the classic LM741 chip. Well since the LM741
doesn't exactly have particularly great noise characteristics you
might want to plug in a more expensive AD825 instead, it has the same
pinots and input/output requirements (its contract). In Java, this
would be expressed through something like "power, balanced inputs, and
output according that can talk to a LM741 ". In C# which has a more
flexible type called a delegate (member function pointer or closure),
it would be expressed with just "power, balanced inputs and an
output". How you hook your components up is entirely up to you, as
long as you agree to the common denominator which is your parameter
signatures. This removes context (looses the coupling) while not
compromising type safely - and it allows a C# developer to configure a
component which has a published event with a string (say an MP3 player
outputting a song title), to another component (say a status bar)
without all the adaptor and inner classes crap we need in Java. And
why would a generic status bar component want to know anything about
an MP3 player? And why would an MP3 player want to know anything about
a status bar?
I am still learning about Flex, so perhaps RogerV could take that one,
I'd be curious in hearing if it is the bind annotation and lambda
functions he finds so much more superior to C# - obviously having good
experience with both. Data binding in the Java language would be nice,
but we need to walk before we can run - and right now we are crawling.
/Casper
RogerV
component-style development was viscerally driven home) I saw these
comments while skimming through a recent infoq interview with Adobe's
James Ward:
Adobe's James Ward on Upcoming Flex 3 Enhancements and Silverlight
http://www.infoq.com/news/2007/09/flex3#view_11474
[begin excerpt]
He [James Ward] also provided more detail on the differences between
Flex and Silverlight, and why the typical developer should choose
Flex:
"One central aspect to RIA where Flex is a few years ahead of
Silverlight is with our component library. With Silverlight you pretty
much have to build your entire UI from scratch. The Flex community and
Adobe provide hundreds of skinable, stylable and extensible components
like DataGrids, Accordions, TabNavigators, and Charts. Other aspects
where we are a few years ahead include built-in support for
accessibility, internationalization, deep-linking, unit testing,
automated testing, data-binding, effects, drag-and-drop management,
and a ton more things that you really need when you build RIAs."
[end excerpt]
So Adobe is entirely conscious of the component capability that
they've engineered into Flex and view it as a distinct advantage.
I agree, because when I saw the extent of capability of components
during the midst of this training, I immediately saw how it would
enable me to accomplish a particular design and architecture goal for
an application I have on the drawing board.
Casper Bang
interesting persons in our industry, Miguel de Icaza, that opened my
eyes. He is generally known for wanting to take Unux developers out of
thinking in pipes and into thinking in components. Unlike many others,
he does not suffer from allergic reactions towards Microsoft related
technologies or pretend to dislike it if he sees an elegant solution.
Now when you look at the difference between opening a file in Java and
doing it in C#, you clearly get the picture of what he is talking
about - even if we in Java call a pipe a decorator:
http://www.ondotnet.com/pub/a/dotnet/2001/07/09/icaza.html
Imagine if Sun was thinking in components. We would have had an IDE
like NetBeans years ago, with a solid and rich component palette
flourishing from community inertia and reuse - where all it took was a
click with a mouse to fetch new components suitable for the problem at
hand. Instead we have a major discovery problem sifting through
sourceforge, swinglabs and various other sources - often missing out
on the very thing that suits you best.
/Casper
On Oct 15, 6:27 am, RogerV <rog...@qwest.net> wrote:
> So after this week of Flex training I sat through (where Flex
> component-style development was viscerally driven home) I saw these
> comments while skimming through a recent infoq interview with Adobe's
> James Ward:
>
> Adobe's James Ward on Upcoming Flex 3 Enhancements and Silverlighthttp://www.infoq.com/news/2007/09/flex3#view_11474
Joe Nuxoll (Java Posse)
hard to get Sun to think this way... but not to much avail until a
long time later when Carl and I were recruited by Sun to finally "fix"
this developer thing with Creator. The WYSIWYG nature of Creator is
what inspired the guys to go build Matisse. They're getting there -
but still don't see that the key is the platform, not the tools. The
tools should be just a thin vaneer on a well designed component
platform. Today the tools have to do *way* too much work for it to
really be considered a "component oriented" platform.
- Joe
joel.neely
sense) which gave me another "poster child" example for events. This
example applies events to a familiar area we all love to hate:
logging.
Instead of requiring a class to hold (or worse, create) an instance of
some logging library's logger object, simply let a class publish
events when interesting (or problematic) state changes occur. In
production deployment, a (real) logger can subscribe to appropriate
events and Do The Right Thing. One could have multiple log-like
subscribers to deal in different ways with different event severities.
And, of course, unit testing is greatly simplified if one merely needs
a mock which subscribes to the class under test and verifies that it
fired expected events during the test. No logging framework (or
frameworkaround ;-) required.
Nat Pryce blogged about this at http://nat.truemesh.com/archives/000710.html
with a reference to his use of an Announcer in connection with jMock.
When I read it, I was reminded of Joe's impassioned plea for
properties and events at Java Posse Roundup 2007.
-jn-
Casper Bang
event bus.
Still I root for Stephen Colebourne's FCM closures to solve this
problem. I can't possibly imagine a large event-driven application
being terribly effecient with all that reflection?!
/Casper
On Nov 8, 9:26 pm, "joel.neely" <joel.ne...@gmail.com> wrote:
> I recently had a whack on the side of the head (in the Roger von Oech
> sense) which gave me another "poster child" example for events. This
> example applies events to a familiar area we all love to hate:
> logging.
>
> Instead of requiring a class to hold (or worse, create) an instance of
> some logging library's logger object, simply let a class publish
> events when interesting (or problematic) state changes occur. In
> production deployment, a (real) logger can subscribe to appropriate
> events and Do The Right Thing. One could have multiple log-like
> subscribers to deal in different ways with different event severities.
>
> And, of course, unit testing is greatly simplified if one merely needs
> a mock which subscribes to the class under test and verifies that it
> fired expected events during the test. No logging framework (or
> frameworkaround ;-) required.
>
> Nat Pryce blogged about this athttp://nat.truemesh.com/archives/000710.html
Peter Becker
http://doc.trolltech.com/4.3/signalsandslots.html . The coolest thing
about it is that there is no compile-time dependency between the
observer and the observed either way. As long as the signature of the
signal matches (and if not you just adapt it), you can just connect A
to B. If something sends an signal of type (int,int) you just connect
it to any slot of type (int,int) -- the implementer of the slot does
not need to know of the existance of the signal as opposed to the
(usually) more specific listeners in Java.
OTOH you could apply the argument that the specific listeners
introduce some more typesafety in the same way an enum is safer than a
bunch of static ints. But it all seems safer than the
PropertyChangeListeners.
Peter
Casper Bang
probably know it, but Trolltech also maintains the QT Jambi layer for
Java UI, which carries over the signals and slots mechanism (in a
slightly modified version, since Java doesn't have method pointers -
yet).
/Casper
On Nov 8, 11:28 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
> I came to Java from Qt and I still miss the way they handle it:http://doc.trolltech.com/4.3/signalsandslots.html. The coolest thing
> about it is that there is no compile-time dependency between the
> observer and the observed either way. As long as the signature of the
> signal matches (and if not you just adapt it), you can just connect A
> to B. If something sends an signal of type (int,int) you just connect
> it to any slot of type (int,int) -- the implementer of the slot does
> not need to know of the existance of the signal as opposed to the
> (usually) more specific listeners in Java.
>
> OTOH you could apply the argument that the specific listeners
> introduce some more typesafety in the same way an enum is safer than a
> bunch of static ints. But it all seems safer than the
> PropertyChangeListeners.
>
> Peter
>
> On Nov 9, 2007 6:26 AM, joel.neely <joel.ne...@gmail.com> wrote:
>
>
>
> > I recently had a whack on the side of the head (in the Roger von Oech
> > sense) which gave me another "poster child" example for events. This
> > example applies events to a familiar area we all love to hate:
> > logging.
>
> > Instead of requiring a class to hold (or worse, create) an instance of
> > some logging library's logger object, simply let a class publish
> > events when interesting (or problematic) state changes occur. In
> > production deployment, a (real) logger can subscribe to appropriate
> > events and Do The Right Thing. One could have multiple log-like
> > subscribers to deal in different ways with different event severities.
>
> > And, of course, unit testing is greatly simplified if one merely needs
> > a mock which subscribes to the class under test and verifies that it
> > fired expected events during the test. No logging framework (or
> > frameworkaround ;-) required.
>
> > Nat Pryce blogged about this athttp://nat.truemesh.com/archives/000710.html
Peter Becker
much detail. The problem I have with the latter is that while I loved
Qt, I suspect that it will clash in the Java world -- in C++ there is
no default GUI library with its own communication patterns, in Java
there is. That causes some conflict and if you add the potential
deployment issues it seemed better to stick with Swing -- at least for
my OSS projects which is where I use Swing.
Now if the language itself would move a bit, things would be
different. Not that I think that'll really happen, the false idol of
backward compability seems very strong in the Java world.
Peter
Jess Holle
> I must admit that I never really looked into either C# or Jambi in
> much detail. The problem I have with the latter is that while I loved
> Qt, I suspect that it will clash in the Java world -- in C++ there is
> no default GUI library with its own communication patterns, in Java
> there is. That causes some conflict and if you add the potential
> deployment issues it seemed better to stick with Swing -- at least for
> my OSS projects which is where I use Swing.
>
> Now if the language itself would move a bit, things would be
> different. Not that I think that'll really happen, the false idol of
> backward compability seems very strong in the Java world.
>
necessary features. It just takes a bit more thought to dovetail old
and new.
--
Jess Holle
Peter Becker
would mean replacing the existing communication patterns (i.e. usually
Observer) with a new approach. Of course you could keep the old
interfaces and just @deprecate them, which wouldn't be the nice
solution I'd like to see, but at least a step in the right direction.
Peter
Casper Bang
> Now if the language itself would move a bit, things would be
> different. Not that I think that'll really happen, the false idol of
> backward compability seems very strong in the Java world.
Way to strong, I can think of no other language that is so locked down
and frankly its killing innovation. Sun's business model around Java
just doesn't create revenue to drive Java forward, it seams like all
there's left is momentum enough to maintain - disguised as backward
compatibility (is that the true reason for the sudden open sourcing?).
That means innovation and improvements has to come from outside, but
evidently people are finding that hard to do as well because it's a
chicken and egg problem. Sun created the language; it's pretty obvious
it will also be Sun destroying it due to their inability to lead. To
those who say "just use Scala", I'll just like to ask where the IDE?
> There is no reason backward compatibility needs to be sacrificed to add
> necessary features. It just takes a bit more thought to dovetail old
> and new.
Backwards compatibility involves duplication, compromises and mental
overhead - you never really shake of the naive old days. Rails, PHP,
Pearl, Python, name-your-language all follow a different model where
cutting the court once a while is considered healthy and practiced
rather successfully. And really, what would the problem be with doing
the same in Java here 15 years after its inception? After all, there
is nothing stopping you from running several JVM's as indeed often you
have to do anyway and it might keep Java from becoming the next
Fortran.
/Casper
Jess Holle
Backwards compatibility involves duplication, compromises and mental overhead - you never really shake of the naive old days. Rails, PHP, Pearl, Python, name-your-language all follow a different model where cutting the court once a while is considered healthy and practiced rather successfully. And really, what would the problem be with doing the same in Java here 15 years after its inception? After all, there is nothing stopping you from running several JVM's as indeed often you have to do anyway and it might keep Java from becoming the next Fortran.
The "mental overhead" of backwards compatibility done right is generally small and old, duplicative deprecated features could be more strongly denoted as "obsolete" and dropped from the default viewing mode of Javadoc. The flip side of this coin is that spending a little time thinking through consistency with the existing language features goes a long ways towards not just towards compatibility but easing learning and the size of the "mental model" required for the language.
Languages that "cut the chord" and break compatibility outright on a whim are clearly not trying to operate in mission critical enterprise environments. This is either laziness or a (desparate?) attempt to absolutely maximize the speed of language evolution while completely sacrificing all other concerns.
What we need is (1) a commitment to evolve the language and (2) a dedication of resources to do so in a timely manner. It is possible to have both of these without tossing out backwards compatibility, though it does require a *bit* more in terms of resources. It is also possible to lack these -- even without attempting backwards compatibility.
I believe big reasons Java is not evolving as fast as some would like are actually:
- Sun is attempting to really evaluate how each language change fits with and improves the whole.
- This is a good thing and I *really* appreciate it -- especially as compared to C#'s kitchen sink approach.
- This includes putting a premium on readability and
maintainability -- not just trying to absolutely minimize the
characters required to hack out the code first time in isolation of
other considerations.
- Sun is trying to design the language by consensus.
- This is not such a good thing. Design by benevolent dictator
generally wins out.
- The slowest moving players seem to have more say than everyone else. They often don't want the language to change as they then have to take time and effort to test, support, and adopt new features.
- I don't see Sun as one of the slow moving players here any more -- there are others, e.g. one who notably isn't supporting Java EE 5 yet...
- This has nothing to do with backwards compatbility -- which is
a red herring in this discussion.
Jess Holle
Casper Bang
> of accumulated code that is still functioning perfectly well needs to
> run in the same JVM as new fangled code.
So run the old stuff on legacy VM and use RMI to connect to this. Or
lets have the tools to refactor from legacy code to Java 3, should not
be impossible given its static nature.
> The "mental overhead" of backwards compatibility done right is generally
> small and old, duplicative deprecated features could be more strongly
> denoted as "obsolete" and dropped from the default viewing mode of
> Javadoc. The flip side of this coin is that spending a little time
> thinking through consistency with the existing language features goes a
> long ways towards not just towards compatibility but easing learning and
> the size of the "mental model" required for the language.
The language is the lowest layer, keeping the "mental model"
consistant and simple here is but an illusion if you always need 5
layers and various design patterns on top. Yet evidently this seems to
be a deeply rooted desire among hardcore Java folk:
http://weblogs.java.net/blog/hansmuller/archive/2007/01/property_syntax.html
It has the effect of the tooling stack becoming huge and complicated
(and inconsistant, because everyone has their own tooling layer)
sometimes to the level of you not seeing the Java code anymore.
> I believe big reasons Java is not evolving as fast as some would like
> are actually:
>
> 1. Sun is attempting to really evaluate how each language change fits
> with and improves the whole.
> * This is a good thing and I *really* appreciate it --
> especially as compared to C#'s kitchen sink approach.
Again, what is wrong with having abstractions supplied? If you need
something, you use it, if not, you don't. Simple.
> * This has nothing to do with backwards compatbility -- which
> is a red herring in this discussion.
Not if you believe backwards compatibility is a major reason in the
loss of momentum of Java the language.
/Casper
Jess Holle
There's plenty to prevent running several JVMs if your existing 10 years of accumulated code that is still functioning perfectly well needs to run in the same JVM as new fangled code.So run the old stuff on legacy VM and use RMI to connect to this.
Let's face it throwing out compatibility just because is sheer mental sloth.
Or lets have the tools to refactor from legacy code to Java 3, should not be impossible given its static nature.
That's the huge issue with just dumping backward compatibility -- you immediately jettison all existing library support and hope that these are updated. You split the community support, mindshare, etc, in two. It's a divided we fail, not a divide-and-conquer strategy.
I believe big reasons Java is not evolving as fast as some would like are actually: 1. Sun is attempting to really evaluate how each language change fits with and improves the whole. * This is a good thing and I *really* appreciate it -- especially as compared to C#'s kitchen sink approach.Again, what is wrong with having abstractions supplied? If you need something, you use it, if not, you don't. Simple.
I've been a huge fan of almost all language features added to date as Sun has clearly carefully considered this.
* This has nothing to do with backwards compatbility -- which is a red herring in this discussion.Not if you believe backwards compatibility is a major reason in the loss of momentum of Java the language.
I do buy that design by consensus leads to stalling waiting for a consensus that may never come -- and that some parties have a vested interest in seeing such a stall (as progress in the broader space would show them for the archaic, anti-agile behemoths they are).
--
Jess Holle