Lets supose I define a class
public class PointFloat {
float x;
float y;
}
Then I instantiate an array
PointFloat[] points = new PointFloat[10];
At this point I have an array of ten PointFloat Objects. Lets supose that some code assigns values x and y to every pointfloats.
What I need is to store that array in a VARBINARY in a Mysql database.
To accomplish this I would need to convert this array of PointFloats to byte[] so I can insert into the database using a PreparedStatement
Nothing new for me to use a PreparedStatement but first time using objects serialization.
How do you convert an array of PointFloat of any size to a byte[]?.
Please keep it as simple as possible.
Thank you very much for reading.
You can simply use an ObjectOutputStream to write your array into a ByteArrayOutputStream. See this answer for details and example: https://stackoverflow.com/a/2836659/337621
Since your object contains two floats, the standard serialization completely fits your needs.
At this point I have an array of ten PointFloat Objects
No. At this point, you have an array of 10 null references.
Choose how you want to transform the points to a byte array. You could design a custom representation, or use Java serialization, or JSON, or XML, for example.
I would choose a format that is readable whatever the language is, and that won't be unreadable as soon as you change the Point class (so not the native Java serialization). JSON is very compact (for a text-based representation). There are dozens of JSON serializers, for every language. They're all documented.
Related
I know what arrays are and how to use them. However, I don't know how they are implemented. I was trying to figure out if I can try to implement an array-like data structure using Java but I couldn't.
I've searched online but didn't find anything useful.
Is it even possible to implement an array-like data structure in Java? Is it possible in other languages? if so how (without using arrays of course)?
EDIT: what I want to know is how to implement an array data structure without using arrays?
Arrays are contiguous sections within memory, so to create an array you would need to reserve a chunk of memory which is of size n * sizeof(type), where n is the amount of items you would like to store and the sizeof(type) would return the size, in bytes which the JVM would need to represent that given type.
You would then store a reference (pointer) to the first location of your memory segment, say 0x00, and then you use that as a base to know how much you need to move to access the elements, so a[n] would be equal to doing 0x00 + (n * sizeof(type)).
The problem with trying to implement this in Java is that Java does not allow pointer manipulation, so I do not think that building your own array type would be possible since you cannot go down to that level.
That being said, you should be able to create a linked data structure, where the nth element points to the (n + 1)th element.
Other problems why you should try other languages, such as C# (check unsafe operations), C++ or C:
To my knowledge, Java does not have a sizeof function (see this).
Java does not allow operator overloading. So you cannot define your own indexing operators such as [index]. You would probably need to do something like array.getElementAt(0) to get the first element.
As #ug_ recommended, you could take a look at the Unsafe class. But also as he recommended, I do not think that you should do pointer arithmetic with a language which has pointer abstraction as one of its core ideas.
If what you want is something like this:
MyArray ma = new MyArray(length);
ma[0] = value;
Then you can't do this in Java but you can in other languages. Look for "operator overloading".
I'm wondering if your thinking of a structs, vectors or link lists. These are all similar to arrays but are different.
Structs are not really in java, but you can implement them.
Read up on Structs here:
www.cplusplus.com/doc/tutorial/structures/
An example Structs used in java:
Creating struct like data structure in Java
I think what you are really looking for though are vectors. They are very similar to an array, but their not one.
Vectors info:
www.cplusplus.com/reference/vector/vector/
Array compared to vector:
https://softwareengineering.stackexchange.com/questions/207308/java-why-do-we-call-an-array-a-vector
I recommend a link list. Its kinda the same idea of an array, but without knowing your exact size. It is easier to implement.
Link lists:
en.wikipedia.org/wiki/Linked_list
All these come down to the situation on what need them for. Saying , "what I want to know is how to implement an array data structure without using arrays?" is kinda open ended.
I am writing a program that will be heavily reliant on ... something ... that stores data like an array where I am able to access any point of the data at any given time as I can in an array.
I know that the java library has an Array class that I could use or I could use a raw array[].
I expect that using the Array type is a bit easier to code, but I expect that it is slightly less efficient as well.
My question is, which is better to use between these two, and is there a better way to accomplish the same result?
Actually Array would be of no help -- it's not what you think it is. The class java.util.ArrayList, on the other hand, is. In general, if you can program with collection classes like ArrayList, do so -- you'll more easily arrive at correct, flexible software that's easier to read, too. And that "if" applies almost all the time; raw arrays are something you use as a last resort or, more often, when a method you want to call requires one as an argument.
The Array class is used for Java reflection and is very, very, rarely used.
If you want to store data in an array, use plain old arrays, indicated with [], or as Gabe's comment on the question suggests, java.util.ArrayList. ArrayList is, as your comment suggests easier to code (when it comes to adding and removing elements!!) but yes, is slightly less efficient. For variable-size collections, ArrayList is all but required.
My question is, which is better to use between these two, and is there a better way to accomplish the same result?
It depends on what you are trying to achieve:
If the number of elements in the array is known ahead of time, then an array type is a good fit. If not, a List type is (at least) more convenient to use.
The List interface offers a number of methods such as contains, insert, remove and so on that can save you coding ... if you need to do that sort of thing.
If properly used, an array type will use less space. The difference is particularly significant for arrays of primitive types where using a List means that the elements need to be represented using wrapper types (e.g. byte becomes Byte).
The Array class is not useful in this context, and neither is the Arrays class. The choice is between ArrayList (or some other List implementation class) and primitive arrays.
In terms of ease of use, the Array class is a lot easier to code.
The array[] is quite a problem in terms of the case that you need to know
the size of the list of objects beforehand.
Instead, you could use a HashMap. It is very efficient in search as well as sorting as
the entire process is carried out in terms of key values.
You could declare a HashMap as:
HashMap<String, Object> map = new HashMap<String, Object>();
For the Object you can use your class, and for key use the value which needs to be unique.
I have some library of classes, working with my data, which is being read into buffer. Is it possible somehow to avoid copying arrays again and again, passing parts of data deeper and deeper into processing methods? Well, it sounds strange, but in my particular case, there's a special writer, which divides data into blocks and writes them individually into different locations, so it just performs System.arraycopy, gets what it needs and calls underlying writer, with that new sub array. And this happens many times. What is the best approach to refactor such code?
Arrays.asList(array).subList(x, y).
This method doesn't give you an array, but a List, which is far more flexible.
Many classes in Java accept a subset of an arrays as parameter. E.g. Writer.write(char cbuf[], int off, int len). Maybe this already suffices for your usecase.
There is no real way to wrap any data without copying and receive real array in Java. You just cannot create new array over existing memory. You have basically 2 options:
Use methods that can accept range of array. This was already recommended.
Use wrapper that gives some kind of abstraction that is close to array and is suitable for many applications. Will be described below.
You may use java.nio.Buffer classes hierarchy, especially java.nio.ByteBuffer which offers buffer abstraction on whole array or sub-ranges. Often it is what people need. This also offers many interesting abilities like 'zero copy' flip and flexible byte area representation.
Here is example of wrapping using java.nio.ByteBuffer.
This should be very close to what you need. At least for some operations.
byte [] a1 = {0, 0, 1, 0};
ByteBuffer buf = ByteBuffer.wrap(a1,1,2);
Then you can do on buf any ByteBuffer operation.
Just a warning, buf.array() returns original a1 array (backend) with all elements.
There is no way to declare a subarray in Java if you use built in arrays like byte[]. The reason is: The length of the array is stored with the data, not with the declaration of the reference to it. Hence a subarray which does not copy the data has no place where it can store the length!
So for basic types you can use the mentioned efficient byte array copies and for higher types (List) there are methods available.
You could take the same approach as the String class takes; create a class for immutable objects which are constructed from an array, a start offset and an end offset which offers access to the sub-array. The user of such an object does not have to know the distinction between the whole array or a sub-array. The constructor does not have to copy the array, just store the array reference and its boundaries.
You could use (ArrayList).subList(value1, value2) i belive, perhaps that could help in your case? That is ofcourse if you want to use an ArrayList.
Perhaps instead of working with arrays you should work with a different type that maintains a reference to a slice of the original array, instead of copying the data over, similar to ArraySegment in C#. An additional benefit to this is that you can also shift the slice over the original array on-demand, without creating new instances. Pseudo code:
public class ArraySegment<T> implements Iterable<T>
{
private int from, to;
private T[] original;
public ArraySegment<T>(T[] original, int from, int to)
{
//constructor stuff
}
public T get(int index)
{
return original[index + from];
}
public int size()
{
return to - from + 1;
}
#Override
public Iterator<T> iterator()
{
//Iterator that iterates over the slice
}
//Can support setters on from/to variables
}
Google's Guava libraries support the slice concept in the form of a ByteSource.
Google Guava is a readily available open-source package of functionality, written from the ground up to follow Google best practices, which depend on significant array slicing capabilities.
Have a look on Arrays.copyOfRange(***) methods.
Sometime back our architect gave this funda to me and I couldn't talk to him more to get the details at the time, but I couldn't understand how arrays are more serializable/better performant over ArrayLists.
Update: This is in the web services code if it is important and it can be that he might mean performance instead of serializability.
Update: There is no problem with XML serialization for ArrayLists.
<sample-array-list>reddy1</sample-array-list>
<sample-array-list>reddy2</sample-array-list>
<sample-array-list>reddy3</sample-array-list>
Could there be a problem in a distributed application?
There's no such thing as "more serializable". Either a class is serializable, or it is not. Both arrays and ArrayList are serializable.
As for performance, that's an entirely different topic. Arrays, especially of primitives, use quite a bit less memory than ArrayLists, but the serialization format is actually equally compact for both.
In the end, the only person who can really explain this vague and misleading statement is the person who made it. I suggest you ask your architect what exactly he meant.
I'm assuming that you are talking about Java object serialization.
It turns out that an array (of objects) and ArrayList have similar but not identical contents. In the array case, the serialization will consist of the object header, the array length and its elements. In the ArrayList case, the serialization consists of the list size, the array length and the first 'size' elements of the array. So one extra 32 bit int is serialized. There may also be differences in the respective object headers.
So, yes, there is a small (probably 4 byte) difference in the size of the serial representations. And it is possible that an array can be serialized / deserialized
slightly more quickly. But the differences are likely to be down in the noise, and not worth worrying about ... unless profiling, etc tells you this is a bottleneck.
EDIT
Based on #Tom Hawtin's comment, the object header difference is significant, especially if the serialization only contains a small number of ArrayList instances.
Maybe he was refering to XML-serialization used in Webservices ?
Having used those a few years ago, I remember that a Webservice returning a List object was difficult to connect to (at least I could not figure it out, probably because of the inner structure of ArrayLists and LinkedLists), although this was trivially done when a native array was returned.
To adress Reddy's comment,
But in any case (array or ArrayList)
will get converted to XML, right?
Yes they will, but the XML-serialization basically translated in XML all the data contained in the serialized object.
For an array, that is a series of values.
For instance, if you declare and serialize
int[] array = {42, 83};
You will probably get an XML result looking like :
<array>42</array>
<array>83</array
For an ArrayList, that is :
an array (obviously), which may have a size bigger than the actual number of elements
several other members such as integer indexes (firstIndex and lastIndex), counts, etc
(you can find all that stuff in the source for ArrayList.java)
So all of those will get translated to XML, which makes it more difficult for the Webservice client to read the actual values : it has to read the index values, find the actual array, and read the values contained between the two indexes.
The serialization of :
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(42);
list.add(83);
might end up looking like :
<firstIndex>0</firstIndex>
<lastIndex>2</lastIndex>
<E>42</E>
<E>83</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
So basically, when using XML-serialization in Webservices, you'd better use arrays (such as int[]) than collections (such as ArrayList<Integer>). For that you might find useful to convert Collections to arrays using Collection#toArray().
They both serialize the same data. So I wouldn't say one is significantly better than the other.
As of i know,both are Serializable but using arrays is better coz the main purpose of implementing the ArrayList is for internal easy manipulation purpose,not to expose to outer world.It is little heavier to use ,so when using in webservices while serializing it ,it might create problems in the namespace and headers.If it automatically sets them ,you ll not be able to receive or send data properly.So it is better to use primitive arrays .
Only in Java does this make a difference, and even then it's hard to notice it.
If he didn't mean Java then yes, your best bet would most likely be asking him exactly what he meant by that.
Just a related thought: The List interface is not Serializable so if you want to include a List in a Serializable API you are forced to either expose a Serializable implementation such as ArrayList or convert the List to an array. Good design practices discourage exposing your implementation, which might be why your architect was encouraging you to convert the List to an array. You do pay a little time penalty converting the List to an array, but on the other end you can wrap the array with a list interface with java.util.Arrays.asList(), which is fast.
Given that Java ME allows for no reflection and is quite stripped down, what would a good approach to storing data in a RecordStore be? I thought of devising a JSON-like syntax adapter class which would probably require every class whose values are to be stored to implement a Hashtable + might probably require an additional regex library as even that's been taken away.
If you're wondering why on earth I need it, it's for an assignment. So the dilemma is really between writing a rather unnecessarily large chunk of proper code as a matter of principle or hardcoding everything in knowing nobody has to suffer through maintenance of this junk down the line. But, the good principles person in me is leaning towards the former.
EDIT: I should have elaborated — I'd like to store object's data within the RecordStore, so I'm trying to devise a method to represent an object as a string which can then be converted into a byte array.
For every object you want to save in the RecordStore, pare it down to its component Strings and primitives, then serialise it to a byte array, using a ByteArrayOutputStream wrapped in a DataOutputStream. Then write this byte array to RMS.
Reverse the process using a ByteArrayInputStream wrapped in a DataInputStream to get the object back.