harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rui Hu" <roberthu...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-1462) [classlib][luni] SocketPermission does not accept '*' as a port number
Date Wed, 20 Sep 2006 03:28:30 GMT
On 9/19/06, Mikhail Markov (JIRA) <jira@apache.org> wrote:

>    [
> http://issues.apache.org/jira/browse/HARMONY-1462?page=comments#action_12435743]
>
> Mikhail Markov commented on HARMONY-1462:
> -----------------------------------------
>
> I absolutely agree that '*' should be supported as a port number.
> But API spec clearly says that: "portrange = portnumber | -portnumber |
> portnumber-[portnumber]" (but still RI supports it!) - that's why i put it
> to "Non-bug differences" category. Possible fix for API spec?


Great analysis! We must follow rule [1], but spec do not restrict
"portnumber" in rule [1].
And the problem is that we must choose one of following considerations:
1. We can take this JIRA as a "Non-bug differences" and consider
"portnumber" as ONLY numerical string ([0-9]*), it hints that RI breaks spec
because RI receive "*" as a "portnumber".
For this case, we certainly need not to give any fix for Harmony.
2. We can think that "portnumber" is not only numerical string, but also can
be "*". If so, because "*" indicates all ports(0-65535), so "-*" and "*-" is
meaningless in rule[1].

If we choose 1., we should take this JIRA as a RI's bug for it breaks the
But I think RI is innocent because the wildcard "*" is reasonable and really
a helpful feature.

If we choose 2., we should just notice that "-*" and "*-" is meaningless, as
an exception of rule [1], and rule[1] can be kept.
Then, we can improve Harmony safely with this helpful feature and keep the
spec.
In fact, following test cases will pass on RI, indicating that "-*" and "*-"
is meaningless and "*" is OK.
        try {
            new SocketPermission("localhost:-*", "listen");
            fail("-* should be considered as an illegal port range.");
        } catch (IllegalArgumentException e) {
            // Expected
        }
        try {
            new SocketPermission("localhost:*-", "listen");
            fail("*- should be considered as an illegal port range.");
        } catch (IllegalArgumentException e) {
            // Expected
        }
        SocketPermission sp3 = new SocketPermission("localhost:*",
"listen");

So, IMO, 2 is better.


[1]: portrange = portnumber | -portnumber | portnumber-[portnumber]




> > [classlib][luni] SocketPermission does not accept '*' as a port number
> > ----------------------------------------------------------------------
> >
> >                 Key: HARMONY-1462
> >                 URL: http://issues.apache.org/jira/browse/HARMONY-1462
> >             Project: Harmony
> >          Issue Type: Bug
> >          Components: Classlib
> >         Environment: Win XP
> >            Reporter: Mikhail Markov
> >         Assigned To: Paulex Yang
> >         Attachments: patch.diff
> >
> >
> > Although API specification does not explicitly allow '*' usage as a port
> number for SocketPermission, RI accept '*' as a port number (representing
> the full port range from 0 to 65535).
> > ============== Test.java =================
> > import java.net.SocketPermission;
> > public class Test {
> >     public static void main(String[] args) throws Exception {
> >         try {
> >             SocketPermission sp = new SocketPermission("localhost:*",
> "listen");
> >             System.out.println("'*' for port is ok.");
> >         } catch (IllegalArgumentException iae) {
> >             System.out.println("'*' for port is not ok: " + iae);
> >         }
> >     }
> > }
> > ======================================
> > Output on RI:
> > '*' for port is ok.
> > Output on Harmony:
> > '*' for port is not ok: java.lang.IllegalArgumentException: Invalid port
> number specified
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>


-- 
Robert Hu
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message