However, this only works if I have initialized vertexShaderID before passing it into the function. The sample program above encapsulates what is happening. If I don't assign the ID before calling compileShader OpenGL sends and error.

I'd like the compileShader function to assign the ID with the call to gl.glCreateShader instead of doing that before the function is called.

In Java, an object passed through a method is automatically passed by reference, and a primitive is passed by value, and there is no way to distinguish. The solution, therefore, is to use an Integer object instead of an actual int, or return an int and assign it.

OK, well I did post in clueless newbies! lol. But, I get the point now: primitives are assigned, and passed by value, so I would have to have an Object with a null to pass to a function for initialization if I wanted that. I think I get it now.

Ofcourse not. An Integer instance is immutable, so you cannot change its value.

Yes, of course you're right... you always seem to be the person who catches my mistakes.

Also if you have an object and then you create a new version of it when inside your function, you're going to lose your pointer which is what you need.

1 2 3 4 5 6 7 8 9

publicvoidfunction(Objecto, Objectp){//The value of o will be correctly changed for later use.o.setWhatever(value);

//P will be a completely different object than what you stored,//so you won't be able to reference it outside this method.p = newObject();}

Any Object in Java is really just a pointer to an Object of that type. So if you have an Integer, it's a pointer to a wrapper class that contains an int. When you call new again, you're basically reassigning the pointer, and your old object gets removed by the garbage collector.

Thanks Riven and Demon. OK, so after looking through the OpenGL spec, I guess I am OK initializing integers for use as Program and Shader IDs to 0 since zero is reserved and will never be issued as an ID from the GL. So, I guess, the whole question was wrong! lol. Oh well, I am glad for the refresher from both of you. That's one of the funny things about JOGL is that you are thinking part C, part Java.

would be better, but normally in java you would design this more OO like, e.g. with a dedicated Shader class:

I was considering doing this. I saw that there are some convenience classes in JOGL2 aimed at GLSL, similar to those we currently have for textures. Is that going to be a while before release ( couldn't find a release date )? If so, I may just get cracking on that for my project.

Maybe nice to clearify it a bit, for those that are puzzled by what 'passed by value' actually means.

Every argument that is passed to a method is copied.

For primitives, this is obvious: if you pass int '5', '5' is copied to another memory location, which can be read from within the invoked method.

For references, it's a bit less obvious: there is a copy, but the reference (memory location) is copied. Like:Object a = new Object();Object b = a; // copy of a referencea = null; // b is still refering to whatever a *was* refering to

If you do want to copy an Object, you can call clone() on any Object, although it's not always implemented. clone() is a protected method, so access is restricted to classes in the same package as Object (none of yours will be), but any subclasses that implement the Cloneable interface will have overridden clone() and made it public. Anything that makes sense to be copied typically can be.

1 2 3 4 5 6 7 8 9

//a points to an Object in memory that is an Integer with a value of 5.Integera = newInteger(5);

//b points to the same Object that a does, so its value is 5 also.//If you modified b (forgetting that Integer is immutable for the moment), you would also change a.Integerb = a;

//c points to a different Object than a and b, also an Integer with value 5.//Note that you need to tyepcast because clone() returns an Object.

Although Integer isn't the best example because it doesn't implement Cloneable. I was surprised too, but I suppose it sort-of makes sense because Integer is unmodifiable and so there's no need to clone it.

No pointers for you in java. 99% of the times you use pointers (for multiple return values) you can refactor to use single functions. The other .9% percent is when you should use a domain object to hold obviously related values. (except if you're lazy, like i am).

The .1% is for performance intensive code, where you're mostly f**ked unless you do ugly things like reusing a array parameter or globals or something.

Although Integer isn't the best example because it doesn't implement Cloneable. I was surprised too, but I suppose it sort-of makes sense because Integer is unmodifiable and so there's no need to clone it.

Huh, that is surprising, I should have looked it up first. I kept looking through the API just now looking for things that were Cloneable but couldn't really find any. Oh well, he gets the idea...

Yeah, I've used it with List's as well, but in the end that's the same basic idea. I actually didn't know you could clone an array.

The really cool bit is that since 1.5 introduced covariant return types they've been applied to most (all?) Cloneables in the standard libraries, including arrays, so Riven's example works even though it has no cast.

The really cool bit is that since 1.5 introduced covariant return types they've been applied to most (all?) Cloneables in the standard libraries, including arrays, so Riven's example works even though it has no cast.

That's cool. They're slowly getting out of having to typecast everything all the time territory. Those were the (1.4) days... I would have statements with like 6 parentheses next to each other.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org