Subtle Smalltalk advantage over Java ? 
Author Message
 Subtle Smalltalk advantage over Java ?

On a large scale Smalltalk project  for the credit card industry  I was
involved with we had a problem with memory leakage caused by unwanted
references being maintained to objects that should have been garbage
collected.

These were caused by a number of subtle programming errors that not been
identified and had built up over time.

These sort of issues can be a show stopper for big projects and can be very
difficult to sort out if identified late in the development cycle

However when this issue was idenitified as a problem we were able to get a
handle on it using  Behavior >> allInstances
and Object >> become: Being able to determine the instance count of any
object and remove it using become: enabled the sources of the problem to
tracked down and eliminated. ( VAST has multiAllinstances and multiBecome
that one would use in practice)

Development QA procedures were modified to check for zero instance count on
any new class added to the system when the application was exited.

I suspect that the same issues will arise in any project that uses Java or
any system that uses garbage collection.  However the reflection
capabilities of Java seem much less advanced. I can't see any obvious
equivalent of Behavior>>allInstances or Object>>become:.

Does such a mechanism exist in Java ?  if not this is could be another
argument to roll out in favour of Smaltalk.

We need as many of these arguments as we can muster in the present climate,
at least here the UK.

Peter Lawson
----------------------------------------------------------------------------
Lawson Consulting Ltd
Cambridge UK.



Tue, 29 Jun 2004 20:12:34 GMT  
 Subtle Smalltalk advantage over Java ?
Peter -

I'm certainly no Java Deity, but recently I've been toggling back and
forth between two projects, one VA/ST, the other VA/J.  Generally,
Java has very little in the way of the reflection capabilities a
Smalltalker gets used to, and those which it does provide are best
left unused (horrible performance).  The root cause is, imho, the lack
of a notion of class-side protocol.

Equivalents to #allInstances or #become: would surprise me.  But they
could be there, as I don't exactly go out of my way to delve any
deeper into J-land than I have to ;-)

If I discover anything further, I'll try to remember to post again.

Paul
(ps - in case anyone cares, having sampled a few Java IDEs, VA/J is
actually pretty good from a Smalltalker's perspective.  My second
favorite is a command line text editor ... .  But I haven't yet tried
any of Instantiations' offerings, and they're probably very good.)

Quote:

> On a large scale Smalltalk project  for the credit card industry  I was
> involved with we had a problem with memory leakage caused by unwanted
> references being maintained to objects that should have been garbage
> collected.

> These were caused by a number of subtle programming errors that not been
> identified and had built up over time.

> These sort of issues can be a show stopper for big projects and can be very
> difficult to sort out if identified late in the development cycle

> However when this issue was idenitified as a problem we were able to get a
> handle on it using  Behavior >> allInstances
> and Object >> become: Being able to determine the instance count of any
> object and remove it using become: enabled the sources of the problem to
> tracked down and eliminated. ( VAST has multiAllinstances and multiBecome
> that one would use in practice)

> Development QA procedures were modified to check for zero instance count on
> any new class added to the system when the application was exited.

> I suspect that the same issues will arise in any project that uses Java or
> any system that uses garbage collection.  However the reflection
> capabilities of Java seem much less advanced. I can't see any obvious
> equivalent of Behavior>>allInstances or Object>>become:.

> Does such a mechanism exist in Java ?  if not this is could be another
> argument to roll out in favour of Smaltalk.

> We need as many of these arguments as we can muster in the present climate,
> at least here the UK.

> Peter Lawson
> ----------------------------------------------------------------------------
> Lawson Consulting Ltd
> Cambridge UK.



Wed, 30 Jun 2004 01:49:18 GMT  
 Subtle Smalltalk advantage over Java ?

Quote:
>I suspect that the same issues will arise in any project that uses Java or
>any system that uses garbage collection.  However the reflection
>capabilities of Java seem much less advanced. I can't see any obvious
>equivalent of Behavior>>allInstances or Object>>become:.

There ain't such a thing, IIRC. However, in favor of Java, I think
that adding allInstances() to, say, Class, one would break a lot of
security/sandboxing assumptions - I remember that I was quite disappointed
with reflection but when I then studied most of the missing stuff, a case
could be made from a security point of view for leaving a lot of them out.

From my brief Blackdown JVM hacking days I seem to recall that it
was possible to emulate such a thing on the VM level, though. Never
underestimate the power of a Java programmer with the VM source on his
harddrive :-)

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Wed, 30 Jun 2004 03:18:19 GMT  
 Subtle Smalltalk advantage over Java ?

Quote:


>>I suspect that the same issues will arise in any project that uses Java or
>>any system that uses garbage collection.  However the reflection
>>capabilities of Java seem much less advanced. I can't see any obvious
>>equivalent of Behavior>>allInstances or Object>>become:.

> There ain't such a thing, IIRC. However, in favor of Java, I think
> that adding allInstances() to, say, Class, one would break a lot of
> security/sandboxing assumptions - I remember that I was quite disappointed
> with reflection but when I then studied most of the missing stuff, a case
> could be made from a security point of view for leaving a lot of them out.

Sure - but in that case, you end up with a 'private' Java...
Quote:
> From my brief Blackdown JVM hacking days I seem to recall that it
> was possible to emulate such a thing on the VM level, though. Never
> underestimate the power of a Java programmer with the VM source on his
> harddrive :-)



Wed, 30 Jun 2004 04:32:26 GMT  
 Subtle Smalltalk advantage over Java ?

Quote:

> > On a large scale Smalltalk project  for the credit card industry  I was
> > involved with we had a problem with memory leakage caused by unwanted
> > references being maintained to objects that should have been garbage
> > collected.

> > These were caused by a number of subtle programming errors that not been
> > identified and had built up over time.

> > These sort of issues can be a show stopper for big projects and can be very
> > difficult to sort out if identified late in the development cycle
> > However when this issue was idenitified as a problem we were able to get a
> > handle on it using  Behavior >> allInstances
> > and Object >> become: Being able to determine the instance count of any
> > object and remove it using become: enabled the sources of the problem to
> > tracked down and eliminated. ( VAST has multiAllinstances and multiBecome
> > that one would use in practice)

I am just curious why you doing that? Why you just not find what is
holding your instances? There is no ReferencePathCollector in VAST? If
not, you can write it by yourself. In VW it is one class with about 6
methods. It would give you Reference Path to your object and you will
see real reason why object is held. It is mostly from following
reasons (VW):

Not unregistering from DependentsFields or EventHandlers
Forgotten Undeclared
Class Variables references
GUI Controllers of badly released windows

ReferencePath is usually very long (~1500) elements, if dependency is
involved. I am wondering if ReferencePathCollector is in Java. I am
seeing Java processes with serious leaks growing to 500MB before
beeing killed by ulimit.

Stan

- Show quoted text -

Quote:
> > Development QA procedures were modified to check for zero instance count on
> > any new class added to the system when the application was exited.

> > I suspect that the same issues will arise in any project that uses Java or
> > any system that uses garbage collection.  However the reflection
> > capabilities of Java seem much less advanced. I can't see any obvious
> > equivalent of Behavior>>allInstances or Object>>become:.

> > Does such a mechanism exist in Java ?  if not this is could be another
> > argument to roll out in favour of Smaltalk.

> > We need as many of these arguments as we can muster in the present climate,
> > at least here the UK.

> > Peter Lawson
> > ----------------------------------------------------------------------------
> > Lawson Consulting Ltd
> > Cambridge UK.



Wed, 30 Jun 2004 06:38:47 GMT  
 Subtle Smalltalk advantage over Java ?



edited...

Quote:
> There ain't such a thing, IIRC. However, in favor of Java, I think
> that adding allInstances() to, say, Class, one would break a lot of
> security/sandboxing assumptions - I remember that I was quite disappointed
> with reflection but when I then studied most of the missing stuff, a case
> could be made from a security point of view for leaving a lot of them out.

Oh and do they love the whole security bit...  Got into a "discussion" with
a Java programmer/friend o' mine who fails to grasp Smalltalk and aside from
that whole dynamic typing issue he finds troublesome, the lack of security
in ST (can just anyone load a class and BTW, why do we need a class loader?)
just bugs the hell out of him.

And since he has never had the pleasure of a truly relfective experience, he
believes that Java's handicapped form of reflection is quite useful.  When I
try and explain to him the value of the breadth and depth of Smalltalk's
reflection capabilities he always answers 'But why would  anyone want to do
that?'...akin to his driving a car and me introducing an airplane to
him...neat concept but why would anyone want to fly when I have a perfectly
good car to drive?

Don't ya just love a scotch induced rant?

Chris



Wed, 30 Jun 2004 13:29:33 GMT  
 Subtle Smalltalk advantage over Java ?

Quote:
>Oh and do they love the whole security bit...  Got into a "discussion" with
>a Java programmer/friend o' mine who fails to grasp Smalltalk and aside from
>that whole dynamic typing issue he finds troublesome, the lack of security
>in ST (can just anyone load a class and BTW, why do we need a class loader?)
>just bugs the hell out of him.

I hope you did find my message less short-sighted ;-). BTW, if you want to
teach that friend a bit about the differences between static typing and
security, show him the E language (http://www.erights.org). It adds to the
security of the JVM by being completely capability-based, runs on top of that
JVM, but is dynamically typed itself.

On the topic "why do we need a class loader" I think I've posted before, if
not I'll be happy to chat about it off-line.

Quote:

>Don't ya just love a scotch induced rant?

Only if it was a fine single malt. Especially when Laphroaig was involved.

--

GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



Wed, 30 Jun 2004 18:10:17 GMT  
 Subtle Smalltalk advantage over Java ?
Perhaps I wasn't clear in my original post.

We used  Behavior >> allInstances Object >> become
as diagnostic tools to track down instances of the problems you mentioned
and deal with them and verify that they had been
dealt with.

We did not of course put any  of these methods in run time code.

Peter Lawson
-------------------------------------------
Lawson Consulting,
Cambridge UK



Quote:
> > > On a large scale Smalltalk project  for the credit card industry  I
was
> > > involved with we had a problem with memory leakage caused by unwanted
> > > references being maintained to objects that should have been garbage
> > > collected.

> > > These were caused by a number of subtle programming errors that not
been
> > > identified and had built up over time.

> > > These sort of issues can be a show stopper for big projects and can be
very
> > > difficult to sort out if identified late in the development cycle
> > > However when this issue was idenitified as a problem we were able to
get a
> > > handle on it using  Behavior >> allInstances
> > > and Object >> become: Being able to determine the instance count of
any
> > > object and remove it using become: enabled the sources of the problem
to
> > > tracked down and eliminated. ( VAST has multiAllinstances and
multiBecome
> > > that one would use in practice)

> I am just curious why you doing that? Why you just not find what is
> holding your instances? There is no ReferencePathCollector in VAST? If
> not, you can write it by yourself. In VW it is one class with about 6
> methods. It would give you Reference Path to your object and you will
> see real reason why object is held. It is mostly from following
> reasons (VW):

> Not unregistering from DependentsFields or EventHandlers
> Forgotten Undeclared
> Class Variables references
> GUI Controllers of badly released windows

> ReferencePath is usually very long (~1500) elements, if dependency is
> involved. I am wondering if ReferencePathCollector is in Java. I am
> seeing Java processes with serious leaks growing to 500MB before
> beeing killed by ulimit.

> Stan

> > > Development QA procedures were modified to check for zero instance
count on
> > > any new class added to the system when the application was exited.

> > > I suspect that the same issues will arise in any project that uses
Java or
> > > any system that uses garbage collection.  However the reflection
> > > capabilities of Java seem much less advanced. I can't see any obvious
> > > equivalent of Behavior>>allInstances or Object>>become:.

> > > Does such a mechanism exist in Java ?  if not this is could be another
> > > argument to roll out in favour of Smaltalk.

> > > We need as many of these arguments as we can muster in the present
climate,
> > > at least here the UK.

> > > Peter Lawson

> --------------------------------------------------------------------------
--
> > > Lawson Consulting Ltd
> > > Cambridge UK.



Fri, 02 Jul 2004 18:51:21 GMT  
 Subtle Smalltalk advantage over Java ?
Oops,  I omitted something.

Perhaps I wasn't clear in my original post.

We used  Behavior >> allInstances Object >> become
as diagnostic tools to track down instances of the problems you mentioned
and deal with them and verify that they had been
dealt with.

These methods are useful when used in conjunction with browse refences to an
object which of couse is present in VAST.

We did not of course put any  of these methods in run time code.

Peter Lawson
-------------------------------------------
Lawson Consulting,
Cambridge UK

Quote:

> Perhaps I wasn't clear in my original post.

> We used  Behavior >> allInstances Object >> become
> as diagnostic tools to track down instances of the problems you mentioned
> and deal with them and verify that they had been
> dealt with.

> We did not of course put any  of these methods in run time code.

> Peter Lawson
> -------------------------------------------
> Lawson Consulting,
> Cambridge UK





> > > > On a large scale Smalltalk project  for the credit card industry  I
> was
> > > > involved with we had a problem with memory leakage caused by
unwanted
> > > > references being maintained to objects that should have been garbage
> > > > collected.

> > > > These were caused by a number of subtle programming errors that not
> been
> > > > identified and had built up over time.

> > > > These sort of issues can be a show stopper for big projects and can
be
> very
> > > > difficult to sort out if identified late in the development cycle
> > > > However when this issue was idenitified as a problem we were able to
> get a
> > > > handle on it using  Behavior >> allInstances
> > > > and Object >> become: Being able to determine the instance count of
> any
> > > > object and remove it using become: enabled the sources of the
problem
> to
> > > > tracked down and eliminated. ( VAST has multiAllinstances and
> multiBecome
> > > > that one would use in practice)

> > I am just curious why you doing that? Why you just not find what is
> > holding your instances? There is no ReferencePathCollector in VAST? If
> > not, you can write it by yourself. In VW it is one class with about 6
> > methods. It would give you Reference Path to your object and you will
> > see real reason why object is held. It is mostly from following
> > reasons (VW):

> > Not unregistering from DependentsFields or EventHandlers
> > Forgotten Undeclared
> > Class Variables references
> > GUI Controllers of badly released windows

> > ReferencePath is usually very long (~1500) elements, if dependency is
> > involved. I am wondering if ReferencePathCollector is in Java. I am
> > seeing Java processes with serious leaks growing to 500MB before
> > beeing killed by ulimit.

> > Stan

> > > > Development QA procedures were modified to check for zero instance
> count on
> > > > any new class added to the system when the application was exited.

> > > > I suspect that the same issues will arise in any project that uses
> Java or
> > > > any system that uses garbage collection.  However the reflection
> > > > capabilities of Java seem much less advanced. I can't see any
obvious
> > > > equivalent of Behavior>>allInstances or Object>>become:.

> > > > Does such a mechanism exist in Java ?  if not this is could be
another
> > > > argument to roll out in favour of Smaltalk.

> > > > We need as many of these arguments as we can muster in the present
> climate,
> > > > at least here the UK.

> > > > Peter Lawson

> --------------------------------------------------------------------------
> --
> > > > Lawson Consulting Ltd
> > > > Cambridge UK.



Fri, 02 Jul 2004 19:03:47 GMT  
 Subtle Smalltalk advantage over Java ?
Out of curiousity -- not knowing IBM VAST at all -- does the fact
that the VAST IDE is written in Java limit the capabilities of their
Smalltalk at all?  Ditto reflection capabilities?

  --Jan

Quote:

> Peter -

> I'm certainly no Java Deity, but recently I've been toggling back and
> forth between two projects, one VA/ST, the other VA/J.  Generally,
> Java has very little in the way of the reflection capabilities a
> Smalltalker gets used to, and those which it does provide are best
> left unused (horrible performance).  The root cause is, imho, the lack
> of a notion of class-side protocol.

> Equivalents to #allInstances or #become: would surprise me.  But they
> could be there, as I don't exactly go out of my way to delve any
> deeper into J-land than I have to ;-)

> If I discover anything further, I'll try to remember to post again.

> Paul
> (ps - in case anyone cares, having sampled a few Java IDEs, VA/J is
> actually pretty good from a Smalltalker's perspective.  My second
> favorite is a command line text editor ... .  But I haven't yet tried
> any of Instantiations' offerings, and they're probably very good.)


> > On a large scale Smalltalk project  for the credit card industry  I was
> > involved with we had a problem with memory leakage caused by unwanted
> > references being maintained to objects that should have been garbage
> > collected.

> > These were caused by a number of subtle programming errors that not been
> > identified and had built up over time.

> > These sort of issues can be a show stopper for big projects and can be very
> > difficult to sort out if identified late in the development cycle

> > However when this issue was idenitified as a problem we were able to get a
> > handle on it using  Behavior >> allInstances
> > and Object >> become: Being able to determine the instance count of any
> > object and remove it using become: enabled the sources of the problem to
> > tracked down and eliminated. ( VAST has multiAllinstances and multiBecome
> > that one would use in practice)

> > Development QA procedures were modified to check for zero instance count on
> > any new class added to the system when the application was exited.

> > I suspect that the same issues will arise in any project that uses Java or
> > any system that uses garbage collection.  However the reflection
> > capabilities of Java seem much less advanced. I can't see any obvious
> > equivalent of Behavior>>allInstances or Object>>become:.

> > Does such a mechanism exist in Java ?  if not this is could be another
> > argument to roll out in favour of Smaltalk.

> > We need as many of these arguments as we can muster in the present climate,
> > at least here the UK.

> > Peter Lawson
> > ----------------------------------------------------------------------------
> > Lawson Consulting Ltd
> > Cambridge UK.

--
---------------------------------------------------------------------

 The Smalltalk Idiom                     http://www.algebraist.com/
*********************************************************************
             "Smalltalk?  Yes, it's really that slick."
---------------------------------------------------------------------
Want to know more?  Check out
           http://www.dnsmith.com/SmallFAQ/
           http://www.object-arts.com/DolphinWhitePaper.htm
           http://st-www.cs.uiuc.edu/users/johnson/smalltalk/
*********************************************************************


Wed, 14 Jul 2004 10:55:28 GMT  
 Subtle Smalltalk advantage over Java ?


Quote:
> Out of curiousity -- not knowing IBM VAST at all -- does the fact
> that the VAST IDE is written in Java limit the capabilities of their
> Smalltalk at all?  Ditto reflection capabilities?

No and no. VAST is *not* written in Java. You have it backwards...VAJ is
written in Smalltalk.

-Eric



Wed, 14 Jul 2004 11:11:56 GMT  
 Subtle Smalltalk advantage over Java ?


Quote:
>Out of curiousity -- not knowing IBM VAST at all -- does the fact
>that the VAST IDE is written in Java limit the capabilities of their
>Smalltalk at all?  Ditto reflection capabilities?

>  --Jan

Other way around.  The VA Java IDE is written in VAST Smalltalk.

Quote:


>> Peter -

>> I'm certainly no Java Deity, but recently I've been toggling back and
>> forth between two projects, one VA/ST, the other VA/J.  Generally,
>> Java has very little in the way of the reflection capabilities a
>> Smalltalker gets used to, and those which it does provide are best
>> left unused (horrible performance).  The root cause is, imho, the lack
>> of a notion of class-side protocol.

>> Equivalents to #allInstances or #become: would surprise me.  But they
>> could be there, as I don't exactly go out of my way to delve any
>> deeper into J-land than I have to ;-)

>> If I discover anything further, I'll try to remember to post again.

>> Paul
>> (ps - in case anyone cares, having sampled a few Java IDEs, VA/J is
>> actually pretty good from a Smalltalker's perspective.  My second
>> favorite is a command line text editor ... .  But I haven't yet tried
>> any of Instantiations' offerings, and they're probably very good.)


>> > On a large scale Smalltalk project  for the credit card industry  I was
>> > involved with we had a problem with memory leakage caused by unwanted
>> > references being maintained to objects that should have been garbage
>> > collected.

>> > These were caused by a number of subtle programming errors that not been
>> > identified and had built up over time.

>> > These sort of issues can be a show stopper for big projects and can be very
>> > difficult to sort out if identified late in the development cycle

>> > However when this issue was idenitified as a problem we were able to get a
>> > handle on it using  Behavior >> allInstances
>> > and Object >> become: Being able to determine the instance count of any
>> > object and remove it using become: enabled the sources of the problem to
>> > tracked down and eliminated. ( VAST has multiAllinstances and multiBecome
>> > that one would use in practice)

>> > Development QA procedures were modified to check for zero instance count on
>> > any new class added to the system when the application was exited.

>> > I suspect that the same issues will arise in any project that uses Java or
>> > any system that uses garbage collection.  However the reflection
>> > capabilities of Java seem much less advanced. I can't see any obvious
>> > equivalent of Behavior>>allInstances or Object>>become:.

>> > Does such a mechanism exist in Java ?  if not this is could be another
>> > argument to roll out in favour of Smaltalk.

>> > We need as many of these arguments as we can muster in the present climate,
>> > at least here the UK.

>> > Peter Lawson
>> > ----------------------------------------------------------------------------
>> > Lawson Consulting Ltd
>> > Cambridge UK.

>--
>---------------------------------------------------------------------

> The Smalltalk Idiom                     http://www.algebraist.com/
>*********************************************************************
>             "Smalltalk?  Yes, it's really that slick."
>---------------------------------------------------------------------
>Want to know more?  Check out
>           http://www.dnsmith.com/SmallFAQ/
>           http://www.object-arts.com/DolphinWhitePaper.htm
>           http://st-www.cs.uiuc.edu/users/johnson/smalltalk/
>*********************************************************************

--
James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>


Wed, 14 Jul 2004 14:25:18 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Advantages of Smalltalk over Java

2. advantages and disadvantages of C++, Java and Smalltalk

3. Hello Smalltalk, bye bye Java (was Sprint: Hello Java, bye bye Smalltalk)

4. (Java success = Smalltalk death) or:[ Java + Smalltalk = Future ]

5. 5i advantage over java

6. Advantages/Disadvantages of Java

7. Advantages of Dylan over Java (second try)

8. Advantages of Dylan over Java

9. Advantages of Dylan over Java?

10. advantages of java?

11. Smalltalk vs Java, OBJS says Java wins.

12. smalltalk advantages and disadvantages

 

 
Powered by phpBB® Forum Software