Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly tightened:
Right you are. Webrev regenerated.
Martin
Joe Darcy wrote:
What other utility methods would have broad enough use and applicability
to go into a common java.util class?
Joe,
You've asked for a call for ideas, but not given any indication of
process. Are you going to evaluate everything that comes in and pick the
best a la Coin? Or al
On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
> Martin Buchholz wrote:
>>
>> On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
>>
>>>
>>> On 09/09/09 08:01 PM, Joe Darcy wrote:
>>> I noticed that the Character class should be similarly tightened:
>>>
>>
>> Right you are. Webrev regenerated.
>>
>>
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly tightened:
Right you are. Webrev regenerated.
Martin
One typo inherited from my earlier suggestion (mea culpa!): a
On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
> On 09/09/09 08:01 PM, Joe Darcy wrote:
> I noticed that the Character class should be similarly tightened:
Right you are. Webrev regenerated.
Martin
On 09/09/09 08:01 PM, Joe Darcy wrote:
Martin Buchholz wrote:
On Wed, Sep 9, 2009 at 17:40, Joe Darcy wrote:
PS This talk of hashing remind me of a small spec cleanup:
4245470 algorithm of java.lang.Byte.hashCode() is not specified
http://bugs.sun.com/view_bug.do?bug_id=4245470
http:/
Le 10/09/2009 04:11, Martin Buchholz a écrit :
On Wed, Sep 9, 2009 at 17:54, Rémi Forax wrote:
Le 10/09/2009 02:15, Martin Buchholz a écrit :
Here's a bunch of static hashCode methods for primitives:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode/
This doesn't include
On 09/10/2009 04:51 PM, Xueming Shen wrote:
David M. Lloyd wrote:
On 09/10/2009 01:47 PM, Xueming Shen wrote:
I think we have enough discussion on this topic, it's time to make a
final decision. Seems like we are all happy on the
changes in Deflater and new DOS.flush(mode), the only difference
David M. Lloyd wrote:
On 09/10/2009 01:47 PM, Xueming Shen wrote:
I think we have enough discussion on this topic, it's time to make a
final decision. Seems like we are all happy on the
changes in Deflater and new DOS.flush(mode), the only difference is
whether or not we should change the exist
On 09/10/2009 01:47 PM, Xueming Shen wrote:
I think we have enough discussion on this topic, it's time to make a
final decision. Seems like we are all happy on the
changes in Deflater and new DOS.flush(mode), the only difference is
whether or not we should change the existing
behavior of DOS.fl
The only use case that can't be worked around is if someone is relying
on code which either sub-classes DeflaterOutputStream or uses a
non-injected DeflaterOutputStream, where they can't replace it with a
fixed version. Both of these use cases probably aren't that common,
since if they ever needed
I think we have enough discussion on this topic, it's time to make a
final decision. Seems like we are all happy on the
changes in Deflater and new DOS.flush(mode), the only difference is
whether or not we should change the existing
behavior of DOS.flush() should use Z_SYNC_FLUSH by default.
Br
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 08:25, Andrew Haley wrote:
Andrew John Hughes wrote:
FWIW, I'm pretty sure I'm not alone in saying I'd much prefer to
receive these 'uninteresting' mails.
This particular back-port mail would have been very interesting to
us, since
On Thu, Sep 10, 2009 at 08:25, Andrew Haley wrote:
> Andrew John Hughes wrote:
>
>> FWIW, I'm pretty sure I'm not alone in saying I'd much prefer to
>> receive these 'uninteresting' mails.
>
> This particular back-port mail would have been very interesting to
> us, since it has a huge impact on bui
> So I'm left with only equal() for your new Objects class. By the way,
> the best implementation is a == b || (a != null && a.equals(b)).
I disagree, as this one does not handle arrays properly.
I'd either like equal to handle deep equality on arrays or have a deepEqual
utility method that tak
Mike Morris wrote:
Joe Darcy wrote:
For JDK 7, I think it is high-time the platform included a class like
java.util.Objects to hold commonly-written utility methods. For
...
What other utility methods would have broad enough use and
applicability to go into a common java.util class?
Ah! L
Andrew John Hughes wrote:
> FWIW, I'm pretty sure I'm not alone in saying I'd much prefer to
> receive these 'uninteresting' mails.
This particular back-port mail would have been very interesting to
us, since it has a huge impact on build times on some architectures.
Andrew.
2009/9/10 Martin Buchholz :
> Hi Andrew,
>
> I don't recall all the details, but I probably backported all-at-once
> because it was a little easier for me to do so - it reflected the
> engineering that was actually done. I care more about
> the quality of the openjdk7 mercurial history. In this
Hi Andrew,
I don't recall all the details, but I probably backported all-at-once
because it was a little easier for me to do so - it reflected the
engineering that was actually done. I care more about
the quality of the openjdk7 mercurial history. In this case
the information *is* available to
2009/9/10 Ulf Zibis :
> Am 10.09.2009 01:54, Stephen Colebourne schrieb:
>>
>> There is also a case for methods to convert arrays of wrappers to
>> arrays of primitives.
>>
>
> +1
> - I guess, you mean also vice versa
> - Maybe would become superfluous, if HotSpot internally would compile to
> prim
2009/9/10 Ulf Zibis :
> Am 10.09.2009 02:04, Rémi Forax schrieb:
>>
>> Le 10/09/2009 01:43, Andrew John Hughes a écrit : I agree about the
>> debugging purpose, that why I don't agree
>> with Kevin when he said that java.util.Objects should not use
>> reflection.
>>
>> Perhaps the method can be re
2009/4/29 Martin Buchholz :
> Since writing this, I have learned, to my horror, that the
> behavior of the -C flag differs from the behavior in tar in that
>
> - -C is not sticky - it applies only to the one following argument
>
> - the path is relative to the JDK's current directory, not the
> pre
Am 10.09.2009 05:45, Reinier Zwitserloot schrieb:
A trick I'm reverting to rather a lot of late is to find my own jar
file by getting a URL to my own class file as a resource, resolved
against my own class, and then parsing this URL for the jar bit of it.
(MyClassName.class.getResource("MyCla
Am 10.09.2009 02:15, Martin Buchholz schrieb:
Here's a bunch of static hashCode methods for primitives:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode/
Can't this be solved by extending auto-boxing capabilities? :
long l = 1234567890;
int hash = l.hashCode();
-Ulf
Am 10.09.2009 02:04, Martin Buchholz schrieb:
Is there any junit support yet for jtreg?
+1 to have this.
-Ulf
Am 10.09.2009 01:54, Stephen Colebourne schrieb:
There is also a case for methods to convert arrays of wrappers to
arrays of primitives.
+1
- I guess, you mean also vice versa
- Maybe would become superfluous, if HotSpot internally would compile to
primitive arrays. (just a raw thought)
Am 10.09.2009 02:04, Rémi Forax schrieb:
Le 10/09/2009 01:43, Andrew John Hughes a écrit :
I agree about the debugging purpose, that why I don't agree
with Kevin when he said that java.util.Objects should not use
reflection.
Perhaps the method can be renamed to: toDebugString.
Rémi
PS: the co
Joe Darcy wrote:
For JDK 7, I think it is high-time the platform included a class like
java.util.Objects to hold commonly-written utility methods. For
...
What other utility methods would have broad enough use and applicability
to go into a common java.util class?
Ah! Let's just go back to
28 matches
Mail list logo
