12 Jan 2010 23:25
Re: Embed E in Java
Mark Miller <erights@...>
2010-01-12 22:25:36 GMT
2010-01-12 22:25:36 GMT
On Tue, Jan 12, 2010 at 2:13 PM, Kevin Reid <kpreid-ee4meeAH724@public.gmane.org> wrote:
On Jan 12, 2010, at 17:08, Mark Miller wrote:Hold on. Where did 1.5 come in, and what do you mean by "moving E-on-
> On Tue, Jan 12, 2010 at 1:42 PM, Kevin Reid <kpreid-ee4meeAH724@public.gmane.org> wrote:
>> On Oct 21, 2009, at 13:25, Mark Miller wrote:
>>> On Tue, Oct 20, 2009 at 9:17 AM, Kevin Reid <kpreid-ee4meeAH724@public.gmane.org> wrote:
>>>> MarkM: Is there a non-historical reason NestedException/
>>>> NestedThrowable/etc exist instead of using the Java 1.4
>>>> Throwable.getCause() mechanism?
>>> Mostly history. The NestedException,.. mechanism predates Java 1.4.
>>> Since it worked, I have never examined the new getCause() API. I do
>>> not know whether or not it would be safe to use instead.
>> I believe I understand it sufficiently well to say that it is safe
>> appropriate to use instead. I propose to change E-on-Java to replace
>> the Nested* mechanisms (backwards compatibly, i.e. the .leaf() sugar
>> and so on will still exist) with causes.
>> * What is the minimum Java version E-on-Java is intended to require?
> 1.4. Yes, I realize that contradicts my paragraph quoted above. I
> have no
> objections to moving E-on-Java's dependencies forward to 1.5. Does
> else see any reasons to stay with 1.4 for now?
Java's dependencies"? I'm only proposing to use 1.4 features, not 1.5.
I don't see any contradiction in what you have said so far.
My mistake. I assumed (incorrectly) that getCause() came in with 1.5.
> Btw, one big potential benefit of moving towards 1.5 is that weWhy do you consider the generics an enormous cost? Additional
> could start
> making parts of E-on-Java be Joe-E safe. Ultimately, except for a
> powerbox, it might be good for E-on-Java to become E-on-Joe-E.
> Unfortunately, for this to happen, we'd need to start to use Java's
> (parameterized typed) within the E implementation, at an enormous
> cost in
> readability and reviewability. I do not yet understand how practical
> it is
> to use Joe-E while avoiding generics.
verbosity, or erasure-related issues, or what?
Both. When participating in the Waterken/Joe-E security review, the effort to ignore all the information (or worse, *almost* all the information) between angle brackets, because it could be lying without warning, made everything much harder. For this noise to become a large fraction of the total source text is more than annoying. All this is Java 1.5's fault, not Joe-E's. Joe-E was not in a practical position to repair this mistake.
Text by me above is hereby placed in the public domain
_______________________________________________ e-lang mailing list e-lang@... http://www.eros-os.org/mailman/listinfo/e-lang