Thread: [Prevayler-coders] Codehaus CVS converted to Subversion

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Prevayler's old Codehaus CVS repository has been converted to
Subversion. Instructions here:

http://xircles.codehaus.org/projects/prevayler/repo

Cheers,
Justin

Hi Justin,

I've just checked it out.  I haven't tried to check anything in.  Actually, I'm 
not sure how that's possible unless we have username/password set up?  But with 
the old setup, it was passe to use a password.  Instead, we used username + SSH2 
public key.  Has codehaus now gone back to username/password?

In any case, I looked at the difference between the tagged Prevayler_2_3 code and 
the trunk.  It's really the same except for a whole bunch of new extraneous and, 
to my eyes, unnecessary exception classes that do little more than bloat the 
codebase.  I wonder if we shouldn't roll the trunk back to the Prevayler_2_3 code 
and start moving forward from there?

After that, what is the plan?  Do we continue forward with the 2.3 codebase, 
keeping full compatibility for users of 2.3?  Do we enhance 2.3 with the JSE 1.5+ 
goodies, but keep essentially the same codebase?  Do we start with the 2.3 
codebase and make radical changes to it, which would probably require significant 
changes to programs using 2.3?  And, finally, if we were to choose the latter 
option, would we simply want to rewrite from scratch?  I think the latter option 
has been tried and, for reasons I don't fully understand, abandoned.

Justin, can you fill us in on your vision for Prevayler?  I'd say Klaus (and 
others) too, but Klaus seems to defer to Justin of late and Justin has been the 
most active and influential developer of the Prevayler codebase over the last few 
years.

Jake

Justin T. Sampson wrote:
> Prevayler's old Codehaus CVS repository has been converted to
> Subversion. Instructions here:
> 
> http://xircles.codehaus.org/projects/prevayler/repo
> 
> Cheers,
> Justin
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Prevayler-coders mailing list
> Pre...@li...
> https://lists.sourceforge.net/lists/listinfo/prevayler-coders
> 
> 
> 

On Thu, Apr 3, 2008 at 11:36 PM, Jacob Kjome <ho...@vi...> wrote:

> I've just checked it out.  I haven't tried to check anything in.  Actually, I'm
> not sure how that's possible unless we have username/password set up?  But with
> the old setup, it was passe to use a password.  Instead, we used username + SSH2
> public key.  Has codehaus now gone back to username/password?

I actually don't know. I haven't tried committing either.

I've imported both the codehaus.org and the prevayler.org Subversion
repositories into local Git repositories on my machine to start poking
around. I'd love to start using Git for Prevayler development, but I
also don't want my slowness (or silliness) at rolling it out to impede
anyone else, so if you've got something to start committing, let's
figure out which of those two Subversion repos you can commit to.

Is there something you're itching to work on / commit?

> In any case, I looked at the difference between the tagged Prevayler_2_3 code and
> the trunk.  It's really the same except for a whole bunch of new extraneous and,
> to my eyes, unnecessary exception classes that do little more than bloat the
> codebase.

I actually quite like them. :) There's further exception work in early
revisions on the prevayler.org Subversion as well, which I was
considering pulling along too. Prevayler 2.3 and earlier would throw
bare Error, RuntimeException, etc., relying on the message to
distinguish different conditions; in my humble opinion, distinct
exception classes for distinct exceptional conditions are clearer and
easier to program against.

> I wonder if we shouldn't roll the trunk back to the Prevayler_2_3 code
> and start moving forward from there?
>
> After that, what is the plan?  Do we continue forward with the 2.3 codebase,
> keeping full compatibility for users of 2.3?  Do we enhance 2.3 with the JSE 1.5+
> goodies, but keep essentially the same codebase?

I'm generally in favor of complete backwards-compatibility. At least
source-level -- I'm not too concerned about requiring users to
recompile, but they shouldn't have to change their code. I actually
managed to accomplish that in the Java 5 experimental branch I was
working on: Even with major changes to the core interfaces, I retained
interfaces identical to the old ones with thin wrappers around the new
ones.

My inclination is to include the first few revisions from my
experimental branch, up to just before I did anything with Java 5, as
there are a handful of code cleanups there that I'm happy with.

> Do we start with the 2.3
> codebase and make radical changes to it, which would probably require significant
> changes to programs using 2.3?  And, finally, if we were to choose the latter
> option, would we simply want to rewrite from scratch?  I think the latter option
> has been tried and, for reasons I don't fully understand, abandoned.

Well, Klaus had started a rewrite to experiment with different ways of
factoring the code, to have a super-simple core with everything else
as modules built on top, because he was dissatisfied with the
complexity of Prevayler 2. I, on the other hand, was fairly pleased
with Prevayler 2, and saw it as robust, fast, stable, peer-reviewed,
and about as simple as possible given the capabilities it supports.
So, given the options of 1. an experimental branch that was barely
working yet and 2. a stable branch that seemed just fine, I chose
Prevayler 2.3 as a basis for my own additional work. You might almost
call that a "fork" of the project, though interestingly it was the
original founder who wanted a radical fork and the new guy who wanted
to keep hacking the existing code. :)

In the end, though, *both* Klaus's rewrite branch and my Java 5 branch
have been "abandoned", in the sense that neither has received any more
work for the past year-plus, and neither is close to being released.

> Justin, can you fill us in on your vision for Prevayler?  I'd say Klaus (and
> others) too, but Klaus seems to defer to Justin of late and Justin has been the
> most active and influential developer of the Prevayler codebase over the last few
> years.

Just as a bit of explanation, I hack most actively on Prevayler when
I'm using it in a project, and unfortunately my current project (past
1.5 years) is using PHP/MySQL. :( That said, I actually think
Prevayler 2.3 is at a kind of plateau, in that it has just the right
functionality for a large class of applications. There's very little
that it *needs* as a product. If I were starting a Java project today,
I'd use Prevayler 2.3 without hesitation and don't think I'd crave any
particular enhancements.

The kinds of things people occasionally ask for are...

* Tuning parameters (like, don't sync the journal, to trade off safety
for speed).

* Maintenance tools (for cleaning out old journals and such).

* Some kind of replication.

One thing that no one asks for, but that I'd like to see myself, is
some kind of static analysis for the correctness of user code.

The biggest public relations win would be a solid replication
implementation. The biggest actual usability win, I think, would be
static analysis. The first addresses concerns about scalability; the
second addresses concerns about human imperfection. ;) Both are
serious concerns that very smart, pro-Prevayler people have raised,
while other things like tuning and maintenance tools are nice-to-have
but not "show-stoppers".

Cheers,
Justin

On Fri, 4 Apr 2008 09:08:58 -0700
  "Justin T. Sampson" <ju...@kr...> wrote:
> On Thu, Apr 3, 2008 at 11:36 PM, Jacob Kjome <ho...@vi...> wrote:
> 
>> I've just checked it out.  I haven't tried to check anything in.  Actually, 
>>I'm
>> not sure how that's possible unless we have username/password set up?  But 
>>with
>> the old setup, it was passe to use a password.  Instead, we used username + 
>>SSH2
>> public key.  Has codehaus now gone back to username/password?
> 
> I actually don't know. I haven't tried committing either.
> 
> I've imported both the codehaus.org and the prevayler.org Subversion
> repositories into local Git repositories on my machine to start poking
> around. I'd love to start using Git for Prevayler development, but I
> also don't want my slowness (or silliness) at rolling it out to impede
> anyone else, so if you've got something to start committing, let's
> figure out which of those two Subversion repos you can commit to.
> 
> Is there something you're itching to work on / commit?
> 

Actually, no, not at the moment.  But it would be nice to figure this out now 
so that if/when there is something to commit, it can be committed.

>> In any case, I looked at the difference between the tagged Prevayler_2_3 
>>code and
>> the trunk.  It's really the same except for a whole bunch of new extraneous 
>>and,
>> to my eyes, unnecessary exception classes that do little more than bloat the
>> codebase.
> 
> I actually quite like them. :) There's further exception work in early
> revisions on the prevayler.org Subversion as well, which I was
> considering pulling along too. Prevayler 2.3 and earlier would throw
> bare Error, RuntimeException, etc., relying on the message to
> distinguish different conditions; in my humble opinion, distinct
> exception classes for distinct exceptional conditions are clearer and
> easier to program against.
> 

Hmm....  Creating our own SkaringaError for errors coming from the 
SkaringaSerializer seems overkill to me.  Personally, I'd limit custom 
exceptions to checked exceptions other than maybe general 
PrevaylerRuntimeException and PrevaylerError classes.

>> I wonder if we shouldn't roll the trunk back to the Prevayler_2_3 code
>> and start moving forward from there?
>>
>> After that, what is the plan?  Do we continue forward with the 2.3 codebase,
>> keeping full compatibility for users of 2.3?  Do we enhance 2.3 with the JSE 
>>1.5+
>> goodies, but keep essentially the same codebase?
> 
> I'm generally in favor of complete backwards-compatibility. At least
> source-level -- I'm not too concerned about requiring users to
> recompile, but they shouldn't have to change their code. I actually
> managed to accomplish that in the Java 5 experimental branch I was
> working on: Even with major changes to the core interfaces, I retained
> interfaces identical to the old ones with thin wrappers around the new
> ones.
> 
> My inclination is to include the first few revisions from my
> experimental branch, up to just before I did anything with Java 5, as
> there are a handful of code cleanups there that I'm happy with.
> 

I'd be ok with this.  Any break in compatibility, if desireable, should come 
in a Prevayler 3.0.

>> Do we start with the 2.3
>> codebase and make radical changes to it, which would probably require 
>>significant
>> changes to programs using 2.3?  And, finally, if we were to choose the 
>>latter
>> option, would we simply want to rewrite from scratch?  I think the latter 
>>option
>> has been tried and, for reasons I don't fully understand, abandoned.
> 
> Well, Klaus had started a rewrite to experiment with different ways of
> factoring the code, to have a super-simple core with everything else
> as modules built on top, because he was dissatisfied with the
> complexity of Prevayler 2. I, on the other hand, was fairly pleased
> with Prevayler 2, and saw it as robust, fast, stable, peer-reviewed,
> and about as simple as possible given the capabilities it supports.
> So, given the options of 1. an experimental branch that was barely
> working yet and 2. a stable branch that seemed just fine, I chose
> Prevayler 2.3 as a basis for my own additional work. You might almost
> call that a "fork" of the project, though interestingly it was the
> original founder who wanted a radical fork and the new guy who wanted
> to keep hacking the existing code. :)
> 

Yes, somewhat ironic :-)  Klaus goes so far (even in another reply on this 
thread) to say that the codehaus repository should be done away with entirely. 
 At a minimum, it should be made read-only.  And if the concern is confusion 
over where it is hosted, it could be brought to prevayler.org and stored there 
as read-only with a separate writable source tree.  I think doing away with 
the old stuff is disrespectful to the users who might want to access it for 
whatever reason.

> In the end, though, *both* Klaus's rewrite branch and my Java 5 branch
> have been "abandoned", in the sense that neither has received any more
> work for the past year-plus, and neither is close to being released.
> 
>> Justin, can you fill us in on your vision for Prevayler?  I'd say Klaus (and
>> others) too, but Klaus seems to defer to Justin of late and Justin has been 
>>the
>> most active and influential developer of the Prevayler codebase over the 
>>last few
>> years.
> 
> Just as a bit of explanation, I hack most actively on Prevayler when
> I'm using it in a project, and unfortunately my current project (past
> 1.5 years) is using PHP/MySQL. :( That said, I actually think
> Prevayler 2.3 is at a kind of plateau, in that it has just the right
> functionality for a large class of applications. There's very little
> that it *needs* as a product. If I were starting a Java project today,
> I'd use Prevayler 2.3 without hesitation and don't think I'd crave any
> particular enhancements.
> 
> The kinds of things people occasionally ask for are...
> 
> * Tuning parameters (like, don't sync the journal, to trade off safety
> for speed).
> 
> * Maintenance tools (for cleaning out old journals and such).
> 
> * Some kind of replication.
> 
> One thing that no one asks for, but that I'd like to see myself, is
> some kind of static analysis for the correctness of user code.
> 
> The biggest public relations win would be a solid replication
> implementation. The biggest actual usability win, I think, would be
> static analysis. The first addresses concerns about scalability; the
> second addresses concerns about human imperfection. ;) Both are
> serious concerns that very smart, pro-Prevayler people have raised,
> while other things like tuning and maintenance tools are nice-to-have
> but not "show-stoppers".
> 

I think creating a working transparent wrapper around Prevayler to abstract 
away manually creating transactions would interest people.  There's at least 
two or three projects out there that attempt to do this, including the 
transactionsFacade contrib project in Prevayler 2.3.  I've seen lots of people 
say that Prevayler is great, but that writing individual transactions for 
everything is a pain.  Being able to use Prevayler transparently would go a 
long way to bringing in new users.

I'm just hoping to see Prevayler move forward.  Stale projects die for lack of 
interest and lack of support.  While Prevayler is useful in its current state, 
it needs to be kept up to date and advanced.  The start of that is to figure 
out where/how the soruce tree is to be set up and actually be available for 
commits.  If this simple task is left undone, Prevayler will whither away.

Jake

> Cheers,
> Justin
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Prevayler-coders mailing list
> Pre...@li...
> https://lists.sourceforge.net/lists/listinfo/prevayler-coders
> 

On Fri, Apr 4, 2008 at 11:46 AM, Jacob Kjome <ho...@vi...> wrote:

>  Hmm....  Creating our own SkaringaError for errors coming from the
>  SkaringaSerializer seems overkill to me.  Personally, I'd limit custom
>  exceptions to checked exceptions other than maybe general
>  PrevaylerRuntimeException and PrevaylerError classes.

I'm sure I had good reasons for each of them. :) I'll review and
document them as I roll them forward and see if we can come to some
consensus.

Part of the problem is that Java is pretty inconsistent about what
exactly "errors", "runtime exceptions", and "checked exceptions"
*mean*, so different projects come up with their own definitions. The
only thing the language *enforces* is that checked exceptions are
caught or declared, while runtime exceptions and errors aren't. (And
Java 5 generics offer a loophole even to that enforcement.) Other
kinds of semantics that are conceptually attached include the
distinction between "abstraction-preserving" and
"abstraction-violating" conditions (I'm not sure if I made up those
terms myself or heard them somewhere) -- an OutOfMemoryError (which is
an Error) is abstraction-violating, in the sense that it's not
triggered by the abstract semantics of your code, but rather by the
physical limitations of your machine; whereas a NullPointerException
(which is a RuntimeException) is abstraction-preserving, because it
*is* triggered by the abstract semantics of your code, and will happen
regardless of the physical limitations of your machine.

So anyway, I was trying to stick to a particular set of
interpretations / distinctions that would 1. make the usage of
exceptions etc. consistent throughout the Prevayler code and 2. not
conflict with any reasonable usage of exceptions in user code. In some
cases those goals suggested using e.g. an Error instead of a
RuntimeException, or introducing a distinct exception subclass, or
even changing code that previously used an exception to use another
mechanism entirely instead.

(This experience and the generics experience have both fomented in me
a strong preference for dynamically-typed languages...)

Cheers,
Justin

Justin is spot on.

I am in favor of GIT too.

Until Justin moves us to GIT, please forget the codehaus repository.
Use the prevayler.org repository.

If someone can make the codehaus repository disappear, I will be grateful.

Thanks, Klaus.

On Fri, Apr 4, 2008 at 1:08 PM, Justin T. Sampson <ju...@kr...> wrote:
> On Thu, Apr 3, 2008 at 11:36 PM, Jacob Kjome <ho...@vi...> wrote:
>
>  > I've just checked it out.  I haven't tried to check anything in.  Actually, I'm
>  > not sure how that's possible unless we have username/password set up?  But with
>  > the old setup, it was passe to use a password.  Instead, we used username + SSH2
>  > public key.  Has codehaus now gone back to username/password?
>
>  I actually don't know. I haven't tried committing either.
>
>  I've imported both the codehaus.org and the prevayler.org Subversion
>  repositories into local Git repositories on my machine to start poking
>  around. I'd love to start using Git for Prevayler development, but I
>  also don't want my slowness (or silliness) at rolling it out to impede
>  anyone else, so if you've got something to start committing, let's
>  figure out which of those two Subversion repos you can commit to.
>
>  Is there something you're itching to work on / commit?
>
>
>  > In any case, I looked at the difference between the tagged Prevayler_2_3 code and
>  > the trunk.  It's really the same except for a whole bunch of new extraneous and,
>  > to my eyes, unnecessary exception classes that do little more than bloat the
>  > codebase.
>
>  I actually quite like them. :) There's further exception work in early
>  revisions on the prevayler.org Subversion as well, which I was
>  considering pulling along too. Prevayler 2.3 and earlier would throw
>  bare Error, RuntimeException, etc., relying on the message to
>  distinguish different conditions; in my humble opinion, distinct
>  exception classes for distinct exceptional conditions are clearer and
>  easier to program against.
>
>
>  > I wonder if we shouldn't roll the trunk back to the Prevayler_2_3 code
>  > and start moving forward from there?
>  >
>  > After that, what is the plan?  Do we continue forward with the 2.3 codebase,
>  > keeping full compatibility for users of 2.3?  Do we enhance 2.3 with the JSE 1.5+
>  > goodies, but keep essentially the same codebase?
>
>  I'm generally in favor of complete backwards-compatibility. At least
>  source-level -- I'm not too concerned about requiring users to
>  recompile, but they shouldn't have to change their code. I actually
>  managed to accomplish that in the Java 5 experimental branch I was
>  working on: Even with major changes to the core interfaces, I retained
>  interfaces identical to the old ones with thin wrappers around the new
>  ones.
>
>  My inclination is to include the first few revisions from my
>  experimental branch, up to just before I did anything with Java 5, as
>  there are a handful of code cleanups there that I'm happy with.
>
>
>  > Do we start with the 2.3
>  > codebase and make radical changes to it, which would probably require significant
>  > changes to programs using 2.3?  And, finally, if we were to choose the latter
>  > option, would we simply want to rewrite from scratch?  I think the latter option
>  > has been tried and, for reasons I don't fully understand, abandoned.
>
>  Well, Klaus had started a rewrite to experiment with different ways of
>  factoring the code, to have a super-simple core with everything else
>  as modules built on top, because he was dissatisfied with the
>  complexity of Prevayler 2. I, on the other hand, was fairly pleased
>  with Prevayler 2, and saw it as robust, fast, stable, peer-reviewed,
>  and about as simple as possible given the capabilities it supports.
>  So, given the options of 1. an experimental branch that was barely
>  working yet and 2. a stable branch that seemed just fine, I chose
>  Prevayler 2.3 as a basis for my own additional work. You might almost
>  call that a "fork" of the project, though interestingly it was the
>  original founder who wanted a radical fork and the new guy who wanted
>  to keep hacking the existing code. :)
>
>  In the end, though, *both* Klaus's rewrite branch and my Java 5 branch
>  have been "abandoned", in the sense that neither has received any more
>  work for the past year-plus, and neither is close to being released.
>
>
>  > Justin, can you fill us in on your vision for Prevayler?  I'd say Klaus (and
>  > others) too, but Klaus seems to defer to Justin of late and Justin has been the
>  > most active and influential developer of the Prevayler codebase over the last few
>  > years.
>
>  Just as a bit of explanation, I hack most actively on Prevayler when
>  I'm using it in a project, and unfortunately my current project (past
>  1.5 years) is using PHP/MySQL. :( That said, I actually think
>  Prevayler 2.3 is at a kind of plateau, in that it has just the right
>  functionality for a large class of applications. There's very little
>  that it *needs* as a product. If I were starting a Java project today,
>  I'd use Prevayler 2.3 without hesitation and don't think I'd crave any
>  particular enhancements.
>
>  The kinds of things people occasionally ask for are...
>
>  * Tuning parameters (like, don't sync the journal, to trade off safety
>  for speed).
>
>  * Maintenance tools (for cleaning out old journals and such).
>
>  * Some kind of replication.
>
>  One thing that no one asks for, but that I'd like to see myself, is
>  some kind of static analysis for the correctness of user code.
>
>  The biggest public relations win would be a solid replication
>  implementation. The biggest actual usability win, I think, would be
>  static analysis. The first addresses concerns about scalability; the
>  second addresses concerns about human imperfection. ;) Both are
>  serious concerns that very smart, pro-Prevayler people have raised,
>  while other things like tuning and maintenance tools are nice-to-have
>  but not "show-stoppers".
>
>  Cheers,
>  Justin
>
>
>
>  -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>  _______________________________________________
>  Prevayler-coders mailing list
>  Pre...@li...
>  https://lists.sourceforge.net/lists/listinfo/prevayler-coders
>

>  I am in favor of GIT too...

...because it is more in the spirit of sovereign computing.

>  > In any case, I looked at the difference between the tagged Prevayler_2_3 code and
>  > the trunk.  It's really the same except for a whole bunch of new extraneous and,
>  > to my eyes, unnecessary exception classes that do little more than bloat the
>  > codebase.
>
>  I actually quite like them. :) There's further exception work in early
>  revisions on the prevayler.org Subversion as well, which I was
>  considering pulling along too. Prevayler 2.3 and earlier would throw
>  bare Error, RuntimeException, etc., relying on the message to
>  distinguish different conditions; in my humble opinion, distinct
>  exception classes for distinct exceptional conditions are clearer and
>  easier to program against.

When looking at that sugested API, even being a generics user myself,
I was overwhelmed by generics, exceptions and annotations.

See you, Klaus.

On Fri, Apr 4, 2008 at 9:48 AM, Klaus Wuestefeld
<kla...@gm...> wrote:

>  When looking at that sugested API, even being a generics user myself,
>  I was overwhelmed by generics, exceptions and annotations.

The generics were definitely overwhelming, which is why I was
disheartened by the whole affair. My initial fantasy was that they'd
be simple and clear, with Prevayler parameterized with the prevalent
system type, Query parameterized by the prevalent system and query
result types, etc. But pretty quickly, using it in a real system (and
even in the existing demos) required so many question marks and angle
brackets all over the place it became unwieldy.

Maybe there's still a simpler approach that would be useful to people.
Klaus, when you refer to yourself as "a generics user", do you just
mean things like List<Foo> and Map<Foo, Bar>, or have you developed
other libraries with generics that didn't turn out a mess?

The annotations were *totally* experimental -- I tried several
approaches, and was never happy with any of them. The idea was that
everything is a "transaction" -- an atomic operation -- whether it's
read-only (a "query"), read-write, etc., so there could be a single
Transaction interface, with annotations expressing ways that this
particular transaction might be optimized. For example, a read-only
transaction doesn't need to be journaled; an immutable transaction
doesn't need to be deep-copied. If you deep-copy and journal every
transaction, the logical behavior of the system is still correct, so
*not* doing these things can be seen as "merely" optimizations. I
still stand by that reasoning, but annotations weren't successful in
expressing it!

Cheers,
Justin

Justin T. Sampson wrote:
> On Fri, Apr 4, 2008 at 11:46 AM, Jacob Kjome <ho...@vi...> wrote:
> 
>>  Hmm....  Creating our own SkaringaError for errors coming from the
>>  SkaringaSerializer seems overkill to me.  Personally, I'd limit custom
>>  exceptions to checked exceptions other than maybe general
>>  PrevaylerRuntimeException and PrevaylerError classes.
> 
> I'm sure I had good reasons for each of them. :) I'll review and
> document them as I roll them forward and see if we can come to some
> consensus.

May I ask where?  That is, in code existing in which repository?  First thing's 
first.  Let's get things ready for commits to happen.  It doesn't matter to me 
whether we use SVN or GIT, just that it gets out there.  In any case, the older 
repositories should be made available as a read-only repository and, minimally, 
archived and made available for download.

> 
> Part of the problem is that Java is pretty inconsistent about what
> exactly "errors", "runtime exceptions", and "checked exceptions"
> *mean*, so different projects come up with their own definitions. The
> only thing the language *enforces* is that checked exceptions are
> caught or declared, while runtime exceptions and errors aren't. (And
> Java 5 generics offer a loophole even to that enforcement.) Other
> kinds of semantics that are conceptually attached include the
> distinction between "abstraction-preserving" and
> "abstraction-violating" conditions (I'm not sure if I made up those
> terms myself or heard them somewhere) -- an OutOfMemoryError (which is
> an Error) is abstraction-violating, in the sense that it's not
> triggered by the abstract semantics of your code, but rather by the
> physical limitations of your machine; whereas a NullPointerException
> (which is a RuntimeException) is abstraction-preserving, because it
> *is* triggered by the abstract semantics of your code, and will happen
> regardless of the physical limitations of your machine.
> 

Those are excellent distinctions to make.

> So anyway, I was trying to stick to a particular set of
> interpretations / distinctions that would 1. make the usage of
> exceptions etc. consistent throughout the Prevayler code and 2. not
> conflict with any reasonable usage of exceptions in user code. In some
> cases those goals suggested using e.g. an Error instead of a
> RuntimeException, or introducing a distinct exception subclass, or
> even changing code that previously used an exception to use another
> mechanism entirely instead.
> 

I agree.  The only thing I disagree with is the need for distinct Exception and 
Error classes for each possible exception that might happen when 
PrevaylerException, PrevaylerRuntimeException, and PrevaylerError could suffice 
for most cases.

My example of the SkaringaException (which I mistakenly named "SkaringaError" 
above) is one of the most clear examples of this.  I mainly object to it because 
the primary subject of the failure is Prevayler, not Skaringa.  Skaringa is but 
one serialization implementation we use.  In this case, a PrevaylerIOException 
suffices, and may be unnecessary anyway since IOException is all the Serializer 
interface specifies anyway.  Because it is a checked exception, 
PrevaylerIOException is more acceptable to define as an extra Exception class in 
Prevayler, but unless it is defined in the interface and/or provides functionality 
above and beyond the base exception (such as accessors providing extra 
information, such as an object detailing the configuration of the system for 
debugging purposes), it is somewhat pointless to define a specific Exception/Error 
class.

If we are going to come up with new Prevayler-specific Exception/Error classes for 
every single possible problem, taken to its logical conclusion we will end up with 
  more of these classes than already exists in implementing the core functionality 
of Prevayler.  Besides that, if most of the cases are RuntimeException/Error, then 
it's the message and stack trace that important, not the name of the 
RuntimeException/Error.  A small set of generic, Prevayler-specific, 
Exception/Error classes that we use consistently throughout Prevayler will allow 
us to enforce the abstraction concepts you detailed above and, at the same time, 
keep from cluttering the codebase with an indefinite number of Exception/Error 
classes.

> (This experience and the generics experience have both fomented in me
> a strong preference for dynamically-typed languages...)
> 

I agree to a certain point.  But whenever I write client-side Javascript, I always 
find myself saying "boy, I wish I could define the exact type I expect in this 
function rather than having to type check it first thing inside the function."  A 
combination of type safety and dynamic features would be nice.

Jake

> Cheers,
> Justin

On Sun, Apr 6, 2008 at 1:34 PM, Jacob Kjome <ho...@vi...> wrote:

> May I ask where? That is, in code existing in which repository? First thing's
> first. Let's get things ready for commits to happen. It doesn't matter to me
> whether we use SVN or GIT, just that it gets out there. In any case, the older
> repositories should be made available as a read-only repository and, minimally,
> archived and made available for download.

Yes. I got a tarball of the codehaus.org cvs repository from Ben
Walding, which I've used to do a cvs->git conversion with decent
results. I've also converted the prevayler.org svn repos to git (all
this is just on my machine at the moment). I'm thinking of publishing
the codehaus.org cvs tarball as well as read-only git repos of the
straight conversions from codehaus.org and prevayler.org repos. I'm
okay with leaving the various svn repos online as read-only as well.

I'm hoping that git will make it relatively easy to piece together a
unified history from the various repos. I want to end up with a git
repository with everything up to Prevayler 2.3 as its master branch, a
personal branch for the post-2.3 stuff that I propose to keep, and
another personal branch for the Java 5 work that I propose to not
release (but that I personally want to keep around for inspiration).
Once that git repo is ready, I'll make it available for others to
clone.

> If we are going to come up with new Prevayler-specific Exception/Error classes for
> every single possible problem, taken to its logical conclusion we will end up with
> more of these classes than already exists in implementing the core functionality
> of Prevayler.

A worthwhile concern. :) Looking back, there do seem to be a lot of them.

> Besides that, if most of the cases are RuntimeException/Error, then
> it's the message and stack trace that important, not the name of the
> RuntimeException/Error.

Ah, well, putting it that way reminds me of the real reason to have
distinct exception classes: If the user wants to recover from a
particular condition, it has to be represented as a distinct exception
class in order to be caught. I was hoping to document particular
conditions and how one might choose to recover.

Cheers,
Justin