Append one array to another array

[June Moore]

Hi,
I would like to append the content of an array (Student[]) to another
array (Student[]).

Student[] oldStudent
Student[] newStudent

Can I do this?
newStudent = newStudent.add(oldStudent);

Thanks,
June.....

 

[VisionSet]

Hi,
I would like to append the content of an array (Student[]) to another
array (Student[]).

Student[] oldStudent
Student[] newStudent

Can I do this?
newStudent = newStudent.add(oldStudent);

No, because an array is immutable.
You will have to create a new array and copy the contents of both into it.
You may find System.arrayCopy() useful.

 

[VisionSet]

Hi,
I would like to append the content of an array (Student[]) to another
array (Student[]).

Student[] oldStudent
Student[] newStudent

Can I do this?
newStudent = newStudent.add(oldStudent);

No, because an array is immutable.
You will have to create a new array and copy the contents of both into it.
You may find System.arrayCopy() useful.

When I say immutable I refer to the size, this being your problem.
It is a poor word choice since an array is mutable as far as changing the
value of the element references.

ie you can do this

String[] myString = {"Original"};

myStringArray[0] = "Mutated";


Also note you can not call methods on Arrays, although they are Objects
there is no API for them.

java.util.Arrays being a utility class for services on Arrays and
java.lang.reflect.Array being a introspection class for accessing an Array
object. Neither can produce objects.

 

[Niels Dybdahl]

Student[] oldStudent

Student[] newStudent

Can I do this?
newStudent = newStudent.add(oldStudent);

You can do something similar, if you use Vectors instead of arrays.

Niels Dybdahl

 

[Lasse Reichstein Nielsen]

I would like to append the content of an array (Student[]) to another
array (Student[]).

Student[] oldStudent
Student[] newStudent

Can I do this?
newStudent = newStudent.add(oldStudent);

No, as the length of an array cannot change after it is created.

You need to create a new array to hold the data:
---
Student[] temp = new Student[oldStudent.length + newStudent.length];
System.arraycopy(newStudent, 0, temp, 0, newStudent.length)
System.arraycopy(oldStudent, 0, temp, newStudent.length, oldStudent.length);
newStudent = temp;
---

A little less low level (no fiddling with indices), you can use
collections to combine the two arrays:
---
List<Student> temp =
new ArrayList<Student>(oldStudent.length + newStudent.length);
temp.add(Arrays.asList(newStudent));
temp.add(Arrays.asList(oldStudent));
newStudent = (Student[]) temp.toArray(new Student[temp.size()]);

 

[Oscar kind]

You can do something similar, if you use Vectors instead of arrays.

Or better yet, use a List (and a class that implements this interface).
Since the new Collections framework came out, I consider it a good idea
not to use a Vector, unless:
- I know the subtle differences between a Vector and a List
- A List doesn't suffice, and I need the specifics of a Vector

 

[Tony Morris]

Also note you can not call methods on Arrays, although they are Objects
there is no API for them.

This is untrue.

Here is an example:

class X
{
public static void main(String[] args)
{
int[] i = new int[]{6, 7, 8};

System.out.println(i.toString());
System.out.println(i.hashCode());
System.out.println(i.equals(null));
}
}

 

[VisionSet]

Also note you can not call methods on Arrays, although they are Objects
there is no API for them.

This is untrue.

Here is an example:

class X
{
public static void main(String[] args)
{
int[] i = new int[]{6, 7, 8};

System.out.println(i.toString());
System.out.println(i.hashCode());
System.out.println(i.equals(null));
}
}

Of course, doh! Everything is an Object and inherits from Object (if it
isn't a primitive).
I suppose I meant it doesn't have its *OWN* public API.

 

[Michael Borgwardt]

This is untrue.

[]

Of course, doh! Everything is an Object and inherits from Object (if it
isn't a primitive).
I suppose I meant it doesn't have its *OWN* public API.

Actually, it has. Unlike Object instances, arrays have the public length field
and a public clone() method. See Java Language Specification section 10.7

 

[VisionSet]

Actually, it has. Unlike Object instances, arrays have the public length field
and a public clone() method. See Java Language Specification section 10.7

I wonder why they didn't make it a length() method - would feel more
intuitive especially since you stumble across this very early in learning
the language.

How could they have included the Array type in the javadocs?

 

[Michael Borgwardt]

I wonder why they didn't make it a length() method - would feel more
intuitive especially since you stumble across this very early in learning
the language.

I suppose it was for performance reasons - at the time the spec was written,
method calls really were much slower than access to a final field.

How could they have included the Array type in the javadocs?

There's no single "Array type". Of course, all Array types are derived from
Object[], but none of them, including Object[] are real classes, they're
synthesized by the JVM. And you can't have a javadoc entry for each of them,
because there's an infinite number: consider Object[], Object[][],
Object[][][], etc...

 

[VisionSet]

How could they have included the Array type in the javadocs?

There's no single "Array type". Of course, all Array types are derived from
Object[], but none of them, including Object[] are real classes, they're
synthesized by the JVM. And you can't have a javadoc entry for each of them,
because there's an infinite number: consider Object[], Object[][],
Object[][][], etc...

Makes sense. Thanks Michael.

 

[Lee Fesperman]

How could they have included the Array type in the javadocs?

There's no single "Array type". Of course, all Array types are derived from
Object[], but none of them, including Object[] are real classes, they're
synthesized by the JVM.

That's not right. An array of primitives can't be derived from Object[].

 

[Michael Borgwardt]

There's no single "Array type". Of course, all Array types are derived from
Object[], but none of them, including Object[] are real classes, they're
synthesized by the JVM.

That's not right. An array of primitives can't be derived from Object[].

Ah, you're right of course, I forgot about those.

So there's not even a common superclass for all array types (except for Object).

 

[Lee Fesperman]

There's no single "Array type". Of course, all Array types are derived from
Object[], but none of them, including Object[] are real classes, they're
synthesized by the JVM.

That's not right. An array of primitives can't be derived from Object[].

Ah, you're right of course, I forgot about those.

So there's not even a common superclass for all array types (except for Object).

Yep, Object is the only common superclass for array types. That's why System.arraycopy()
takes its array arguments as Object ;^)

 

[Thomas G. Marshall]

VisionSet coughed up:

I wonder why they didn't make it a length() method - would feel more
intuitive especially since you stumble across this very early in
learning the language.

How could they have included the Array type in the javadocs?

It's funny how an innocuous post like yours get come under such fire! LOL.
Welcome to Anal Quote International. I'm an offender too. In fact, I liked
it so much I bought the company.

I've always suspected that .length is a primitive and not an object is
because of a few things:

1. The array length is not something run-time
computable. The length is indeed immutable.

2. Efficiency (speed).

3. There is no need for it to be synchronized, as
a single primitive read is defined as atomic.

I've always wondered why there wasn't a specific class called Array that
/meant/ the array (forget he existing Array and Arrays classes). It would
allow us to use instanceof, instead of calling a dedicated method to check
an object for "arrayness". Furthermore, it might allow for some interesting
subclasses.


--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.

 

[Thomas G. Marshall]

Thomas G. Marshall coughed up:

VisionSet coughed up:


It's funny how an innocuous post like yours get come under such fire!
LOL. Welcome to Anal Quote International. I'm an offender too. In
fact, I liked it so much I bought the company.

I've always suspected that .length is a primitive and not an object

{SCREEEEEEEECHING brake, then collision, then rolling hub cap sounds all go
here}

I obviously meant "and not a method".

is because of a few things:

1. The array length is not something run-time
computable. The length is indeed immutable.

2. Efficiency (speed).

3. There is no need for it to be synchronized, as
a single primitive read is defined as atomic.

I've always wondered why there wasn't a specific class called Array
that /meant/ the array (forget he existing Array and Arrays classes).
It would allow us to use instanceof, instead of calling a dedicated
method to check an object for "arrayness". Furthermore, it might
allow for some interesting subclasses.

--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.

 

[Thomas G. Marshall]

Oscar kind coughed up:

Or better yet, use a List (and a class that implements this
interface). Since the new Collections framework came out, I consider
it a good idea not to use a Vector, unless:
- I know the subtle differences between a Vector and a List
- A List doesn't suffice, and I need the specifics of a Vector

There is only one good reason to use Vector.

The vector methods are synchronized. Now you can get a synchronized
arraylist at runtime, but you cannot get one at compile time for extension
into a subclass. For reasons that no one can adequately explain, the
classes responsible for such things are imbedded within Collections.java
with /package scope/.

If you /were/ to extend ArrayList, you would have to re-implement every
single method just to put the synchronized keyword in:

public synchronized void <method name>(<arg list>)
{
super.<method name>(<arg list>);
}

The <> are of course not generics, but just a syntax for the example...





--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.

 

[Lee Fesperman]

There is only one good reason to use Vector.

The vector methods are synchronized.

The second reason is 1.1 compatibility.

 

[Thomas Weidenfeller]

There is only one good reason to use Vector.

There are at least 102 more reasons. Vector is used 102 times in the
public API of J2SE 1.5.

/Thomas