Hi Folks,

Just a reminder that we are holding a special event THIS THURSDAY, Dec
17, to hear from several Googlers who are in Sydney at the moment,
talking all things shiny in GWT 2.0.

This event is proving popular, and so to help us manage the numbers,
please RSVP using the link below (but please DON'T print the ticket -
you don't need it).

Cheers,
-Brendan

*** RSVP Required ***

Please RSVP at http://sjug-gwt20.eventbrite.com

WHEN:

THIS Thursday December 17, 6:00pm.
Talk starts at 6:30pm

WHERE:

Atlassian HQ
173-185 Sussex Street (cnr Market)
Sydney CBD
http://maps.google.com.au/maps?q=173+Sussex+Street,+Sydney+NSW

TOPIC:

Show case of the new features of GWT 2.0, including Speed Tracer, code
splitting, UiBinder and ClientBundle.
Ray Ryan, Bob Vawter and Adam Schuck from Google.

Ray Ryan is part of the Google Web Toolkit team, and has been goading
people into writing software the way he thinks they should since the
1980s. He has worked at Lighthouse Design, Sun, AOL, and has spent the
last five years at Google. He had a strong hand in shaping the
architecture of the GWT-based user interface for AdWords, and recently
landed the UiBinder in GWT 2.0.

Bob Vawter contributes to the Google Web Toolkit in his role as a
Research Actualization Engineer.  After a couple of startups, Bob
landed at Google in 2005 and has been creating general solutions to
specific problems since then.  He is the primary author of the GWT
ClientBundle system as well as a number of compiler and toolchain
features.

Adam Schuck works on Google Wave as the Technical Lead of the client
team. Since commencing work at Google Sydney in February 2006, Adam
worked on Google Maps, having co-created Mapplets in 2007. Having
achieved a black-belt as a JavaScript ninja, Adam dusted off his Java
textbook, threw away his ninja uniform, and embraced the new art of
Google Web Toolkit.

Hi Folks,

Sorry for the short notice, but two of the Google GWT engineering team
are in town in December and have agreed to give a talk for us on their
recent GWT 2.0 release. Come along and hear Ray Ryan & Bob Vawter from
the GWT team talk about the new features of GWT 2.0, including Speed
Tracer, code splitting, UiBinder and ClientBundle.

Please RSVP at http://sjug-gwt20.eventbrite.com this time, so we get
the pizza right :-)

Cheers,
-Brendan

WHEN:

Thursday December 17, 6:00pm.
Talk starts at 6:30pm

WHERE:

Atlassian HQ
173-185 Sussex Street (cnr Market)
Sydney CBD
http://maps.google.com.au/maps?q=173+Sussex+Street,+Sydney+NSW

TOPIC:

Show case of the new features of GWT 2.0, including Speed Tracer, code
splitting, UiBinder and ClientBundle.
Ray Ryan & Bob Vawter from Google.


BEER and PIZZA provided

*** RSVP Required ***

Please RSVP at http://sjug-gwt20.eventbrite.com

Thanks for the replies.

By Java source, I mean the .java file that represents the declaration
of the interface.

In essence, I want to be able to perform structured edits on the Java
source by applying XSLT that codifies the edit to the source.

Admittedly, an IDE/AST-level approach is probably more valuable since
it could drive associated  refactorings on dependent class files in a
way that a file-oriented XSLT could not.

jon.

On Fri, Dec 11, 2009 at 12:42 AM, David Bullock <db@...> wrote:
> Hi Jon, sounds like one of those projects ... I don't know of any
> tools which do just that.
>
> Possibly you might get by with hacking an open-source Java-to-WSDL
> compiler, which is doing approximately what you seem to be
> contemplating, but modify the XML representation to suit your needs.
>
> Maybe you're looking at ANTLR or JavaCC to parse the Java source file
> (they both have community-contributed grammars for Java-the-langugage
> 5).  I have no experience of JavaCC and think ANTLR is groovy but I'd
> give some thought to tooling (how does it integrate into your
> edit/debug/build) which is my main ANTLR hesitation.  Bit of a
> learning curve though.
>
> Some of the IDE's (IntelliJ,Eclipse, Netbeans) probably also expose an
> object model for the structure of a source file.  If your problem fit
> nicely into an IDE, or your could use the IDE's
> source-code-object-model library standalone ... and were interested in
> writing a plugin one day, then this might be a way forward.
>
> Another approach would be to actually use javac API compile the class,
> chuck the bits at a classloader, and use reflection to get the method
> signatures.  That's actually pretty quick and dirty if the source
> files will compile.
>
>
> As you say, once you have got the data in XML, XSLT gets it back out
> again ... might as well get your XSLT engine emitting the actual Java
> code.
>
> thanks for the diversion,
> David.
>
>
> On Thu, Dec 10, 2009 at 1:55 AM, Jon Seymour <jon.seymour@...> wrote:
>> I am looking for a tool that allows me to transform the Java source of
>> an interface into an XML document and then go back the other way once
>> I have edited the source (using, say, XSLT). The round trip has to be
>> lossless.
>>
>> Is there a good way to do that these days?
>>
>> jon.
>>
>>
>> ------------------------------------
>>
>> To unsubscribe, send a message to
>> ajug-unsubscribe@egroups.com
>> Yahoo! Groups Links
>>
>>
>>
>>
>

Hi Jon, sounds like one of those projects ... I don't know of any
tools which do just that.

Possibly you might get by with hacking an open-source Java-to-WSDL
compiler, which is doing approximately what you seem to be
contemplating, but modify the XML representation to suit your needs.

Maybe you're looking at ANTLR or JavaCC to parse the Java source file
(they both have community-contributed grammars for Java-the-langugage
5).  I have no experience of JavaCC and think ANTLR is groovy but I'd
give some thought to tooling (how does it integrate into your
edit/debug/build) which is my main ANTLR hesitation.  Bit of a
learning curve though.

Some of the IDE's (IntelliJ,Eclipse, Netbeans) probably also expose an
object model for the structure of a source file.  If your problem fit
nicely into an IDE, or your could use the IDE's
source-code-object-model library standalone ... and were interested in
writing a plugin one day, then this might be a way forward.

Another approach would be to actually use javac API compile the class,
chuck the bits at a classloader, and use reflection to get the method
signatures.  That's actually pretty quick and dirty if the source
files will compile.


As you say, once you have got the data in XML, XSLT gets it back out
again ... might as well get your XSLT engine emitting the actual Java
code.

thanks for the diversion,
David.


On Thu, Dec 10, 2009 at 1:55 AM, Jon Seymour <jon.seymour@...> wrote:
> I am looking for a tool that allows me to transform the Java source of
> an interface into an XML document and then go back the other way once
> I have edited the source (using, say, XSLT). The round trip has to be
> lossless.
>
> Is there a good way to do that these days?
>
> jon.
>
>
> ------------------------------------
>
> To unsubscribe, send a message to
> ajug-unsubscribe@egroups.com
> Yahoo! Groups Links
>
>
>
>

I am looking for a tool that allows me to transform the Java source of
an interface into an XML document and then go back the other way once
I have edited the source (using, say, XSLT). The round trip has to be
lossless.

Is there a good way to do that these days?

jon.

Hi Folks,

Last SJUG of the year should be a cracker. Oliver Burn, Architect at
Fujitsu, founder of Checkstyle, talks build systems for control
freaks. Come along and cheer, heckle, or throw food.

Since this is the last SJUG for the year, I think we should also have
a beer or three afterward and discuss the finer points of Java's
trajectory over the year.

Cheers,
-Brendan
(only joking about throwing food)

WHERE:

Atlassian HQ
173-185 Sussex Street (cnr Market)
Sydney CBD
http://maps.google.com.au/maps?q=173+Sussex+Street,+Sydney+NSW

WHEN:

Thursday, December 10, 6:00pm for Pizza + Beer.
Talk starts at 6:30pm

WHO:

This event is free to attend. No RSVP is required.


TOPIC:

The Build System of a Control Freak
Oliver Burn

This talk, by a self-confessed Build System Control Freak, discusses
how to best leverage an application's build system to improve the
quality of the software being developed. The talk will walk through
some of the techniques, tools and tips he has accrued over time,
whilst carefully sidestepping the technology debate (e.g. Maven versus
ANT).

Oliver Burn is an Architect working for Fujitsu in Sydney and has been
responsible for establishing build systems for many years. Oliver is
the founder of the Checkstyle project, a development tool to help
programmers write Java code that adheres to coding standards.

I was, of course, assuming correct implementation of the value objects
themselves.

The errors I am interested in preventing are errors in the use of the
value objects.

In my scheme, Value objects refer to their Option objects by way of a
final reference which is initialized at construction time. The state
is actually contained in the implementation of the Option objects. The
Option objects may typically contain final references to the Option
interfaces of other value objects (to avoid the cost of cast when
using the methods of their Option interfaces) .

Now, the Option interfaces do have methods and in theory a dereference
to a null reference of one of these could cause a problem.

However, Option interfaces come with a simple rule:

    * references to them are never, under any circumstances initialized
or set to a null value.
    * they are never passed as method parameters
    * they are never returned from methods unless they are non-null.

These rules are easy to relatively easy to be dictatorial about - any
code that violates them is simply wrong and must be fixed. If you ever
think you need to store or pass a null reference to an Option, then
what you should be passing or storing instead is the reference to the
related value.

jon.

On Mon, Nov 30, 2009 at 4:21 PM, Esmond Pitt FACS
<esmond.pitt@...> wrote:
> What about such an object that contains a reference to another object?
>
> EJP

> If there is no call, there can be no NullPointerException

That's fallacious. If there is no *use* of the potentially null value there
can be no NullPointerException.

EJP

It appears you have applied a catamorphism to my use of the term
"functional languages" when instead I expected it to be applied to the
phrase "the year null" :-)

Anyway, thanks for the insight!

jon.

On 29/11/2009, at 15:33, Tony Morris <tmorris@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Jon,
> I don't quite understand what you mean, so I will clarify :)
>
> There is no such thing as a functional language. All turing-complete
> languages are functional to some extent. The thesis of functional
> programming is composition in the truest, measurable, not-wishy-washy
> sense of the term (see WhyFP, John Hughes). Some languages are
> amenable to this more than others. There are hundreds of languages in
> the world. Java is perhaps the least amenable to the thesis of
> functional programming, so you might say "Java is not a very
> functional language" or "Java does not permit the desires for the
> thesis of FP." Other languages, that are not very amenable to
> functional programming include C#, C, Ruby and Python. It's a
> continuum. Sitting near the top are languages like Haskell, Clean and
> CAL. Sacrificing turing-completeness, you can go even further with
> Coq, Agda or Isabelle.
>
> With this in mind, catamorphisms are a well known mathematical
> concept. *All* software developers write them all the time, regardless
> of language and regardless of how much the language gets in the way.
> To give an anecdote that may appear exaggerated, I have seen on
> multiple occasions, a catamorphism for a typical data structure that
> would normally be straight-forward turned into an "enterprise project"
> with funding for several developers.
>
> Going back to null, this is just a symptom of a very sick, impractical
> language. It's not fair to pick on null without picking on the whole
> language, but to point out each and every disaster is overwhelming, so
> let's just focus on one. The catamorphism I gave is for a particular
> data structure or a "shape" if you will. It is our responsibility as
> software developers, to recognise the shape of problems. The more
> rigorous we are in doing this, is a measure of our competence (imo).
> That data structure given is for what you might paraphrase as "the
> list with a maximum length of one."
>
> It's such a common data type, that almost all reasonable language
> define it. The name is usually Option or Maybe or some such. It is
> what should often (but not always) be used where null is unfortunately
> used. Null represents a concept of computability theory that has many
> names: undefined, bottom, _|_, non-terminating computation, logical
> absurdity, not even false. You can see the relationship to logic in
> what is called the Curry-Howard Isomorphism (an awesome piece of work
> with many opportunities for enlightenment).
>
> I hope this helps mate :)
>
> Jon Seymour wrote:
>>
>> Tony,
>>
>> It occurs to me is that what you are really saying is that
>> functional languages have known about catamorphism since the year
>> null.
>>
>> :-;
>>
>> jon.
>>
>> On 28/11/2009, at 11:57, Tony Morris <tmorris@...> wrote:
>>
>> Hey Jon, Haskell calls it Maybe, ML calls it option, Scala calls it
>> Option, Functional Java calls it Option. Note that it (the type
>> constructor) is a covariant functor and a monad. The catamorphism
>> is the important part. You can use languages that simply don't have
>> null, or assume language subsets without it (many Java users do).
>> You can also write in languages that guarantee termination i.e. all
>> total functions (with some sacrifices of course) e.g. Agda, Coq,
>> Isabelle.
>>
>> Jon Seymour wrote:
>>>>> Tony: thanks for the explanation in Functional Java - I just
>>>>> new there was going to be one :-)
>>>>>
>>>>> On Sat, Nov 28, 2009 at 7:48 AM, Peter Becker
>>>>> <peter@...> wrote:
>>>>>> Two problems with that:
>>>>>>
>>>>>> 1) it probably won't reduce the amount of business logic
>>>>>> needed, so
>> you just
>>>>>> move the code with potential NPEs somewhere else
>>>>>
>>>>> Actually, I think it does. Every check or failure to check
>>>>> for a
>> null
>>>>> value object is a potential runtime error. When the default
>>>>> handling of null that you are expecting the consumer of a
>>>>> value to implement can be expressed as an operation on the
>>>>> null reference you have
>>>>>
>>>>> a) eliminated the need the chance for the programmer to get
>>>>> it wrong b) eliminated the chance that the programmer will
>>>>> code too defensively.
>>>>>
>>>>> Date range handling is a classic case because there are 4
>>>>> nulls to worry about - the date range itself, the lower bound
>>>>> and the upper bound and the date value under test. Making
>>>>> sure the contains() test is implemented sanely when there are
>>>>> 4 things that could be null can generate a *lot* of code.
>>>>> Most of the time such code has untested corner cases that
>>>>> blowup under real conditions. I know this, I have seen such
>>>>> code [ and, if truth be told, probably even written
>> some ].
>>>>>
>>>>> Consider instead how simple things become if you make date
>>>>> range tests an operation between finite and infinite sets.
>>>>>
>>>>> For example, with my full Date range library, a date range
>>>>> test can be expressed like this:
>>>>>
>>>>> boolean inRange = Date.NEW.apply(from, to,
>>>>> INFINITE).contains(Date.new.apply(test));
>>>>>
>>>>> If the rule is that the test date, satisfies the date range
>>>>> conditions if it is specifies the specified finite bounds,
>>>>> that code gets its right, every time, with zero conditional
>>>>> logic in the consumer
>> of the
>>>>> library, zero null-safety issues and not much in the
>>>>> implementation (because finite and infinite intervals get
>>>>> their own implementations).
>>>>>
>>>>> That's a big saving.
>>>>>
>>>>>> 2) what you most likely want is proper value objects:
>>>>>> immutable and with value equality. In Java that
>>>>>> unfortunately requires
>> implementing two methods
>>>>>>
>>>>>
>>>>> I have dealt with this issue too.
>>>>>
>>>>> A Value interface extends Value<V>  (e.g. interface Interval
>>>>> extends Value<V> {} ).
>>>>>
>>>>> Value<V> deprecates (but still implements) equals(Object),
>>>>> compareTo(Comparable<Value>), toString(), hashCode(). These
>>>>> methods still do the useful thing - but the programmer gets a
>>>>> warning when they are doing it that way instead of:
>>>>>
>>>>> Date.OPS.apply(bound).equalTo(test);
>>>>>
>>>>> Regards,
>>>>>
>>>>> jon.
>>>>>
>>>>>
>>>>>> 2) what you most likely want is proper value objects:
>>>>>> immutable and with value equality. In Java that
>>>>>> unfortunately requires
>> implementing two methods
>>>>>>
>>>>>> Having said that: value objects are a great idea and OO's
>>>>>> encapsulation is overhyped. I just think it's not as easy
>>>>>> as you might think.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> Jon Seymour wrote:
>>>>>>> Or, The Zen Of Zero-Method Value Objects...
>>>>>>>
>>>>>>> I had an ephiphany the other day.
>>>>>>>
>>>>>>> The path to null-safety is the zero-method value object.
>>>>>>>
>>>>>>> Rationale: an interface that defines no methods cannot
>>>>>>> result in the generation of call-site that causes a
>>>>>>> NullPointerException for the simple reason that if there
>>>>>>> is no method, there can be no call. If there is no call,
>>>>>>> there can be no NullPointerException
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> For further exposition on this, read
>>>>>>> http://tinyurl.com/ylmjqx3 <http://tinyurl.com/ylmjqx3>
>>>>>>>
>>>>>>> jon.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFLEfm1mnpgrYe6r60RArzdAKDAJPVL7wyXYb/tnwTNrQmbboBgUwCfUAVc
> T4EpJIUmSe0hopJQN0RBc3c=
> =7KeM
> -----END PGP SIGNATURE-----
>

Tony,

It occurs to me is that what you are really saying is that functional
languages have known about catamorphism since the year null.

:-;

jon.

On 28/11/2009, at 11:57, Tony Morris <tmorris@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hey Jon,
> Haskell calls it Maybe, ML calls it option, Scala calls it Option,
> Functional Java calls it Option. Note that it (the type constructor)
> is a covariant functor and a monad. The catamorphism is the important
> part. You can use languages that simply don't have null, or assume
> language subsets without it (many Java users do). You can also write
> in languages that guarantee termination i.e. all total functions (with
> some sacrifices of course) e.g. Agda, Coq, Isabelle.
>
> Jon Seymour wrote:
>> Tony: thanks for the explanation in Functional Java - I just new
>> there
>> was going to be one :-)
>>
>> On Sat, Nov 28, 2009 at 7:48 AM, Peter Becker
>> <peter@...> wrote:
>>> Two problems with that:
>>>
>>> 1) it probably won't reduce the amount of business logic needed, so
> you just
>>> move the code with potential NPEs somewhere else
>>
>> Actually, I think it does. Every check or failure to check for a null
>> value object is a potential runtime error. When the default handling
>> of null that you are expecting the consumer of a value to implement
>> can be expressed as an operation on the null reference you have
>>
>>   a) eliminated the need the chance for the programmer to get it
>> wrong
>>   b) eliminated the chance that the programmer will code too
>> defensively.
>>
>> Date range handling is a classic case because there are 4 nulls to
>> worry about - the date range itself, the lower bound and the upper
>> bound and the date value under test. Making sure the contains() test
>> is implemented sanely when there are 4 things that could be null can
>> generate a *lot* of code. Most of the time such code has untested
>> corner cases that blowup under real conditions. I know this, I have
>> seen such code [ and, if truth be told, probably even written some ].
>>
>> Consider instead how simple things become if you make date range
>> tests
>> an operation between finite and infinite sets.
>>
>> For example, with my full Date range library, a date range test can
>> be
>> expressed like this:
>>
>>           boolean inRange = Date.NEW.apply(from, to,
>> INFINITE).contains(Date.new.apply(test));
>>
>> If the rule is that the test date, satisfies the date range
>> conditions
>> if it is specifies the specified finite bounds, that code gets its
>> right, every time, with zero conditional logic in the consumer of the
>> library, zero null-safety issues and not much in the implementation
>> (because finite and infinite intervals get their own
>> implementations).
>>
>> That's a big saving.
>>
>>> 2) what you most likely want is proper value objects: immutable
>>> and with
>>> value equality. In Java that unfortunately requires implementing two
> methods
>>>
>>
>> I have dealt with this issue too.
>>
>> A Value interface extends Value<V>  (e.g. interface Interval extends
>> Value<V> {} ).
>>
>> Value<V> deprecates (but still implements) equals(Object),
>> compareTo(Comparable<Value>), toString(), hashCode(). These methods
>> still do the useful thing - but the programmer gets a warning when
>> they are doing it that way instead of:
>>
>>    Date.OPS.apply(bound).equalTo(test);
>>
>> Regards,
>>
>> jon.
>>
>>
>>> 2) what you most likely want is proper value objects: immutable
>>> and with
>>> value equality. In Java that unfortunately requires implementing two
> methods
>>>
>>> Having said that: value objects are a great idea and OO's
>>> encapsulation is
>>> overhyped. I just think it's not as easy as you might think.
>>>
>>> Peter
>>>
>>>
>>> Jon Seymour wrote:
>>>> Or, The Zen Of Zero-Method Value Objects...
>>>>
>>>> I had an ephiphany the other day.
>>>>
>>>> The path to null-safety is the zero-method value object.
>>>>
>>>> Rationale: an interface that defines no methods cannot result in
>>>> the
>>>> generation of call-site that causes a NullPointerException for the
>>>> simple reason that if there is no method, there can be no call. If
>>>> there is no call, there can be no NullPointerException
>>>>
>>>> ...
>>>>
>>>> For further exposition on this, read http://tinyurl.com/ylmjqx3
>>>> <http://tinyurl.com/ylmjqx3>
>>>>
>>>> jon.
>>>>
>>>>
>>>
>>
>>
>>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFLEHWKmnpgrYe6r60RAh2cAJ9SLhhSaLmHNdIqoEbyGY1zRIGw2QCgm/Mt
> 6nrOckNjYFjkIVab0sjR2Y0=
> =nVOy
> -----END PGP SIGNATURE-----
>

Tony: thanks for the explanation in Functional Java - I just new there
was going to be one :-)

On Sat, Nov 28, 2009 at 7:48 AM, Peter Becker <peter@...> wrote:
> Two problems with that:
>
> 1) it probably won't reduce the amount of business logic needed, so you just
> move the code with potential NPEs somewhere else

Actually, I think it does. Every check or failure to check for a null
value object is a potential runtime error. When the default handling
of null that you are expecting the consumer of a value to implement
can be expressed as an operation on the null reference you have

    a) eliminated the need the chance for the programmer to get it wrong
    b) eliminated the chance that the programmer will code too defensively.

Date range handling is a classic case because there are 4 nulls to
worry about - the date range itself, the lower bound and the upper
bound and the date value under test. Making sure the contains() test
is implemented sanely when there are 4 things that could be null can
generate a *lot* of code. Most of the time such code has untested
corner cases that blowup under real conditions. I know this, I have
seen such code [ and, if truth be told, probably even written some ].

Consider instead how simple things become if you make date range tests
an operation between finite and infinite sets.

For example, with my full Date range library, a date range test can be
expressed like this:

            boolean inRange = Date.NEW.apply(from, to,
INFINITE).contains(Date.new.apply(test));

If the rule is that the test date, satisfies the date range conditions
if it is specifies the specified finite bounds, that code gets its
right, every time, with zero conditional logic in the consumer of the
library, zero null-safety issues and not much in the implementation
(because finite and infinite intervals get their own implementations).

That's a big saving.

> 2) what you most likely want is proper value objects: immutable and with
> value equality. In Java that unfortunately requires implementing two methods
>

  I have dealt with this issue too.

A Value interface extends Value<V>  (e.g. interface Interval extends
Value<V> {} ).

Value<V> deprecates (but still implements) equals(Object),
compareTo(Comparable<Value>), toString(), hashCode(). These methods
still do the useful thing - but the programmer gets a warning when
they are doing it that way instead of:

     Date.OPS.apply(bound).equalTo(test);

Regards,

jon.


> 2) what you most likely want is proper value objects: immutable and with
> value equality. In Java that unfortunately requires implementing two methods
>
> Having said that: value objects are a great idea and OO's encapsulation is
> overhyped. I just think it's not as easy as you might think.
>
> Peter
>
>
> Jon Seymour wrote:
>>
>> Or, The Zen Of Zero-Method Value Objects...
>>
>> I had an ephiphany the other day.
>>
>> The path to null-safety is the zero-method value object.
>>
>> Rationale: an interface that defines no methods cannot result in the
>> generation of call-site that causes a NullPointerException for the
>> simple reason that if there is no method, there can be no call. If
>> there is no call, there can be no NullPointerException
>>
>> ...
>>
>> For further exposition on this, read http://tinyurl.com/ylmjqx3
>> <http://tinyurl.com/ylmjqx3>
>>
>> jon.
>>
>>
>
>

Two problems with that:

1) it probably won't reduce the amount of business logic needed, so you
just move the code with potential NPEs somewhere else
2) what you most likely want is proper value objects: immutable and with
value equality. In Java that unfortunately requires implementing two methods

Having said that: value objects are a great idea and OO's encapsulation
is overhyped. I just think it's not as easy as you might think.

Peter


Jon Seymour wrote:
>
> Or, The Zen Of Zero-Method Value Objects...
>
> I had an ephiphany the other day.
>
> The path to null-safety is the zero-method value object.
>
> Rationale: an interface that defines no methods cannot result in the
> generation of call-site that causes a NullPointerException for the
> simple reason that if there is no method, there can be no call. If
> there is no call, there can be no NullPointerException
>
> ...
>
> For further exposition on this, read http://tinyurl.com/ylmjqx3
> <http://tinyurl.com/ylmjqx3>
>
> jon.
>
>

Or, The Zen Of Zero-Method Value Objects...

I had an ephiphany the other day.

The path to null-safety is the zero-method value object.

Rationale: an interface that defines no methods cannot result in the
generation of call-site that causes a NullPointerException for the
simple reason that if there is no method, there can be no call. If
there is no call, there can be no NullPointerException

...

For further exposition on this, read http://tinyurl.com/ylmjqx3

jon.

Hi folks,

Just a reminder that the next SJUG will be TONIGHT - Thursday,
November 12, with Jonas Karlsson from Google talking Google Megastore
and infinite scalability in Java. Should be a cracker.  This event is
free and no RSVP is required.

Cheers,
-Brendan

WHERE:

Atlassian HQ
173-185 Sussex Street (cnr Market)
Sydney CBD
http://maps.google.com.au/maps?q=173+Sussex+Street,+Sydney+NSW

WHEN:

TONIGHT - Thursday, November 12, 6:00pm for Pizza + Beer.
Talk starts at 6:30pm

TOPIC:

Google Megastore and Infinite Scalability in Java
Jonas S Karlsson

Jonas will talk about Google Megastore and how to scale web apps and
underlying principle of scalability of storage and data processing to
millions of users on many thousands of machines. The talk is based on
experiences with Google Megastore and many applications that is has
enabled to scale seamlessly, while maintaining user consistency. He
will counter with experiences of the Megastore system design over time
and choices made to streamline performance for apps like AppEngine.


Jonas designs and implements database kernels, scalable distributed
storage, and interpreters in various languages. He's worked on
implementing DB2 in 200KB for the Palm Pilot and other embedded
devices. Later he worked on Cloudscape when it was transitioning to
become open source Apache Derby. In 2004 he joined Google, where he
worked in the ads backend, was one of the original creators of Google
Megastore, and is currently working on indexing reliability on Google
Wave in the Sydney office. When he doesn't work, he's trying to figure
out how to integrate work, programming, Zen meditation, and life. He
occasionally hacks on his functional declarative optimizing query
programming language interpreter. Getting a motorcycle again might be
on the agenda.