java inner class, for the sole use of parameter passing

Not sure I fully follow your requirement for doing this, since any method called from within a class (if that is what you mean) should likely be a good candidate for the use of a varargs invocation.

Variadic methods don't jibe with the stated requirement for strong types.

Yeah like CPColin said just make the class static and it'll do exactly what you want.

Doug

You know when you need to call a function and you need to pass a load of parameters to it

Declare the inner class static and you should be able to instantiate it without an instance of the enclosing class.

Yeah like CPColin said just make the class static and it'll do exactly what you want.

If you're calling a method,  unless it's static, you must already have an instance, so why would you need a 'transporter class' to be static itself?

If you're calling a method,  unless it's static, you must already have an instance, so why would you need a 'transporter class' to be static itself?

2 cases I can think of - if the method being called is static itself or if it's the constructor.

But I think we're mostly splitting hairs on this one :)

Doug

Let's leave aside constructors for the moment. thready - are the methods in question static?

@thready - If you could give us the actual use case you have in mind in this question, I reckon it would be helpful and maybe even enlightening.

need to call a function and you need to pass a load of parameters to it

I think this is where the crux of the issue is. You realise the benefit of creating a class to pass these parameters but you say that you don't need to use this anywhere else.

I think that it is highly unlikely that ALL of these "loads" of parameters are unrelated to any other parameter in the list. Therefore, I think if you thought more about it, you would see relationships and common themes between some/all of these parameters that you could come up with a useful class hierarchy to represent them. And then, this hierarchy (or a good part of it) would be useful to other areas of your app, and therefore you would have these classes as top-level classes for use throughout.


Also, back to one of your original points about using the class outside to parent, might be an obvious one but make sure the inner class is declared "public" (this is in addition to being declared static)

If I make the parent class static, then only one thread in the application can ever use this class.

Whereas, an instance if a non static class can still instantiate its own version of parameters in inner classes.

And these are rest API parameters, so it's kind of a nice way to keep simple data structures out of the way and preventing thinking about unnecessary complicated relationships...

If I make the parent class static, then only one thread in the application can ever use this class.

Not sure what you mean there: there's no meaningful connection between the static modifier and threads

As others have said, it would be helpful for you to post example code. At the moment i can't see much happening other than the perceived problem being moved elsewhere by the kind of strategy envisaged.

@mccarl

Also, back to one of your original points about using the class outside to parent, might be an obvious one but make sure the inner class is declared "public" (this is in addition to being declared static)

Why is that? Why can't it be declared 'private' for example?

thready - I still don't get where you are going with this . . . how can the list of params be 'growing' all the time? Don't you mean more like the size(s) of whatever objects (arrays) you are passing is growing? If the number of params/args is growing, then, as mccarl alludes to, there is a different approach lurking under the surface most likely.

Seems to me you are unsuitably applying the use of 'static'. Static isn't going to help you avoid defining the 'growing' args list - or is it?

thready: you didn't answer my question above btw:

thready - are the methods in question static?

And these are rest API parameters

The above suggests that the answer is probably that they're not static.

In any case, if your objective is to allow a varying number (with the tendency of that to increase) of parameters to be passed into a REST call then your best bet would be to use something like a Call object (per SOAP) or ClientConfig (per Jersey REST API)

Hi folks, thank you very much for your input here.  Static is not so important to me here.  I'm writing a helper class for our rest API.  The parameters are growing only in the sense that we might have more parameters added to a rest call later, example, to post data. I was thinking of creating one big class called restAPIParams and have a slew of inner classes, one for each call. I wanted them here to keep them as "dumb parameters"- where the only smarts built into them I'd for the rest call use only.  I wanted to prevent people from reading these classes like models for any other use...

@krakatoa,

Why is that? Why can't it be declared 'private' for example?

Well, in the author's original question they are referring to being to instantiate an object of the class from outside the parent class. If it were private, it definitely wouldn't be visible from outside the parent class.

I was thinking of creating one big class called restAPIParams

See my answer above

Good, so you can understand my point now!? :)

Well, in the author's original question . . . .

You could of course leave off the access qualifier completely.

Thanks everyone - I used the public static inner class in the end.  Nice to know when you instantiate this - you get a new instance every time...  It allows the "growing parameter list" by adding other parameters to the inner class without changing the signature...