line numbers policy change for "multiline" expressions

[Howard Lovatt]

Yes as in stream peek but inside the debugger. Stream peek is like print
statement debugging, its OK but not really as productive as a good
debugger. It is what I currently use.

 -- Howard.


On 28 January 2014 14:29, Brian Goetz <brian.goetz at oracle.com> wrote:

> As in, Stream.peek()?
>
> On 1/27/2014 8:38 PM, Howard Lovatt wrote:
>
>> Unfortunately lazy evaluation and FLUENT, e.g. Streams, and the current
>> debugger do not go well together. The problem is that you need to be able
>> to observe the transformations as they happen down the chain of calls.
>> Therefore I doubt it is worth changing the line numbers, better to put
>> effort into a new debugging tool that works well with lazy, FLUENT APIs.
>>
>>   -- Howard.
>>
>>
>> On 28 January 2014 09:27, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>  On 01/27/2014 04:05 PM, Jochen Theodorou wrote:
>>>
>>>> Am 27.01.2014 15:16, schrieb Remi Forax:
>>>>
>>>>> Hi Anna,
>>>>> this change is unlikely be reverted, otherwise for a code like the one
>>>>> below,
>>>>> the lambda body will not have the right line number.
>>>>>
>>>>> list.stream()
>>>>>         .filter(....)
>>>>>         .map(x -> Integer.toString(x))
>>>>>         .collect(...);
>>>>>
>>>>
>>>> I wished there would be some kind of spec for how the bytecode has to
>>>> look like for the debugger to be able to have breakpoints and step
>>>> debugging. At least the conditions for the former seems to differ from
>>>> the later.
>>>>
>>>
>>> + 1
>>>
>>>
>>>> bye Jochen
>>>>
>>>>
>>> Rémi
>>>
>>>
>>>
>>>
>>
>>


-- 
  -- Howard.