Moving your question to core-libs-dev, please drop build-dev from all
future responses.
David
On 18/06/2014 10:56 AM, Su wrote:
May I ask why "contains" method of TreeSet uses the comparator to decide if
two objects are equals, but not the equals method of the object?
Thank you.
On 6/16/14 9:33 PM, huizhe wang wrote:
It's not xhmtl, but I would think closing tags is a good practice. Being
explicit is always a good thing to do.
Being explicit sounds good, but in this case it leads to errors; see below.
The problem with using the end tag is that it's easy for addition
Hi,
This is a long time compatibility issue: Duration.compare returns equal
for INDETERMINATE relations defined in XML Schema standard
(http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
following table:
Relation
P*1Y* > P*364D*<> P*365D*<> P*366
Hi Paul,
That thread, while interesting -- maybe :-) -- is about a somewhat different
issue: self-closing tags as opposed to optional end tags. Self-closing tags were
never part of HTML4 and thus are strictly illegal. In practice many people use
them and many browsers accept them, leading to a
Hi,
Can I get a review for this fix and javadoc clarification for
https://bugs.openjdk.java.net/browse/JDK-8044629
The problem is with potentially annotated receiver parameters, they only exist
for inner class constructors, so this fix makes sure that a ctor is for an
inner class or returns nu
Ok, I'm working on improving code and comments based on feedback. I'll
split the SharedSecrets part out, make the methods public and post a new
webrev soon.
/Claes
On 06/17/2014 04:21 PM, roger riggs wrote:
Yes, that looks more consistent with the current versions.
Though you want to see the
Yes, that looks more consistent with the current versions.
Though you want to see these for 8u, the preferred pattern is to make
the changes
in 9 and then backport the result (in this case adding the shared
secrets aspect).
Roger
On 6/16/2014 4:13 PM, Claes Redestad wrote:
...
The terminol
This thread is a good reference on JDK 8's lint enforcement of HTML in
javadoc. You can see the reasons behind not allowing self-enclosing tags
and enforcing HTML:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/thread.html#19269
Cheers,
Paul
On Mon, Jun 16, 2014 at 11:33 PM, hui
Looks fine Pavel.
On 17 Jun 2014, at 14:06, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8047062?
>
> http://cr.openjdk.java.net/~prappo/8047062/webrev.00/
>
> Thanks
> -Pavel
Hi everyone,
Could you please review my change for JDK-8047062?
http://cr.openjdk.java.net/~prappo/8047062/webrev.00/
Thanks
-Pavel
Hi,
It is easier to read and maintain the source code if there is less
clutter and markup.
Previous consensus seemed to be to omit closing html when not required.
Roger
On 6/17/2014 12:33 AM, huizhe wang wrote:
On 6/16/2014 5:35 PM, Stuart Marks wrote:
This is somewhat moot at this point,
I will close this bug with resolution "Cannot Reproduce" and create a new one.
I think this should be the right way to go.
Apologies.
-Pavel
On 17 Jun 2014, at 13:32, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8046768?
>
> http://cr.openjdk.java.net/~prap
Hi everyone,
Could you please review my change for JDK-8046768?
http://cr.openjdk.java.net/~prappo/8046768/webrev.00/
This change doesn't fix the issue. It barely adds a diagnostic output
(LdapTimeoutTest.java:167) for the case that is failing. During my
investigation I haven't been able to re
Thank you, John.
Best regards,
Vladimir Ivanov
On 6/16/14 10:07 PM, John Rose wrote:
Reviewed. — John
On Jun 16, 2014, at 9:50 AM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8046903/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8046903
j.l.i.InvokerBytecodeGenerato
14 matches
Mail list logo
