Don't try to represent sets in JSON. Do it when parsing the data instead.

Your JSON data should have a schema which specifies which fields should be treated as a set, or you may have a metadata embedded in the JSON data itself that describes when a list should be treated as a set (e.g. {"houses": {"_type": "set", "value": [...]}}) or with a naming convention.

Note that according to JSON standard, a JSON object can have duplicate keys. ECMA-404 wordings:

Objects

[...] The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.

AFAICD, nothing in the spec forbids non unique names, and there are many JSON parser implementations that can parse non unique object names. RFC 7159 discourages non unique names for interoperability, but specifically don't forbid it either, and goes on to list how various parsers have been seen handling non unique object names.

And ECMA 404 also doesn't require that array ordering be preserved:

Arrays

The JSON syntax does not define any specific meaning to the ordering of the values. However, the JSON array structure is often used in situations where there is some semantics to the ordering.

This wording allows applications to use arrays to represent sets if they so choose.

when u convert a array of strings to list and then the list to a Set, it is no longer String, but an array of objects hence new HashSet<>(Arrays.asList("a", "b"))); gives "set":[b, a] (without quotes). And parser.parse(jsonString); works on Object not array of Objects.

Try using a list instead of a set as below :

json.put("set", new Arraylist<>(new HashSet<>(Arrays.asList("a", "b"))));

I really suggest to keep this implementation nearly as it is. It is clear and direct.

Maybe you decompose the method into two methods.

Maybe you reduce scope of one variable (tempj).

Maybe you rename some artefacts.

public String toJSONString(Set<Locale> languageSet) throws Exception {

    JSONObject root = new JSONObject();

    try {

        JSONArray localeAsJSONObjectArray = new JSONArray();

        for (Locale locale : languageSet) {
            if (locale != null) {
                localeAsJSONObjectArray.put(toJSONObject(locale));
            }
        }

        root.put("root", localeAsJSONObjectArray);

    } catch (JSONException e) {
        //
    }

    return root.toString();
}

private JSONObject toJSONObject(Locale locale) {
    JSONObject localeAsJSONObject = new JSONObject();
    localeAsJSONObject.put("lcode", locale.toLanguageTag());
    localeAsJSONObject.put("ldisplay", locale.getDisplayName());
    return localeAsJSONObject;
}

Anything else will distort the intention. Introducing lambdas here will make me think that you want to make the algorithm fit to lambda as the direction should be vice versa: The used control structures should follow your algorithm.

You have to keep one thing in mind:

Lambdas and streams really make sense if you use ".parallelStream()" instead of ".stream()". Then your code will act in some parallel way with the Fork-Join-Thread-Pool and your code speeds up. Anything else is Old wine in new bottles. Occasionally lambdas seem to be more expressive. In other situations you will break your leg if you want to fit you algorithm to lambda and you loose expressiveness.

But to use ".parallelStream()" your code has to meet some not obvious requirements that is clear to those who already work with parallelism. Most of the time you are not able to simply change ".stream()" to ".prallelStream()". So most of the time you will not benefit from the new API.

If you still want to use lambdas I provide you an example that is surely not strcutral optimizied but that shows the elements to consider if you really want to benefit from parallelism.

public static String toJSONString(Set<Locale> languageSet) {

    JSONObject root = new JSONObject();

    JSONArray localeAsJSONObjectArray = new JSONArray();

    // synchronization, as putting may occur asynchronously. JSONArray itself is NOT synchronized. 

    Consumer<JSONObject> synchronizedJSONObjectAdder = jsonObject -> {

        synchronized (localeAsJSONObjectArray) {
            localeAsJSONObjectArray.put(jsonObject);
        }

    };

    // function that defines the transformation from a locale to a JSONObject.
    // no synchronization needed as every result only depends on the function parameter.

    Function<Locale, JSONObject> localeToJSONObjectFunction = locale -> {
        JSONObject localeAsJSONObject = new JSONObject();
        localeAsJSONObject.put("lcode", locale.toLanguageTag());
        localeAsJSONObject.put("ldisplay", locale.getDisplayName());

        // for debugging in which thread the transformation will be processed.

        System.out.println(Thread.currentThread().getName());

        return localeAsJSONObject;
    };

    // using parallel stream to address parallelism
    languageSet.parallelStream().filter(locale -> locale != null).map(localeToJSONObjectFunction).forEach(synchronizedJSONObjectAdder);

    root.put("root", localeAsJSONObjectArray);

    return root.toString();
}


public static void main(String[] args) throws Exception {
    toJSONString(new HashSet<>(Arrays.asList(Locale.getAvailableLocales())));
}

Jackson is a popular framework for converting between JSON and Java POJOs.