SequentialList extends AbstractList - implementing unmodifiable list

[Nicholas Jordan]

As a design decision, I have chosen - this morning, while writing some GUI that will display some file content, to implment Abstract List and have a file-scope class thus:

// Counter-example of ByteArrayOutputStream
class SequentialList extends AbstractList<Byte[]>
{
    super(new Byte[]);
    public Byte get(int index)
    {
        ;//
    }
    public int size()
    {
        ;
    }
}

That code is directly copy-pasted from work an hour ago, that is as far as I got. I have not attempted a compile yet.... I am seeking suggestions on how the internal buffer should be implemented. Likely, the constructor will take a file. Some of the files will be in proprietary format, and thus I cannot do any writes. That is how I came to the decision to implement AbstractList as an unmodifiable list, from the comments in the source file.

While driving in, it occured to me that storing the read as an array of Byte may make the design bulky for no reason and to no gain. I am sure there are library implementations of what I am trying to do, I am seeking suggestions and counter-claim.

The design goal is: Given a File ( or subclass ) in the constructor, read in a few pages at most / close the file / probaly retain info such as file size and filename extension. Probably will need a constructor or method call for getting blocks from various parts of a file for large files.

A major design issue here is that some proprietary file formats have embedded nulls and all manner of control characters that will not convert to DBCS in any sane approach. My first idea for that is to trap any exceptions and mark that zone incontrovertible, testing for language like constructs using digraphs and trigraphs ( and reading some more unicode articles ) and keeping the whole buffer distinct and well separated from the storage media.

That is not my question, my question is: Something in the library that will do this already?

[Jim Yingst]

I can't really follow what you're trying to do here. Do you want a List<Byte[]> or a List<Byte>? Because your code shows a List<Byte[]> with a get() method that returns a Byte, which won't work. Which are you trying for? There's also a super(new Byte[]) call that makes no sense at all to me. Really, if you use your compiler before you show us code, it will help weed out these confusing side issues and let you focus more on meatier things.

[Nicholas Jordan]

[Jim Yingst:]   I can't really follow what you're trying to do here. Do you want a List<Byte[]> or a List<Byte>?
The question is prior to that, the code was my first thinking - I noted the incompatible return type. My area of thought is to read in a file, read-only, close the file then have a buffer that I may inspect with no chance of either modifiying the disc or having exceptions at runtime show up in the screen-view. My first effort found comments in the interface definition that stated

To implement an unmodifiable list, the programmer needs only to extend this class and provide implementations for the get(int index) and size() methods.

which was exactly what I wanted to do so that I could focus more on meatier things. ( no parody intended )

I thought, perhaps incorrectly, that I could declare the type of the list to be a byte array and chose Byte[] as I assumed a superclass constructor would only work with an Object ~ not a primitive. It occured to me instead of trying to wander around ( no pun again ) I could probably find something in the library that had a lot of unforseen already discovered and thus could subject trials to compiler observations.

To do that would collapse my needed effort here in a spectacular fashion.



{ message edit: I was working on the same base isssue in another area of the program. I notice that JTextPane(StyledDocument doc) and other areas I was looking at do not throw exceptions when the mime/type is not recognized. What I am working on here, let us say that someone codes <!-- Order pizza for lunch. --> and it is the policy of the site not to eat pizza in the building. It must be eaten in the parking garage. ( ?.. okay, they're nuts ) I need to be able to pass something like that to an area of the code that can try to do something with it.

There are many formats. Only a few are recognized in Editor Kits. }
[ May 13, 2008: Message edited by: Nicholas Jordan ]

[Jim Yingst]

For what you describe, couldn't you just use a RandomAccessFile opened in read-only mode ("r"")? You can use read() or readFully() to populate a byte[] buffer. Yes, every time you do this, you could get an exception - but that's also true for the solution you were describing, every time you exhaust one buffer and call next() or get() to retrieve more data. The point is, the exception may occur during the read() or noxt() or get(), but once that method returns successfully, you can examine the byte[] array with no chance of either (a) a further IOException while you examine the byte[], or (b) you modifying the file in any way.

[Nicholas Jordan]

Okay, I am going to go directly to java.io.RandomAccessFile,... I just got a clean build on ( a very large source file ) and will plug that directly into that and move it into the control class just as soon as I get back to that.

Thank you.