How to convert image into Hex 2 Dimensional Array?

Discussion in 'Java' started by sout saret, May 8, 2013.

  1. sout saret

    sout saret Guest

    Dear Community!

    May you help me how to write code in java to convert image to Hex 2 dimensional array. I want to show format as below:

    {
    {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x1B,0xFB,0x12,0x0A,0x1B,0x0B,0x09,0x09,0x19,0x09,0x19,0x29,0x19,0xE9,0x00,0x20,0x00,0x60,0x00,0x00,0x00,0x00,0x00,0x00,},
    {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x6D,0xFD,0x48,0x05,0x6D,0xF5,0x25,0x14,0x25,0x15,0x25,0x15,0xFD,0x15,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    {0x00,0xC0,0x01,0x00,0x01,0xC0,0x00,0x00,0xBC,0x78,0x24,0x48,0xA4,0x48,0xA4,0x48,0xB4,0x48,0xB5,0x48,0xB6,0xC8,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    };

    Best Regard!

    Saret Sout
     
    sout saret, May 8, 2013
    #1
    1. Advertising

  2. sout saret

    Joerg Meier Guest

    On Wed, 08 May 2013 09:06:09 +0100, lipska the kat wrote:

    > On 08/05/13 07:30, sout saret wrote:
    >> May you help me how to write code in java to convert image to Hex 2 dimensional array. I want to show format as below:

    > [snip]


    > hmm, sounds like homework.


    It sounded more like he wanted to hardcode an image into his class files,
    which is a fantastically terrible idea that's usually attempted by people
    who decided that loading resources in jar files is too complicated to
    figure out, which is why I stayed away ;)

    Liebe Gruesse,
    Joerg

    --
    Ich lese meine Emails nicht, replies to Email bleiben also leider
    ungelesen.
     
    Joerg Meier, May 8, 2013
    #2
    1. Advertising

  3. On 08/05/2013 10:06, lipska the kat allegedly wrote:
    > Byte[][] bytes = new Byte[width][height];


    Lipska, mind the difference between Byte and byte. That code above is
    extremely bad advice.

    --
    DF.
     
    Daniele Futtorovic, May 8, 2013
    #3
  4. sout saret

    Jeff Higgins Guest

    On 05/08/2013 02:30 AM, sout saret wrote:
    > Dear Community!
    >
    > May you help me how to write code in java
    > to convert image to Hex 2 dimensional array.
    > I want to show format as below:
    >

    You've asked too much for a simple usenet post.
    You might read the article here:
    <http://www.developer.com/java/other/article.php/3403921>
    It's a pretty long article but at the end you should
    understand how to get the image data and then you will
    only need to figure out how to represent it as a hex string
     
    Jeff Higgins, May 8, 2013
    #4
  5. sout saret

    Daniel Pitts Guest

    On 5/8/13 6:57 AM, lipska the kat wrote:
    > On 08/05/13 14:19, Daniele Futtorovic wrote:
    >> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>> Byte[][] bytes = new Byte[width][height];

    >>
    >> Lipska, mind the difference between Byte and byte. That code above is
    >> extremely bad advice.

    >
    > Why? it's common practice these days to eschew primitives and use
    > (autoboxing) classes

    Common practice where? Cite a credible source or I'll be forced to think
    that you are just making up facts to support your mistake. My 4 year
    old daughter does that; you want to be more credible than my 4 year old,
    don't you?

    > it's more consistent in OO code and, as I
    > understand things, post autoboxing, the following two lines are
    > logically equivalent.
    >
    > 1. Byte[][] bytes = new Byte[width][height];
    > 2. byte[][] bytes = new byte[width][length]


    Even ignoring the typos, those are nothing alike.

    Auto-boxing is a convenience, but does not make those two things the
    same, even by a long shot.

    byte cannot contain a NULL reference. It contains no reference
    whatsoever. Byte on the other hand *can* contain a reference.

    byte[] is *not* assignable to Byte[], and Byte[] is *not* assignable to
    byte[].

    You also cannot use arrayCopy to copy between the two.

    Boxing and Unboxing (whether manual or automatic) *does* have a cost. It
    may be minimal, and shouldn't be the only consideration. It should
    however be noted and considered as part of the choice.

    Personally my decision on whether to use Byte vs byte would hinge solely
    on the question "do I want to store nulls in this?"

    Also, I would likely wrap that primitive value in a semantic class. I
    still lament that Java doesn't have "value types" other than the
    predefined primitives, but I have learned to be "okay" with that.
     
    Daniel Pitts, May 8, 2013
    #5
  6. On 08/05/2013 15:57, lipska the kat allegedly wrote:
    > On 08/05/13 14:19, Daniele Futtorovic wrote:
    >> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>> Byte[][] bytes = new Byte[width][height];

    >>
    >> Lipska, mind the difference between Byte and byte. That code above is
    >> extremely bad advice.

    >
    > Why? it's common practice these days to eschew primitives and use
    > (autoboxing) classes, it's more consistent in OO code and, as I
    > understand things, post autoboxing, the following two lines are
    > logically equivalent.
    >
    > 1. Byte[][] bytes = new Byte[width][height];
    > 2. byte[][] bytes = new byte[width][length]
    >
    > The following is perfectly legal given either of the above
    >
    > byte b = 127;
    > bytes[0][0] = b;
    > Byte c = 126;
    > bytes[0][1] = c;
    > Byte d = bytes[0][0];
    > byte e = bytes[0][1];
    >
    > I would of course be interested to know what your objection is.


    Simple: "byte[]" is not a primitive type. "byte" is a primitive type.
    "byte[]" is a reference type.

    Along the same lines, you'll be hard pressed to find a Java I/O library
    that uses Byte[]'s rather than byte[]'s.

    > Also, I seem to remember being 'told off' for using primitives a while
    > back ... ho hum.


    I don't know about that.

    --
    DF.
     
    Daniele Futtorovic, May 8, 2013
    #6
  7. sout saret

    Jeff Higgins Guest

    On 05/08/2013 04:06 AM, lipska the kat wrote:
    > On 08/05/13 07:30, sout saret wrote:
    >> Dear Community!
    >>
    >> May you help me how to write code in java to convert image to Hex 2
    >> dimensional array. I want to show format as below:

    >
    > [snip]
    >
    > hmm, sounds like homework.


    hmm. Sounds like the beginning of another snarky reply.

    >
    > 1. get hold of the javadoc for your chosen Java version
    >
    > Then ...
    >
    > To get you started.
    >
    > import javax.swing.ImageIcon;
    >
    > public class ImageToHex {
    >
    > public static void main(String[] args) {
    >
    > ImageIcon ii = new ImageIcon("/path/to/image.ext");
    > Integer width = ii.getIconWidth();
    > Integer height = ii.getIconHeight();
    > Byte[][] bytes = new Byte[width][height];
    > //you now have 2 dimensional array into which
    > //you can read your image bytes
    > //the rest is up to you I guess
    > }
    > }
    >
    > I'm sure there are other/better ways of doing it
    >


    WTF Why bother?
     
    Jeff Higgins, May 8, 2013
    #7
  8. On 5/8/2013 8:57 AM, lipska the kat wrote:
    > Why? it's common practice these days to eschew primitives and use
    > (autoboxing) classes, it's more consistent in OO code and, as I
    > understand things, post autoboxing, the following two lines are
    > logically equivalent.
    >
    > 1. Byte[][] bytes = new Byte[width][height];


    This creates an array with every entry prefilled to NULL.
    > 2. byte[][] bytes = new byte[width][length]


    This creates an array with every entry prefilled to 0.

    Ergo, not logically equivalent, even if I assume that your height/length
    was a typo.
    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer ðŸ§, May 8, 2013
    #8
  9. On 08/05/2013 18:17, lipska the kat allegedly wrote:
    > On 08/05/13 16:32, Daniele Futtorovic wrote:
    >> On 08/05/2013 15:57, lipska the kat allegedly wrote:
    >>> On 08/05/13 14:19, Daniele Futtorovic wrote:
    >>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>>>> Byte[][] bytes = new Byte[width][height];
    >>>>
    >>>> Lipska, mind the difference between Byte and byte. That code above is
    >>>> extremely bad advice.
    >>>
    >>> Why? it's common practice these days to eschew primitives and use
    >>> (autoboxing) classes, it's more consistent in OO code and, as I
    >>> understand things, post autoboxing, the following two lines are
    >>> logically equivalent.
    >>>
    >>> 1. Byte[][] bytes = new Byte[width][height];
    >>> 2. byte[][] bytes = new byte[width][length]

    >
    > typo notwithstanding oops :-(
    >
    >>> The following is perfectly legal given either of the above
    >>>
    >>> byte b = 127;
    >>> bytes[0][0] = b;
    >>> Byte c = 126;
    >>> bytes[0][1] = c;
    >>> Byte d = bytes[0][0];
    >>> byte e = bytes[0][1];
    >>>
    >>> I would of course be interested to know what your objection is.

    >>
    >> Simple: "byte[]" is not a primitive type.

    >
    > I wasn't aware that I said it was


    When I called out your using a Byte[] rather than byte[] in your example
    code, you defended it on the grounds of an alleged "common practice" to
    use (boxed) reference types instead of primitive types. Thereby, you
    have implied that byte[] was a primitive type; otherwise your whole
    argument would have been a non sequitur.

    But byte[] is not a primitive type, and hence your argument,
    irrespectively of its merits (see below), does not apply.

    >> "byte" is a primitive type.
    >> "byte[]" is a reference type.

    >
    > no argument there but what is your *objection* to
    >
    > Byte[][] bytes = new Byte[width][height];
    >
    > in the context of the OPs question?


    Objection? It's bullcrap. Firstly, no I/O library uses Byte[]. Secondly,
    as Daniel has indicated, the only reason to use Byte[] over byte[] would
    be to store null references. Which the OP doesn't need, as they have
    actual data. And lastly, it's dangerous because it furthers the very
    thing that, I reckon, lead you to use it in the first place: the
    confusion induced by autoboxing.

    General OO matters set aside, in the context of Java, autoboxing is a
    poison. The meagre convenience it provides is largely offset by the
    confusion, or lack of clarity, it causes in the minds of Java
    programmers, especially aspirant Java programmers. I've witnessed its
    nefarious effects countless times in my colleagues' code. A for/each
    loop is exactly the same thing as a normal for loop with an iterator.
    But, for better or for worse, in Java, a boxed reference type and a
    primitive type are two completely different things. Autoboxing induces
    the thought that they're not. That's why it's poison.

    --
    DF.
     
    Daniele Futtorovic, May 8, 2013
    #9
  10. sout saret

    Eric Sosman Guest

    On 5/8/2013 11:22 AM, Daniel Pitts wrote:
    > On 5/8/13 6:57 AM, lipska the kat wrote:
    >> On 08/05/13 14:19, Daniele Futtorovic wrote:
    >>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>>> Byte[][] bytes = new Byte[width][height];
    >>>
    >>> Lipska, mind the difference between Byte and byte. That code above is
    >>> extremely bad advice.

    >>
    >> Why? it's common practice these days to eschew primitives and use
    >> (autoboxing) classes

    > Common practice where? Cite a credible source or I'll be forced to think
    > that you are just making up facts to support your mistake. My 4 year
    > old daughter does that; you want to be more credible than my 4 year old,
    > don't you?
    >
    >> it's more consistent in OO code and, as I
    >> understand things, post autoboxing, the following two lines are
    >> logically equivalent.
    >>
    >> 1. Byte[][] bytes = new Byte[width][height];
    >> 2. byte[][] bytes = new byte[width][length]

    >
    > Even ignoring the typos, those are nothing alike.
    >
    > Auto-boxing is a convenience, but does not make those two things the
    > same, even by a long shot.


    For example, consider what happens when `int x = bytes[0][0];'
    immediately follows either of the above. In case 2, it sets x
    to zero. In case 1, the JVM throws NullPointerException. That's
    not "logically equivalent" in my book!

    >[...]
    > Personally my decision on whether to use Byte vs byte would hinge solely
    > on the question "do I want to store nulls in this?"


    Or on "Do I want to put it in a Collection?"

    There's also the matter of the memory footprint, even if
    "efficiency" is a dirty word in some circles. Version 1 will
    use four times (32-bit JVM) or eight times (64-bit) as much
    memory as version 2. Image sizes vary, but even a fairly modest
    640x480 has 300K pixels -- so using Byte[][] instead of byte[][]
    would cost an extra 0.9MB or 2.1MB. Even if I had the desire to
    store nulls, a bloat of such proportions would probably prompt
    me to use byte[][] and seek another way to represent whatever
    I wanted the nulls to stand for.

    --
    Eric Sosman
    d
     
    Eric Sosman, May 8, 2013
    #10
  11. On 5/8/2013 1:30 AM, sout saret wrote:
    > Dear Community!
    >
    > May you help me how to write code in java to convert image to Hex 2 dimensional array. I want to show format as below:


    What format is this two-dimensional array? Looking from your code, you
    appear to want it to be some sort of 256-byte pixel value, but are you
    desiring:
    1. 8-bit ARGB
    2. 5-6-5 RGB
    3. 8-bit grayscale
    4. 32-bit ARGB
    5. 24-bit RGB
    6. Binary version of any widely-used image format, including but not
    limited to PNG, BMP, GIF, JPG, XBM, TIF, and ICO.
    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer ðŸ§, May 8, 2013
    #11
  12. On 5/8/2013 12:40 PM, lipska the kat wrote:
    > On 08/05/13 17:52, Joshua Cranmer 🧠wrote:
    >> On 5/8/2013 1:30 AM, sout saret wrote:
    >>> Dear Community!
    >>>
    >>> May you help me how to write code in java to convert image to Hex 2
    >>> dimensional array. I want to show format as below:

    >>
    >> What format is this two-dimensional array? Looking from your code, you
    >> appear to want it to be some sort of 256-byte pixel value, but are you
    >> desiring:
    >> 1. 8-bit ARGB
    >> 2. 5-6-5 RGB
    >> 3. 8-bit grayscale
    >> 4. 32-bit ARGB
    >> 5. 24-bit RGB
    >> 6. Binary version of any widely-used image format, including but not
    >> limited to PNG, BMP, GIF, JPG, XBM, TIF, and ICO.

    >
    > I think he wants a byte for byte copy so the first byte gets copied into
    > [0][0] the next into [1][0] the next [2][0] etc until [width-1][0]
    > then start again at [0][1], [1][1], [2][1] etc etc


    A byte for byte copy of what? I'm guessing the answer is the "pixel
    matrix", but that's underdefined since pixels can take on many different
    formats, which is what I was trying to get at--what encoding of a pixel
    is desired?

    Things get even more fun if you don't want an RGB colorspace--HSL is
    often better for manipulation, but YCbCr or CIELAB are more
    representative of how the human eye perceives color and are used in
    lossy compression and scientific image processing, for that reason.
    Also, even just RGB is a meaningless term because there are several
    different RGB colorspaces, the most common being sRGB and Adobe RGB.

    If you just want to statically convert an image into this format for use
    as an internal resource, I'd recommend not coding it in Java but using
    ImageMagick to convert the image to something like PBM which specifies
    the pixel data in a simple ASCII format:
    <http://en.wikipedia.org/wiki/Netpbm_format>.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer ðŸ§, May 8, 2013
    #12
  13. sout saret

    Daniel Pitts Guest

    On 5/8/13 9:03 AM, lipska the kat wrote:
    > On 08/05/13 16:22, Daniel Pitts wrote:
    >> On 5/8/13 6:57 AM, lipska the kat wrote:
    >>> On 08/05/13 14:19, Daniele Futtorovic wrote:
    >>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>>>> Byte[][] bytes = new Byte[width][height];
    >>>>
    >>>> Lipska, mind the difference between Byte and byte. That code above is
    >>>> extremely bad advice.
    >>>
    >>> Why? it's common practice these days to eschew primitives and use
    >>> (autoboxing) classes

    >> Common practice where? Cite a credible source or I'll be forced to think
    >> that you are just making up facts to support your mistake. My 4 year
    >> old daughter does that; you want to be more credible than my 4 year old,
    >> don't you?

    >
    > Think what you like, your opinion of my credibility is of no importance
    > to me.
    >
    > In the context of the OPs question, why is it bad advice to suggest
    > Byte[][] as opposed to byte[][]
    >
    > [snip]

    Given in the part you snipped. Try again.

    >
    >> Personally my decision on whether to use Byte vs byte would hinge solely
    >> on the question "do I want to store nulls in this?
    >> Also, I would likely wrap that primitive value in a semantic class.

    >
    > What primitive value? a byte?
    > There is already a wrapper class, it's called Byte ???

    The "Byte" class is a primitive wrapper. I would wrap it with a semantic
    class which determines what that byte represents. Although, I wouldn't
    be likely to write that for a byte, but other primitives I would.
     
    Daniel Pitts, May 8, 2013
    #13
  14. On 08/05/2013 19:25, lipska the kat allegedly wrote:
    > On 08/05/13 17:46, Daniele Futtorovic wrote:
    >> On 08/05/2013 18:17, lipska the kat allegedly wrote:
    >>> On 08/05/13 16:32, Daniele Futtorovic wrote:
    >>>> On 08/05/2013 15:57, lipska the kat allegedly wrote:
    >>>>> On 08/05/13 14:19, Daniele Futtorovic wrote:
    >>>>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>>>>>> Byte[][] bytes = new Byte[width][height];
    >>>>>>
    >>>>>> Lipska, mind the difference between Byte and byte. That code above is
    >>>>>> extremely bad advice.
    >>>>>
    >>>>> Why? it's common practice these days to eschew primitives and use
    >>>>> (autoboxing) classes, it's more consistent in OO code and, as I
    >>>>> understand things, post autoboxing, the following two lines are
    >>>>> logically equivalent.
    >>>>>
    >>>>> 1. Byte[][] bytes = new Byte[width][height];
    >>>>> 2. byte[][] bytes = new byte[width][length]
    >>>
    >>> typo notwithstanding oops :-(
    >>>
    >>>>> The following is perfectly legal given either of the above
    >>>>>
    >>>>> byte b = 127;
    >>>>> bytes[0][0] = b;
    >>>>> Byte c = 126;
    >>>>> bytes[0][1] = c;
    >>>>> Byte d = bytes[0][0];
    >>>>> byte e = bytes[0][1];
    >>>>>
    >>>>> I would of course be interested to know what your objection is.
    >>>>
    >>>> Simple: "byte[]" is not a primitive type.
    >>>
    >>> I wasn't aware that I said it was

    >>
    >> When I called out your using a Byte[] rather than byte[] in your example
    >> code, you defended it on the grounds of an alleged "common practice" to
    >> use (boxed) reference types instead of primitive types. Thereby, you
    >> have implied that byte[] was a primitive type;

    >
    > There was no such implication, you are mistaken.


    Okay, whatever.

    --
    DF.
     
    Daniele Futtorovic, May 8, 2013
    #14
  15. Le mercredi 8 mai 2013 08:30:25 UTC+2, sout saret a écrit :
    > Dear Community!
    >
    >
    >
    > May you help me how to write code in java to convert image to Hex 2 dimensional array. I want to show format as below:
    >
    >
    >
    > {
    >
    > {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x1B,0xFB,0x12,0x0A,0x1B,0x0B,0x09,0x09,0x19,0x09,0x19,0x29,0x19,0xE9,0x00,0x20,0x00,0x60,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x6D,0xFD,0x48,0x05,0x6D,0xF5,0x25,0x14,0x25,0x15,0x25,0x15,0xFD,0x15,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > {0x00,0xC0,0x01,0x00,0x01,0xC0,0x00,0x00,0xBC,0x78,0x24,0x48,0xA4,0x48,0xA4,0x48,0xB4,0x48,0xB5,0x48,0xB6,0xC8,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,},
    >
    > };
    >
    >
    >
    > Best Regard!
    >
    >
    >
    > Saret Sout


    You should have a look in the javadoc at the BufferedImage class.

    Method getRGB(int x, int y)
    or
    getRed() getGreen() getBlue() getAlpha()

    and then loop and output in hex format.

    Seems trivial.
     
    Manuel Dahmen, May 8, 2013
    #15
  16. sout saret

    Arne Vajhøj Guest

    On 5/8/2013 9:57 AM, lipska the kat wrote:
    > On 08/05/13 14:19, Daniele Futtorovic wrote:
    >> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>> Byte[][] bytes = new Byte[width][height];

    >>
    >> Lipska, mind the difference between Byte and byte. That code above is
    >> extremely bad advice.

    >
    > Why? it's common practice these days to eschew primitives and use
    > (autoboxing) classes,


    No - it is not.

    And especially not when it comes to arrays.

    > it's more consistent in OO code and, as I
    > understand things, post autoboxing, the following two lines are
    > logically equivalent.
    >
    > 1. Byte[][] bytes = new Byte[width][height];
    > 2. byte[][] bytes = new byte[width][length]


    Not at all.

    You will eventually end up with 1+width*height and 1 objects respectively.

    > The following is perfectly legal given either of the above
    >
    > byte b = 127;
    > bytes[0][0] = b;
    > Byte c = 126;
    > bytes[0][1] = c;
    > Byte d = bytes[0][0];
    > byte e = bytes[0][1];


    Yes.

    But the fact that you can make those assignments does not
    make the two declarations equivalent.

    > I would of course be interested to know what your objection is.


    Typically you want value semantics for a case like this.

    And all those objects will come with significant overhead (which may
    be important in some contexts).

    > Also, I seem to remember being 'told off' for using primitives a while
    > back ... ho hum.


    If someone said that for a case like this, then you have been listening
    to the wrong person.

    Arne
     
    Arne Vajhøj, May 9, 2013
    #16
  17. sout saret

    Arne Vajhøj Guest

    On 5/8/2013 12:48 PM, lipska the kat wrote:
    > On 08/05/13 16:22, Daniel Pitts wrote:
    >> On 5/8/13 6:57 AM, lipska the kat wrote:
    >>> On 08/05/13 14:19, Daniele Futtorovic wrote:
    >>>> On 08/05/2013 10:06, lipska the kat allegedly wrote:
    >>>>> Byte[][] bytes = new Byte[width][height];
    >>>>
    >>>> Lipska, mind the difference between Byte and byte. That code above is
    >>>> extremely bad advice.
    >>>
    >>> Why? it's common practice these days to eschew primitives and use
    >>> (autoboxing) classes

    >> Common practice where? Cite a credible source or I'll be forced to think
    >> that you are just making up facts to support your mistake. My 4 year
    >> old daughter does that; you want to be more credible than my 4 year old,
    >> don't you?

    >
    > Hmm
    >
    > http://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html
    >
    > <cite>
    > So when should you use autoboxing and unboxing? Use them only when there
    > is an “impedance mismatch” between reference types and primitives, for
    > example, when you have to put numerical values into a collection. It is
    > not appropriate to use autoboxing and unboxing for scientific computing,
    > or other performance-sensitive numerical code. An Integer is not a
    > substitute for an int; autoboxing and unboxing blur the distinction
    > between primitive types and reference types, but they do not eliminate it.
    > </cite>
    >
    > So, I'll agree that my assertion of logical equivalence is bollocks


    Good.

    > However I'm still not convinced that mixing primitives and reference
    > types is a 'good idea' in OO code.


    I would expect almost any Java program to use both ref types and
    value types.

    And the equivalent in C#.

    Lots of generic collection code and ORM code even mixes primitives
    with their ref type wrappers, because that is necessary in the
    context (Java implementation of generics and databases NULL values).

    Arne
     
    Arne Vajhøj, May 9, 2013
    #17
  18. sout saret

    Eric Sosman Guest

    On 5/8/2013 9:04 PM, Arne Vajhøj wrote:
    > On 5/8/2013 9:57 AM, lipska the kat wrote:
    >> [...] the following two lines are
    >> logically equivalent.
    >>
    >> 1. Byte[][] bytes = new Byte[width][height];
    >> 2. byte[][] bytes = new byte[width][length]

    >
    > Not at all.
    >
    > You will eventually end up with 1+width*height and 1 objects respectively.


    No; both will generate 1+width objects:

    - One array containing `width' references to other arrays,

    - `width' arrays containing `height' bytes or Byte
    references.

    A *really* stupid coder might use Byte[][] *and* populate
    the arrays with `new Byte(value)' repeated `width*height' times;
    that would produce `1 + width + width*height' objects in all.
    Autoboxers would be unlikely to enter that particular trap --
    but even so, a four- to eight-fold memory bloat is not to be
    sneezed at.

    --
    Eric Sosman
    d
     
    Eric Sosman, May 9, 2013
    #18
  19. sout saret

    Arne Vajhøj Guest

    On 5/8/2013 9:45 PM, Eric Sosman wrote:
    > On 5/8/2013 9:04 PM, Arne Vajhøj wrote:
    >> On 5/8/2013 9:57 AM, lipska the kat wrote:
    >>> [...] the following two lines are
    >>> logically equivalent.
    >>>
    >>> 1. Byte[][] bytes = new Byte[width][height];
    >>> 2. byte[][] bytes = new byte[width][length]

    >>
    >> Not at all.
    >>
    >> You will eventually end up with 1+width*height and 1 objects
    >> respectively.

    >
    > No; both will generate 1+width objects:
    >
    > - One array containing `width' references to other arrays,
    >
    > - `width' arrays containing `height' bytes or Byte
    > references.
    >
    > A *really* stupid coder might use Byte[][] *and* populate
    > the arrays with `new Byte(value)' repeated `width*height' times;
    > that would produce `1 + width + width*height' objects in all.
    > Autoboxers would be unlikely to enter that particular trap --
    > but even so, a four- to eight-fold memory bloat is not to be
    > sneezed at.


    Ooops.

    1+width+width*height and 1+width objects.

    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.

    Arne
     
    Arne Vajhøj, May 9, 2013
    #19
  20. sout saret

    Arne Vajhøj Guest

    On 5/8/2013 9:59 PM, Arne Vajhøj wrote:
    > On 5/8/2013 9:45 PM, Eric Sosman wrote:
    >> On 5/8/2013 9:04 PM, Arne Vajhøj wrote:
    >>> On 5/8/2013 9:57 AM, lipska the kat wrote:
    >>>> [...] the following two lines are
    >>>> logically equivalent.
    >>>>
    >>>> 1. Byte[][] bytes = new Byte[width][height];
    >>>> 2. byte[][] bytes = new byte[width][length]
    >>>
    >>> Not at all.
    >>>
    >>> You will eventually end up with 1+width*height and 1 objects
    >>> respectively.

    >>
    >> No; both will generate 1+width objects:
    >>
    >> - One array containing `width' references to other arrays,
    >>
    >> - `width' arrays containing `height' bytes or Byte
    >> references.
    >>
    >> A *really* stupid coder might use Byte[][] *and* populate
    >> the arrays with `new Byte(value)' repeated `width*height' times;
    >> that would produce `1 + width + width*height' objects in all.
    >> Autoboxers would be unlikely to enter that particular trap --
    >> but even so, a four- to eight-fold memory bloat is not to be
    >> sneezed at.

    >
    > Ooops.
    >
    > 1+width+width*height and 1+width objects.
    >
    > 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?

    Arne
     
    Arne Vajhøj, May 9, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    10
    Views:
    6,215
    Neredbojias
    Aug 19, 2005
  2. Venkat
    Replies:
    4
    Views:
    975
    Venkat
    Dec 5, 2003
  3. Bengt Richter
    Replies:
    6
    Views:
    471
    Juha Autero
    Aug 19, 2003
  4. chirs
    Replies:
    3
    Views:
    166
    Dr John Stockton
    Dec 1, 2003
  5. sout saret
    Replies:
    1
    Views:
    274
    Jim Gibson
    May 8, 2013
Loading...

Share This Page