RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
Thanh Hong Dai
hdthanh at tma.com.vn
Thu Jan 14 03:53:22 UTC 2016
Hi,
Some comment on the regex (and also the JEP):
([1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*)(\-([a-zA-Z0-9]+))?((\+)(0|[1-9][0-9]*)?)?(-([\-a-zA-Z0-9\.]+))?
- The outer most quantifier in (((\.0)*\.[1-9][0-9]*)*)* is redundant and a source of catastrophic backtracking. You only need ((\.0)*\.[1-9][0-9]*)*.
- The outside - in PRE part (\-([a-zA-Z0-9]+))? doesn't need escaping. Simplify it to (-([a-zA-Z0-9]+))?
- Do you want to allow only a plus without the number in the BUILD part? Why do you capture the +? ((\+)(0|[1-9][0-9]*)?)?
- Dot loses meaning in the character class, and hyphen loses meaning at the beginning or at the end of the character class. You can simplify the OPT part to (-([-a-zA-Z0-9.]+))?
- You might want to consider using named-capturing groups instead of numbered capturing groups. Also, consider using non-capturing groups for groups you don't need to extract.
Best regards,
Hong Dai Thanh.
-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Iris Clark
Sent: Thursday, 14 January, 2016 4:55 AM
To: Alan Bateman <alan.bateman at oracle.com>; core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
Hi, Alan.
Thanks for looking at this (hopefully) one last time.
> It can't be java.base (see design principles in JEP 200).
> If it's going into java.base temporarily then the top-level
> modules.xml will need to be updated to export the "jdk" package.
This diff has been applied to modules.xml:
diff -r 6fefc5bce180 modules.xml
--- a/modules.xml Wed Jan 13 13:56:19 2016 +0000
+++ b/modules.xml Wed Jan 13 13:46:56 2016 -0800
@@ -205,6 +205,9 @@
<name>javax.security.cert</name>
</export>
<export>
+ <name>jdk</name>
+ </export>
+ <export>
<name>jdk.net</name>
</export>
<export>
It essentially reverts your 8049422 change [0] to that file. I will not re-add jdk to the javadoc bundle for javac trees API since that is not an appropriate location. I filed the following bug to track publication of jdk.Version:
8144069: Determine correct publication for jdk.Version API
https://bugs.openjdk.java.net/browse/JDK-8144069
When this came up earlier, I filed this bug to track finding a more appropriate module for jdk.Version:
8144062: Determine appropriate module for jdk.Version
https://bugs.openjdk.java.net/browse/JDK-8144062
Thanks,
iris
[0] http://hg.openjdk.java.net/jdk9/dev/rev/1bee5efa73e3
-----Original Message-----
From: Alan Bateman
Sent: Tuesday, January 12, 2016 7:41 AM
To: Iris Clark; core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
On 11/01/2016 21:44, Iris Clark wrote:
> Hi, Joe, Roger, Alan, Magnus, and Mandy.
>
> At the end of December (shortly before the Christmas/Winter break and
> my vacation), I provided responses to your messages and an updated
> webrev:
>
> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/
>
> I didn't hear from anybody, so I'd like to optimistically assume that
> you were satisfied. Is that correct?
>
> For you convenience, here's a reference to the December and November
> threads:
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037
> 062.html
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036
> 904.html
>
> I'd like to wrap up this work for the initial implementation of
> jdk.Version soon.
>
I think this looks good but we'll to decide which module to put this in.
It can't be java.base (see design principles in JEP 200). If it's going into java.base temporarily then the top-level modules.xml will need to be updated to export the "jdk" package.
-Alan
More information about the core-libs-dev
mailing list