Asked  6 Months ago    Answers:  5   Viewed   34 times

I'd like to be able to create a function like:

class A {
  private String extraVar;
  public String myFormat(String format, Object ... args){
    return String.format(format, extraVar, args);

The problem here is that args is treated as Object[] in the method myFormat, and thus is a single argument to String.format, while I'd like every single Object in args to be passed as a new argument. Since String.format is also a method with variable arguments, this should be possible.

If this is not possible, is there a method like String.format(String format, Object[] args)? In that case I could prepend extraVar to args using a new array and pass it to that method.



The underlying type of a variadic method function(Object... args) is function(Object[] args). Sun added varargs in this manner to preserve backwards compatibility.

So you should just be able to prepend extraVar to args and call String.format(format, args).

Tuesday, June 1, 2021
answered 6 Months ago

After digging a bit I quickly found out there are basically two options:

Option 1

You pass a "wrapper object" containing all the other parameters to the service. You might need to annotate this wrapper class with JAXB annotations like @XmlRootElement in order for this to work with the Jettison based provider, but if you use Jackson in stead there is no need. Just set the content type to the right type and the right message body reader will be invoked. This will only work for POST type services of course (AFAIK).


This is just an example of turning the service mentioned in the original question into one using a wrapper object.

class RestService {

    public Result fooBar(

          * Using "" will inject all form params directly into a ParamsWrapper 
          * @see
          @FormParam("") FooBarParamsWrapper wrapper

        ) throws WebServiceException {

class ParamsWrapper {
  double foo, bar;
  MyComplexObject object;

Option 2

You can provide some special string format that you pack your objects into and then implement either a constructor taking a string, a static valueOf(String s) or a static fromString(String s) in the class that will take this string and create an object from it. Or quite similar, create a ParameterHandler that does exactly the same.

AFAIK, only the second version will allow you to call your services from a browser using JSONP (since JSONP is a trick restricted to GET). I chose this route to be able to pass arrays of complex objects in the URI.

As an example of how this works, take the following domain class and service


public void myService(@QueryParam("a") MyClass [] myVals) {
    //do something

class MyClass {
    public int foo;
    public int bar;

   /** Deserializes an Object of class MyClass from its JSON representation */
   public static MyClass fromString(String jsonRepresentation) {
           ObjectMapper mapper = new ObjectMapper(); //Jackson's JSON marshaller
           MyClass o= null;
           try {
                   o = mapper.readValue(jsonRepresentation, MyClass.class );
           } catch (IOException e) {
                    throw new WebApplicationException()
           return o;

A URI{"foo":1, "bar":2}&a={"foo":100, "bar":200} would in this case be deserialized into an array composed of two MyClass objects.

2019 comment: Seeing that this answer still gets some hits in 2019, I feel I should comment. In hindsight, I would not recomment option 2, as going through these steps just to be able to be able to do GET calls adds complexity that's probably not worth it. If your service takes such complex input, you will probably not be able to utilize client side caching anyway, due to the number of permutations of your input. I'd just go for configuring proper Cross-Origin-Sharing (CORS) headers on the server and POST the input. Then focus on caching whatever you can on the server.

Tuesday, July 27, 2021
answered 4 Months ago

There's no standard way to construct or manipulate va_args arguments, or even pass them to another function (Standard way to manipulate variadic arguments?, C Programming: Forward variable argument list). You'd be better off seeing if you can access the internal routines of LogEvent.

Sunday, August 15, 2021
answered 4 Months ago

None of the answers I've seen on this question seem to me to be satisfactory so I thought I'd take a stab at it.

Here's the way I see it:

  1. @SafeVarargs
  • Suppresses the warning: [unchecked] Possible heap pollution from parameterized vararg type Foo.
  • Is part of the method's contract, hence why the annotation has runtime retention.
  • Is a promise to the caller of the method that the method will not mess up the heap using the generic varargs argument.
  1. @SuppressWarnings("varargs")
  • Suppresses the warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter bar.
  • Is a cure for problems occurring within the method code, not on the method's contract, hence why the annotation only has source code retention.
  • Tells the compiler that it doesn't need to worry about a callee method called by the method code messing up the heap using the array resulting from the non-reifiable varargs parameter.

So if I take the following simple variation on OP's original code:

class Foo {
    static <T> void bar(final T... barArgs) {
    static <T> void baz(final T[] bazArgs) { }

The output of $ javac -Xlint:all using the Java 9.0.1 compiler is: warning: [unchecked] Possible heap pollution from parameterized vararg type T
    static <T> void bar(final T... barArgs) {
  where T is a type-variable:
    T extends Object declared in method <T>bar(T...)
1 warning

I can make that warning go away by tagging bar() as @SafeVarargs. This both makes the warning go away and, by adding varargs safety to the method contract, makes sure that anyone who calls bar will not have to suppress any varargs warnings.

However, it also makes the Java compiler look more carefully at the method code itself - I guess in order to verify the easy cases where bar() might be violating the contract I just made with @SafeVarargs. And it sees that bar() invokes baz() passing in barArgs and figures since baz() takes an Object[] due to type erasure, baz() could mess up the heap, thus causing bar() to do it transitively.

So I need to also add @SuppressWarnings("varargs") to bar() to make that warning about bar()'s code go away.

Sunday, August 22, 2021
answered 4 Months ago

One approach is to include


which supplies importClass.

On the other hand, you can use,, ... directly without importing.

var File =;
var FileReader =;

This is backward compatible with Rhino.

Monday, September 6, 2021
Razvan N
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :