, Mark Sheppard wrote:
> yes that's fine with me also
>
> regards
> Mark
>
> On 15/12/2015 15:04, Chris Hegarty wrote:
>> On 13 Nov 2015, at 04:59, Sebastian Sickelmann
>> wrote:
>>
>>> Hi,
>>>
>>> my recordings related to this thre
Hi,
I want to ask if we can make any progress with this javadoc- and
test-only change.
Are you ok with the provided patch?
@Chris and Mark: Can i create a changeset that lists you as reviewer?
--
Sebastian
On 11/13/2015 05:59 AM, Sebastian Sickelmann wrote:
> Hi,
>
> my recordings r
Hi,
I wanted to start an discussion/review-process some time ago,
for a description of it see the previous tries below.
The actual webrev-url is:
http://cr.openjdk.java.net/~sebastian/8022748/webrev.01/
--
Sebastian
On 11/07/2015 09:43 AM, Sebastian Sickelmann wrote:
> Hi,
>
> i f
15 04:27 PM, Sebastian Sickelmann wrote:
> Hi,
>
> here is the updated webrev:
>
> http://cr.openjdk.java.net/~dbuck/4906983.3/
>
> Hope the comments are fine now.
>
> What would be the normal procedure in net-dev for accepting a change (a
> 2 group-member thumb
2015 1:02 AM, Sebastian Sickelmann wrote:
>> Hi Brad,
>>
>> The bug is for the complete codebase, where the webrev is for the
>> net-dev part only. I have already created
>> a subtask for the macos-port-dev part, and it is fixed already.
>
> Ok.
>
>> Now
make the javadocs target to test?
>
> Brad
>
>
>
> On 11/5/2015 7:42 PM, Sebastian Sickelmann wrote:
>> Hi, i wanted to start an discussion/review-process some time ago, see
>> second-try below.
>>
>> Is there someone who wants to discuss/review this jav
Hi,
i fixed some typing and formatting errors. Thanks to Martijn.
Please find the updated webrev at:
http://cr.openjdk.java.net/~sebastian/8022748/webrev.01/
-- Sebastian
On 11/06/2015 04:40 AM, Sebastian Sickelmann wrote:
> Hi,
>
> i wanted to start an discussion/review-process some
Hi, i wanted to start an discussion/review-process some time ago, see
second-try below.
Is there someone who wants to discuss/review this javadoc-only change?
Else, should i link my result as reference into the JBS?
-- Sebastian
On 10/27/2015 05:28 AM, Sebastian Sickelmann wrote:
> He
Hi,
i wanted to start an discussion/review-process some time ago, see
second-try below.
Is there someone who wants to discuss/review this change?
Else, should i link my result as reference into the JBS?
--
Sebastian
On 10/27/2015 05:24 AM, Sebastian Sickelmann wrote:
> Hi,
>
> i inv
Hello,
Actually I am searching through the JBS for low hanging fruits.
Right now i am looking through the openjdk-sources and try to evaluate
if i can make something about JDK-5108778.
Please find my webrevs for the jdk(net) repos at:
http://cr.openjdk.java.net/~sebastian/5108778/net/webrev.00/
Hi,
i investigated the problem described in JDK-8022748[1] i found that
the parser needed to be rescued for confusion while handling relative URIs.
A URI created through the relativize-method is schemaless and so it
need to handle the special-case (a colon in the path-element). While
there is als
Hi,
is there someone who wants to sponsor/review my suggested change?
-- Sebastian
On 10/06/2015 01:13 PM, Sebastian Sickelmann wrote:
> Hi,
>
> i investigated the problem described in JDK-8022748[1] i found that
> the parser needed to be rescued for confusion while handling r
Hello,
Actually I am searching through the JBS for low hanging fruits.
Right now i am looking through the openjdk-sources and try to evaluate
if i can make something about JDK-5108778.
Please find my webrevs for the jdk(net) repos at:
http://cr.openjdk.java.net/~sebastian/5108778/net/webrev.00/
Hi,
i investigated the problem described in JDK-8022748[1] i found that
the parser needed to be rescued for confusion while handling relative URIs.
A URI created through the relativize-method is schemaless and so it
need to handle the special-case (a colon in the path-element). While
there is al
Sebastian Sickelmann:
> Hi,
>
> i investigated the problem described in JDK-8022748[1] i found that we
> need to rescue the parser for confusion while parsing relative URIs.
> A URI created through the relativize-method is schemaless and so it
> need to handle the special-case (a colon i
On 13/09/15 20:18, Sebastian Sickelmann wrote:
>> Am 13.09.2015 um 16:25 schrieb Chris Hegarty:
>>>
>>>> On 13 Sep 2015, at 14:07, Mark Sheppard
>>>> <<mailto:mark.shepp...@oracle.com>mark.shepp...@oracle.com> wrote:
>>>>
>&g
Am 14.09.2015 um 11:02 schrieb Chris Hegarty:
> On 13/09/15 19:03, Mark Sheppard wrote:
>>
>> I was thinking as a change for all constructors, as there are URL, which
>> may overload authority part's structural elements such that port
>> might be
>> a "remote object id", or some other form of toke
Am 14.09.2015 um 10:53 schrieb Chris Hegarty:
> On 13/09/15 20:18, Sebastian Sickelmann wrote:
>> Am 13.09.2015 um 16:25 schrieb Chris Hegarty:
>>>
>>>> On 13 Sep 2015, at 14:07, Mark Sheppard
>>>> <<mailto:mark.shepp...@oracle.com>mark.shepp...@o
d, e.g.
>>
>> if the parsed URL fails to comply with the scheme specific syntax of
>> the associated protocol.
>
> Is this suggested wording for the “spec” accepting constructors? I
> think what we have for the constructors accepting protocol, host,
> port, etc, is more a
2015, at 11:13, Chris Hegarty wrote:
>
>> On 8 Sep 2015, at 21:01, Sebastian Sickelmann
>> wrote:
>>
>>> Hi,
>>>
>>> Please find my small patch[1] to javadoc in java.net.URL that adresses
>>> JDK-4906983(javadoc-fix)[2].
>>>
>>> I
Hi,
i investigated the problem described in JDK-8022748[1] i found that we
need to rescue the parser for confusion while parsing relative URIs.
A URI created through the relativize-method is schemaless and so it
need to handle the special-case (a colon in the path-element). While
there is another
Hi,
while investigation for JDK-8022748 [1] (new URI(u.toString()).equals(u)
does not hold with paths containing colons
i found some smaller things.
The javadoc contains the following example
---
*This operation is often useful when constructing a document
containing URIs that must be m
Hi,
Please find my small patch[1] to javadoc in java.net.URL that adresses
JDK-4906983(javadoc-fix)[2].
I signed the SCA/OCA some time ago. Feel free to check at the OCA
Signatures-List[3]
thanks to david buck for hosting this patch on cr.openjdk.java.net.
-- Sebastian Sickelmann
[1] http
> > that will be reflected at [3].
> > The process of becoming an OpenJDK contributor is described at [4].
> >
> > Thanks,
> >
> > Ivan
> >
> >
> > [1] http://openjdk.java.net/bylaws
> > [2] http://www.oracle.com/technetwo
ic-part of "b"
I would like to add another low_mask and high_mask to manage all
forbidden chars and put this mask
into the encode method.
So we can encode all forbidden chars for every part of the URI differently.
What do you think?
Is there someone who would sponsor this?
-- Sebast
Hi,
i want to have a closer look to JDK-8022748[1].
I make experimented a little and for me it seemed that the relativize
method is making the trouble.
Has someone had a look at it, already? Or is it a academic (relativize
on "." ) case that is described
in the bug-report? Elsewise I would invest
26 matches
Mail list logo
