Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: How to convert image into Hex 2 Dimensional Array? Date: Fri, 10 May 2013 23:42:15 +0200 Organization: A noiseless patient Spider Lines: 52 Message-ID: References: <41718873-b1a6-4b97-bbbb-8002c48d4e29@googlegroups.com> <518af634$0$32105$14726298@news.sunsite.dk> <518b02f9$0$32109$14726298@news.sunsite.dk> <518b040c$0$32109$14726298@news.sunsite.dk> <518c55f3$0$32106$14726298@news.sunsite.dk> <%Aajt.33$Ax6.0@newsfe25.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 10 May 2013 21:38:34 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="f6ca6bb52c0933e86b8a17e90bd81433"; logging-data="32493"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+H4w/04fNjgag2UpM4olaV" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: <%Aajt.33$Ax6.0@newsfe25.iad> Cancel-Lock: sha1:ZIDTXn66g31DTNPyIdjpF65z9DM= Xref: csiph.com comp.lang.java.programmer:23998 On 10/05/2013 20:00, Daniel Pitts allegedly wrote: > On 5/10/13 10:02 AM, Daniele Futtorovic wrote: >> On 10/05/2013 18:46, Daniel Pitts allegedly wrote: >>> On 5/9/13 7:05 PM, Arne Vajhøj wrote: >>>> On 5/8/2013 11:18 PM, Eric Sosman wrote: >>>>> On 5/8/2013 10:03 PM, Arne Vajhøj wrote: >>>>>> [...] >>>>>>> I would still expect the byte version to end up >>>>>>> with width*height Byte objects. >>>>>>> >>>>>>> If there are no null and no reused objects, then >>>>>>> I can not see how that can be avoided. >>>>>> >>>>>> Are you saying that Java will intern so aggressively >>>>>> that there will be reused objects? >>>>> >>>>> JLS, section 5.1.7: >>>>> >>>>> "If the value p being boxed is true, false, a byte, >>>>> or a char in the range \u0000 to \u007f, or an int or >>>>> short number between -128 and 127 (inclusive), then let >>>>> r1 and r2 be the results of any two boxing conversions >>>>> of p. It is always the case that r1 == r2." >>>> >>>> Ah - so max. 256 objects in case of auto boxing. >>> If I'm reading that right, that is only 128 for bytes and chars. Every >>> byte with a high-bit set will be autoboxed to a new object. >>> >>> I'm surprised by this actually. I can see the justification in chars, >>> but bytes I would have just go with the full 00 to FF >> >> I don't think you're reading it right. Firstly, there's a comma after >> "byte". Secondly, given how little sense Unicode notation makes for >> bytes, it is doubtful that it should be meant to apply to them. And >> finally, both the source code and Javadoc for Byte#valueOf are >> unambiguous; to quote the latter: "all byte values are cached". > > Eats, shoots, and leaves. Yes, I missed the comma. That totally makes > sense now. What threw me off the most was that they listed "values" > (true/false), then "a type" (byte), and then "values for types". > > I might have worded it differently, but it is unambiguous as is. > > I think my preferred structure would have been "If the value being boxed > is is a char in the range ... or is a short or int in the range ... or > is any boolean or byte value ..." True, that formulation would be clearer. Looks like they, in true systematic fashion, went from the more simple to the more complex types. :) -- DF.