Hi Jaroslav,
On 12/08/15 18:05, Jaroslav Bachorik wrote:
On 5.8.2015 08:04, Eamonn McManus wrote:
That makes me sad. The limit is clearly a detail of this particular
implementation and should not be enshrined in the spec.
Éamonn
I re-requested CCC for not mentioning the exact limit in the
Looks fine to me (emcmanus).
On Aug 13, 2015 11:13 AM, Jaroslav Bachorik jaroslav.bacho...@oracle.com
wrote:
On 13.8.2015 02:53, Daniel Fuchs wrote:
Hi Jaroslav,
On 12/08/15 18:05, Jaroslav Bachorik wrote:
On 5.8.2015 08:04, Eamonn McManus wrote:
That makes me sad. The limit is clearly a
On 13.8.2015 02:53, Daniel Fuchs wrote:
Hi Jaroslav,
On 12/08/15 18:05, Jaroslav Bachorik wrote:
On 5.8.2015 08:04, Eamonn McManus wrote:
That makes me sad. The limit is clearly a detail of this particular
implementation and should not be enshrined in the spec.
Éamonn
I re-requested CCC for
On 5.8.2015 08:04, Eamonn McManus wrote:
That makes me sad. The limit is clearly a detail of this particular
implementation and should not be enshrined in the spec.
Éamonn
I re-requested CCC for not mentioning the exact limit in the docs and it
has been approved (thanks to Joe for quick
Eamonn, Daniel,
thanks for the comments.
I've updated the webrev to address them. Also, I've added a test to
exercise the boolean flag en-/decoding in ObjectName.
http://cr.openjdk.java.net/~jbachorik/8041565/webrev.03
Cheers,
-JB-
On 4.8.2015 23:02, Daniel Fuchs wrote:
Hi Jaroslav,
I would remove the spec changes about the limit on the domain length,
which are a property of this particular implementation. It's perfectly
reasonable to blow up if the domain length is 536,870,911, but
there's no reason for it to be in the spec.
Éamonn
2015-08-05 4:48 GMT-07:00 Jaroslav
On 5.8.2015 16:53, Eamonn McManus wrote:
I would remove the spec changes about the limit on the domain length,
which are a property of this particular implementation. It's perfectly
reasonable to blow up if the domain length is 536,870,911, but
there's no reason for it to be in the spec.
That makes me sad. The limit is clearly a detail of this particular
implementation and should not be enshrined in the spec.
Éamonn
2015-08-05 8:02 GMT-07:00 Jaroslav Bachorik jaroslav.bacho...@oracle.com:
On 5.8.2015 16:53, Eamonn McManus wrote:
I would remove the spec changes about the limit
On 8/5/15 8:02 AM, Jaroslav Bachorik wrote:
On 5.8.2015 16:53, Eamonn McManus wrote:
I would remove the spec changes about the limit on the domain length,
which are a property of this particular implementation. It's perfectly
reasonable to blow up if the domain length is 536,870,911, but
That makes sense to me. I think the phrase could even be as vague as
or the name exceeds one of the implementation's limits without
saying what those limits might be. That would leave having reasonable
limits as a quality-of-implementation issue, as it should be. The acid
test is whether we would
Hi,
reviving this review.
On 14.4.2015 16:58, Jaroslav Bachorik wrote:
On 14.4.2015 14:56, Daniel Fuchs wrote:
Hi Jaroslav,
I like this change, but it does introduce an incompatibility,
so it probably needs a CCC and some release notes.
For instance, this test passes with the current
I would like to suggest some cosmetic changes. The hex constants could
have underscores, for example 0x8000_. The FLAG_MASK constant
could be expressed as the OR of the three flags rather than as a
literal, and the DOMAIN_LENGTH_MASK could be ~FLAG_MASK. In
setDomainLength, the parameter name
Hi Jaroslav,
379 * This field encodes _domain_pattern, _property_list_pattern and 380
* _property_value_pattern booleans.
If I'm not mistaken it also encodes the domain length.
1072 if ((l FLAG_MASK) 0 ) {
Although it is not expected that 'l' could be negative, it might be
better to
On 14.4.2015 14:56, Daniel Fuchs wrote:
Hi Jaroslav,
I like this change, but it does introduce an incompatibility,
so it probably needs a CCC and some release notes.
For instance, this test passes with the current version of
ObjectName:
public class StringLengthTest {
final static int
Hi Jaroslav,
I like this change, but it does introduce an incompatibility,
so it probably needs a CCC and some release notes.
For instance, this test passes with the current version of
ObjectName:
public class StringLengthTest {
final static int smax = Short.MAX_VALUE;
final static
On 14/04/15 14:56, Daniel Fuchs wrote:
With that in mind I believe you should consider throwing
InternalError - or IllegalArgumentException - instead of
using 'assert' statements.
Actually - MalformedObjectNameException would be more appropriate.
Stupid me.
-- daniel
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00
In situations when there are 10s of thousands ObjectNname instances
around (enterprise setups etc.) the 3 separate internal boolean
Hi Jaroslav,
Looks good to me.
Nice to save 8 bytes on object name insatnces (~ 20%) !
Olivier
Le 13/04/2015 11:43, Jaroslav Bachorik a écrit :
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
Webrev:
Hi Jaroslav,
Minor comments:
1488+: In forms like:
_pattern_flag = (~PROPLIST_PATTERN 0xff);
The 0xff seems unnecessary since the store is to a byte field.
1644: the ? and : operators should be surrounded by spaces.
There are other style issues, such as then statements on the same line
19 matches
Mail list logo
