This post originated from an RSS feed registered with Java Buzz
by James Gosling.
Original Post: Only solve the problems you need to solve
Feed Title: James Gosling: on the Java road...
Feed URL: /jag/feed/entries/rss?cat=%2FJava
Feed Description: I've been inescapably tagged as "the Java guy", despite the fact that I havn't worked in the Java product organization for a couple of years (I do still kibbitz). These days I work at Sun's research lab about two thirds of the time, and do customer visits and talks the other third. For more detail...
Back when I was a grad student I was spinning out of control trying to
come up with a thesis topic. My advisor
took me out to lunch one day and asked me a simple question: "What is a
PhD thesis?" I yattered on for a while and he listened patiently.
Eventually he said "No: It's just a stack of 100 pages with 4 signatures
on top". I was falling into a common grad student trap of feeling that I
needed to do something grandiose and solve all of the worlds problems. He
was into "keep it simple". So I did, and I came up with a pretty
straightforward thesis proposal. The odd thing was that when I finally
finished my thesis, I realized that I had only delt with one sentence out
of the simplified proposal.
I got a lot of email about my previous post, a lot of it centered on
JINI, RMI and CORBA. Not too many months ago, during the hypon flux
storm [by analogy with bogon
flux] surrounding SOA and Web Services it was worth one's life to
mention that folks had been successfully implementing SOAs for years.
That has calmed down significantly. JINI
is particularly interesting since it goes significantly beyond what's
possible with today's SOA - but it only works in a Java-only universe.
The folks who developed RMI/JINI had previously worked on CORBA. A big
chunk of the complexity of CORBA comes from trying to solve the
cross-language problem. They discovered that if you don't try to solve
that problem, some very cool things emerge. The poster child for
building SOAs on JINI is Orbitz.
There are some interesting discussions here
and here.
In response to the comment about OO and granularity: they really are
orthogonal axes. OO methodologies work well regardless of granularity.
But granularity is related to the question of whether or not an
operation can sensibly involve a network transit: it only works well
when granularity is high. This is a direct corollary of the Eight
Fallicies of Distributed Computing.
Previous Topic
Back when I was a grad student I was spinning out of control trying to
come up with a thesis topic. My