0

I am using a byte array to store a text file outside of the filesystem.

It looks like this:

private static final byte[] CDRIVES = new byte[] {
        (byte)0xe0, 0x4f, (byte)0xd0, 0x20, (byte)0xea, 0x3a, 0x69, 0x10,
        (byte)0xa2, (byte)0xd8, 0x08, 0x00, 0x2b, 0x30, 0x30, (byte)0x9d,
        (byte)0xba, (byte)0x8a, 0x0d, 0x45, 0x25, (byte)0xad, (byte)0xd0, 0x11,
        (byte)0x98, (byte)0xa8, 0x08, 0x00, 0x36, 0x1b, 0x11, 0x03,
        (byte)0x80, 0x53, 0x1c, (byte)0x87, (byte)0xa0, 0x42, 0x69, 0x10,
        (byte)0xa2, (byte)0xea, 0x08, 0x00, 0x2b, 0x30, 0x30, (byte)0x9d
        ...
        ...
        ...
        };

Is there a way to avoid casting to (byte) for better visual interpretation?

I don't mind using other data type, but I need to be able build an InputStream out of it and do it the fastest way if possible. (for example storing a text file into a String variable is not the best way...)

arenaq
  • 2,304
  • 2
  • 24
  • 31
  • pls check this link if it is helpful to u
    [http://stackoverflow.com/questions/7619058/convert-a-byte-array-to-integer-in-java-and-vise-versa][1] [1]: http://stackoverflow.com/questions/7619058/convert-a-byte-array-to-integer-in-java-and-vise-versa     – kswaughs Jul 30 '15 at 07:39

1 Answers1

0

Well one simple approach would be to use base64 - but perform the conversion on class initialization, so you only take the performance hit once:

private static final byte[] CDRIVES = Base64.decode("YOURBASE64HERE");

Or if it's genuinely text, perform that encoding once in a similar way:

private static final byte[] CDRIVES =
    "Your constant text here".getBytes(StandardCharsets.UTF_8);

Again, the performance hit occurs exactly once, and then you can use the bytes multiple times. I would be very surprised if the cost of encoding text into bytes at class initialization time is genuinely a bottleneck for you.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Wow, answer from Jon Skeet himself :) Well... using Base64 is not a bad idea, problem is that it takes some time to convert Base64 string to a byte array using Base64.decode method, initializing into byte array directly is faster. And Base64 string is even worse to "manage" because its unreadable and one-liner. But still thanks for thinking outside of the box :) – arenaq Jul 30 '15 at 08:19
  • @arenaq: This is performed exactly once, at class initialization time. What *exactly* are your performance requirements, and how have you determined them? In terms of management, where is this data coming from? In many cases (e.g. if it's a file) if the data changes it'll be much easier to re-encode it as base64 and copy/paste that string into the code instead of specifying each byte separately... – Jon Skeet Jul 30 '15 at 08:27
  • Well... using byte array initialization directly, decoding will be performed exactly zero times ;) And since my text file could be 1 MB large and this code is running on Android, time is valuable ;) Data will come from a script, that will have file on input and the best answer to this question on output ;) – arenaq Jul 30 '15 at 08:37
  • @arenaq: If your text file could be 1MB large, you really *really* don't want to do it in an array initializer. Heck, at that point you may well blow up various constant limits on Java. I suggest you look at the bytecode emitted for array initializers. I'm not sure what would happen in the dex file, but in plain Java it's a really bad idea. I would *very strongly* urge you to load this from resources instead. Sure, time is valuable - but that doesn't mean you should just ignore the more straightforward option. Have you *tried* loading the data from a resource instead? – Jon Skeet Jul 30 '15 at 08:44
  • @arenaq: To put it another way: consider all the resources used for games on Android. They're going to be much larger than 1MB. Do you think *they're* all hardcoded? – Jon Skeet Jul 30 '15 at 08:44
  • It has a reason, I dont want the file in apk package for users to see ;) – arenaq Jul 30 '15 at 10:28
  • @arenaq: So they decompile your APK code and get the data that way. The obscurity there really isn't great, and do you *really* want to make your APK size much larger due to storing the data in an inefficient way? This really sounds like a terrible idea to me. – Jon Skeet Jul 30 '15 at 10:29
  • Do you have any other idea, how to prevent common user (with non-programming skills) to see certain file you are using, most importanly to prevent editing that file and creating his own apk? – arenaq Jul 30 '15 at 10:33