Return-Path: 
 <harmony-dev-return-4492-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 32804 invoked from network); 22 Feb 2006 06:07:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 22 Feb 2006 06:07:29 -0000
Received: (qmail 43604 invoked by uid 500); 22 Feb 2006 06:07:27 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 42420 invoked by uid 500); 22 Feb 2006 06:07:23 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 42357 invoked by uid 99); 22 Feb 2006 06:07:23 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2006 22:07:22 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates
 66.249.92.206 as permitted sender)
Received: from [66.249.92.206] (HELO uproxy.gmail.com) (66.249.92.206)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2006 22:07:17 -0800
Received: by uproxy.gmail.com with SMTP id e2so737235ugf
        for <harmony-dev@incubator.apache.org>;
 Tue, 21 Feb 2006 22:06:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tiks1AGTELiVnVdX8/rzYkYQUuSSzNo6e7SnwawUynNflFuca8cPxazOSTGbo1NvgWud4ND/goAc6o9WJ4ii5GXzjCGaUmBYo8EF2BBWa3pwFgXYrNth3TbdU2BaKkhN6LMQomi1WuSp9rHtvKwnqsd4OVSwS/qGIHZ7+jYxdgQ=
Received: by 10.66.184.5 with SMTP id h5mr3023850ugf;
        Tue, 21 Feb 2006 22:06:56 -0800 (PST)
Received: by 10.66.244.19 with HTTP; Tue, 21 Feb 2006 22:06:56 -0800 (PST)
Message-ID: <906dd82e0602212206w6683f9bdn6222e8c357ef3dec@mail.gmail.com>
Date: Wed, 22 Feb 2006 12:06:56 +0600
From: "Mikhail Loenko" <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Bug-to-bug compatibility - first issue
In-Reply-To: <43FBF2DC.3010404@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <e3b630230602211136p48242ec9gb48ee7c2d6fb15f8@mail.gmail.com>
	 <86668a350602211233l187fca38tb5c9c0867d6bac3d@mail.gmail.com>
	 <43FBF2DC.3010404@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

I'd suggest splitting the issue into two different ones:

The first one is interpreting the command line. I completely agree
that we should
do it similar to RI.

The second one is as Vladimir said that behavior is caused by something
in URLClassloader or kernel classes. Vladimir, if you could provide
a piece of java code that shows difference in the behavoir of RI and Harmon=
y
in those classes, so we could discuss how to implement the classes the best=
.

Thanks,
Mikhail

On 2/22/06, Paulex Yang <paulex.yang@gmail.com> wrote:
> I agree with you that it is natural to copy RI behavior in this case,
> and I even don't think this is a bug, in the same reason with one of the
> bugs' evaluation [1],
>
> <quote>An empty path component is always (in both Unix/Posix-like and Win=
dows systems) treated as "."</quote>
>
>
> Arzhan Kinzhalin wrote:
> >> URLClassLoader can't load this class because searchURLs parameter in
> >> findClassImpl does not contain current directory and includes only
> >> "p:/". So, IMO problem is inside VM kernel classes.
> >>
> >> What do you think we should do with this issue?
> >>
> >
> > It actually has corresponding bug report [1] which provides some
> > background to the story.
> >
> > Names and behaviour of command-line arguments is not a part of the
> > spec. It's just that everyone follows well-established conventions. In
> > this case it would seem natural to copy the behavior.
> >
> > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4515984
> >
> > --
> > Arzhan
> > Intel Middleware Products Division
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>