Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23473 > unrolled thread

exec problem is JDK 1.7.0_21

Back to article view | Back to comp.lang.java.programmer

Contents

  exec problem is JDK 1.7.0_21 Roedy Green <see_website@mindprod.com.invalid> - 2013-04-16 15:48 -0700
    Re: exec problem is JDK 1.7.0_21 Lew <lewbloch@gmail.com> - 2013-04-16 16:48 -0700
    Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-20 13:00 +0300
    Re: exec problem is JDK 1.7.0_21 Joerg Meier <joergmmeier@arcor.de> - 2013-04-20 15:13 +0200
      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-20 19:07 +0300
        Re: exec problem is JDK 1.7.0_21 markspace <markspace@nospam.nospam> - 2013-04-20 09:24 -0700
          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-20 19:34 +0300
            Re: exec problem is JDK 1.7.0_21 markspace <markspace@nospam.nospam> - 2013-04-20 11:01 -0700
              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 00:25 +0300
            Re: exec problem is JDK 1.7.0_21 Joerg Meier <joergmmeier@arcor.de> - 2013-04-20 22:03 +0200
              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 00:29 +0300
                Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-20 21:56 +0000
                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 08:31 +0300
                    Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 11:08 +0000
                      Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-21 13:43 -0300
                      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:12 +0300
                        Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 21:17 +0000
                        Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:49 -0400
                Re: exec problem is JDK 1.7.0_21 Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-20 15:03 -0700
                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 08:26 +0300
                    Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-21 14:30 +0100
                      Re: exec problem is JDK 1.7.0_21 Knute Johnson <nospam@knutejohnson.com> - 2013-04-21 09:20 -0700
                        Re: exec problem is JDK 1.7.0_21 markspace <markspace@nospam.nospam> - 2013-04-21 11:31 -0700
                          Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-21 16:06 -0300
                            Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 19:47 +0000
                              Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 23:01 +0000
                        Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:29 +0300
                          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:45 +0300
                          Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-21 21:38 +0000
                          Re: exec problem is JDK 1.7.0_21 Knute Johnson <nospam@knutejohnson.com> - 2013-04-21 18:49 -0700
                            Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-22 09:36 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-22 10:39 +0100
                                Re: exec problem is JDK 1.7.0_21 Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-22 07:43 -0700
                                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-22 19:33 +0300
                                    Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 07:30 +0100
                            Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-22 21:07 +0000
                              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-23 23:28 +0300
                                Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-23 21:05 +0000
                                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 11:22 +0300
                                    Re: exec problem is JDK 1.7.0_21 Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-24 20:22 +0000
                                  Re: exec problem is JDK 1.7.0_21 Nigel Wade <nmw@ion.le.ac.uk> - 2013-04-24 11:24 +0100
                      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 23:23 +0300
              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-21 00:40 +0300
                Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 10:48 +0100
                  Re: exec problem is JDK 1.7.0_21 Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-04-23 13:31 +0300
                    <? extends String> (was: exec problem is JDK 1.7.0_21) Steven Simpson <ss@domain.invalid> - 2013-04-23 14:55 +0100
                      Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-23 16:37 +0100
                        Re: <? extends String> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-23 08:50 -0700
                          Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-23 17:30 +0100
                            Re: <? extends String> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-23 09:58 -0700
                              Re: <? extends String> Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-04-23 21:06 +0300
                              Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-23 19:33 +0100
                                Re: <? extends String> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-23 12:26 -0700
                                  Re: <? extends String> lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-24 09:08 +0100
                          Re: <? extends String> Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-23 16:28 -0300
                      Re: <? extends String> (was: exec problem is JDK 1.7.0_21) Lew <lewbloch@gmail.com> - 2013-04-23 14:12 -0700
                        Re: <? extends String> Steven Simpson <ss@domain.invalid> - 2013-04-23 23:22 +0100
                  Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 19:56 +0100
                    Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-23 23:31 +0300
                      Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-23 23:39 +0100
                        Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 09:29 +0300
                          Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-24 10:26 +0100
                            Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 13:11 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-24 22:24 +0100
                                Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-25 11:49 +0300
                                  Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-25 10:19 +0100
                            Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-25 09:02 +0100
                              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-25 11:47 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-25 09:50 +0100
                                Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-25 10:07 +0100
                                  Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-27 08:44 +0100
                            Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-26 20:17 +0300
                              Re: exec problem is JDK 1.7.0_21 Steven Simpson <ss@domain.invalid> - 2013-04-27 09:22 +0100
                                Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-27 12:39 +0300
                  Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-23 23:17 +0300
                    Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-23 17:32 -0300
                      Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-24 10:39 +0300
                        Re: exec problem is JDK 1.7.0_21 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-25 09:02 +0100
                          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-25 11:59 +0300
                            Re: exec problem is JDK 1.7.0_21 Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-25 18:38 -0300
                              Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-28 10:57 +0300
                        Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:35 -0400
                          Re: exec problem is JDK 1.7.0_21 Sven Köhler <remove-sven.koehler@gmail.com> - 2013-04-28 09:23 +0300
                            Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-28 09:52 -0400
    Re: exec problem is JDK 1.7.0_21 Stanimir Stamenkov <s7an10@netscape.net> - 2013-04-20 17:52 +0300
      Re: exec problem is JDK 1.7.0_21 Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:31 -0400

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#23620

On 23/04/13 22:05, Martin Gregorie wrote:
> On Tue, 23 Apr 2013 23:28:35 +0300, Sven Köhler wrote:
>
>> Am 23.04.2013 00:07, schrieb Martin Gregorie:
>>> My testprog works exactly the same when run from within my
>>> TestProcessBuilder test class as it does when run stand-alone from the
>>> command line:
>>>
>>> $ java TestProcessBuilder testprog "hello world" "\"hello world\""
>>> "\"hello\" \"world\"" "hello ""double quoted"" world"
>>> argc=5 argv[0]=testprog argv[1]=hello world argv[2]="hello world"
>>> argv[3]="hello" "world"
>>
>> Please look at the results that Steven posted. If the String "hello\"
>> \"world" is passed to the ProcessBuilder, the result was:
>>    argv[1]=[hello] argv[2]=[world]
>>
> Actually, on Linux almost all the messing about with strings is done by
> the shell that invokes the the command if the strings are enclosed in
> double quotes.

Only if the command invokes a shell, otherwise there is no shell involved.

The shell is just another executable.

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#23557

Am 21.04.2013 16:30, schrieb Chris Uppal:
> Or, to put it another way: the only way to find out what works is to experiment
> (it probably depends on the application you're launching as well as the OS and
> Java platform).  A right pain in the bum...

So I experimented. I found, that using a list of arguments works just
fine, unless these arguments contain quotes, spaces, or the empty string
is one of the arguments. I found, that ProcessBuilder (as well as
Runtime.exec) do a VERY BAD job at converting the argument array to
something, that CommandLineToArgv would tokenize back into something
close to what the argument array was.

At the same time, ProcessBuilder doesn't give me full control over the
command line parameter string. Instead, it sometimes adds quotes - but
not in all cases that would require them. Also any of that is
undocumented, such that any workaround I implement may or may not break
in the future.

Also, some here think that documentation as vague as "on some operating
systems, something MIGHT be required" would actually contain a concrete
statement about how to use ProcessBuilder on Windows. (Claiming, that
this statement does not apply to Windows is just as bad as the opposite.)


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#23541

Am 20.04.2013 23:03, schrieb Joerg Meier:
> ProcessBuilder acts exactly the way Windows needs it to:

Oh, and of course the ProcessBuilder doesn't behave as it is supposed
to. As mentioned in my first post, the String "\"a b\"" would be passed
unmodified to the program invoked. However, clearly, the string passed
to the program should have been
"\"\\\"a b\\\"\""

Only with the quotes and backslashes added, CommandLineToArgv would
decode it to "\"a b\"". With the current ProcessBuilder implementation,
a Windows program will see the parameter "a b" while on UNIX the program
will see "\"a b\"".

See
http://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx
for details.

Note, that I assume that the program invoked uses CommandLineToArgv to
decode the command line. Which is by no means clear, as any program can
implement their own tokenizer.

Don't you find that a bit strange?


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#23582

On 20/04/13 22:40, Sven Köhler wrote:
> Oh, and of course the ProcessBuilder doesn't behave as it is supposed
> to. As mentioned in my first post, the String "\"a b\"" would be passed
> unmodified to the program invoked. However, clearly, the string passed
> to the program should have been
> "\"\\\"a b\\\"\""
>
> Only with the quotes and backslashes added, CommandLineToArgv would
> decode it to "\"a b\"". With the current ProcessBuilder implementation,
> a Windows program will see the parameter "a b" while on UNIX the program
> will see "\"a b\"".
>
> See
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx
> for details.

You're expecting Java to build its Windows command string something like 
this?:

import java.util.*;
import java.util.regex.*;

public final class WindowsArgumentGenerator {
     private WindowsArgumentGenerator() { }

     private static final Pattern slashSequence =
         Pattern.compile("\\\\*\"");

     private static boolean needsQuotes(String arg) {
         return arg.indexOf(' ') > -1;
     }

     public static String generateWindowsArgument(List<? extends String> args) {
         StringBuilder out = new StringBuilder();
         String sep = "";

         for (String arg : args) {
             out.append(sep);
             sep = " ";

             final boolean quoted = needsQuotes(arg);

             if (quoted)
                 out.append('"');

             Matcher m = slashSequence.matcher(arg);
             int lastEnd = 0;
             while (m.find()) {
                 out.append(arg.substring(lastEnd, m.start()));
                 final String slashes = m.group();
                 final int len = slashes.length() - 1;
                 out.append(slashes.substring(0, len))
                     .append('\\')
                     .append(slashes);
                 lastEnd = m.end();
             }
             out.append(arg.substring(lastEnd));

             if (quoted)
                 out.append('"');
         }

         return out.toString();
     }

     public static void main(String[] args) throws Exception {
         for (int i = 0; i < args.length; i++)
             System.out.printf("argv[%d]=[%s]%n", i, args[i]);
         System.out.println(generateWindowsArgument(Arrays.asList(args)));
     }
}

Does that work correctly for anything to be thrown at CommandLineToArgvW?


> Note, that I assume that the program invoked uses CommandLineToArgv to
> decode the command line. Which is by no means clear, as any program can
> implement their own tokenizer.
>
> Don't you find that a bit strange?

Perhaps that assumption is too risky for Java to make, e.g. there are 
enough 'native' Windows/DOS commands around that the programmer is 
likely to want to invoke, but don't use CommandLineToArgvW, and so would 
be confused if they received a string escaped as above. Not a very 
satisfactory situation.


-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#23583

23.04.2013 12:48, Steven Simpson kirjoitti:
> public static String generateWindowsArgument(List<? extends String> args) {

<offtopic>java.lang.String is final, so nothing can extend it. </offtopic>

-- 

He hath eaten me out of house and home.
		-- William Shakespeare, "Henry IV"

[toc] | [prev] | [next] | [standalone]

#23585 — <? extends String> (was: exec problem is JDK 1.7.0_21)

On 23/04/13 11:31, Donkey Hottie wrote:
> 23.04.2013 12:48, Steven Simpson kirjoitti:
>> public static String generateWindowsArgument(List<? extends String> args) {
> <offtopic>java.lang.String is final, so nothing can extend it. </offtopic>

It's a matter of habit drawn from the general principle that if I don't 
need to modify the list, I don't impose the additional, unnecessary 
constraint on the caller, regardless of the element type.

Also, just because a class is final now, it might not be in the future.  
It's harder to make an already published class final than to make a 
final one non-final, because a currently final class won't have any 
derivations that could be affected by its change of finality.  
<potentially-dodgy-generalization>Finality is not final; non-finality 
is.</potentially-dodgy-generalization> That said, it's not likely to 
happen to String, and maybe there would be other consequences that keep 
it unlikely.  Nevertheless, my code will remain neutral on this matter, 
whatever happens.

Furthermore, the class could be re-factored to use (say) CharSequence.  
By sticking to the principle that is correct whether String or 
CharSequence is used, I worry less about the specifics of the type in 
use as I make the change.

import java.util.*;
import java.util.regex.*;

public final class WindowsArgumentGenerator {
     private WindowsArgumentGenerator() { }

     private static final Pattern slashSequence =
         Pattern.compile("\\\\*\"");

     private static final Pattern spaces = Pattern.compile(" ");

     private static boolean needsQuotes(CharSequence arg) {
         return spaces.matcher(arg).find();
     }

     public static String
         generateWindowsArgument(List<? extends CharSequence> args) {
         StringBuilder out = new StringBuilder();
         String sep = "";

         for (CharSequence arg : args) {
             out.append(sep);
             sep = " ";

             final boolean quoted = needsQuotes(arg);

             if (quoted)
                 out.append('"');

             Matcher m = slashSequence.matcher(arg);
             int lastEnd = 0;
             while (m.find()) {
                 out.append(arg.subSequence(lastEnd, m.start()));
                 final String slashes = m.group();
                 final int len = slashes.length() - 1;
                 out.append(slashes.substring(0, len))
                     .append('\\')
                     .append(slashes);
                 lastEnd = m.end();
             }
             out.append(arg.subSequence(lastEnd, arg.length()));

             if (quoted)
                 out.append('"');
         }

         return out.toString();
     }

     public static void main(String[] args) throws Exception {
         for (int i = 0; i < args.length; i++)
             System.out.printf("argv[%d]=[%s]%n", i, args[i]);
         System.out.println(generateWindowsArgument(Arrays.asList(args)));
     }
}

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#23587 — Re: <? extends String>

On 23/04/13 14:55, Steven Simpson wrote:
> On 23/04/13 11:31, Donkey Hottie wrote:
>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>> public static String generateWindowsArgument(List<? extends String>
>>> args) {
>> <offtopic>java.lang.String is final, so nothing can extend it.
>> </offtopic>
>
> It's a matter of habit drawn from the general principle that if I don't
> need to modify the list, I don't impose the additional, unnecessary
> constraint on the caller, regardless of the element type.

I don't understand this. In the first place List<? extends String>  says 
nothing about your ability to modify the list, you can add and remove 
Strings to your hearts content, secondly the only type you can pass as 
argument to generateWindowsArgument is List<String> so the construct is 
redundant anyway In fact, given that >>extends String<< is effectively 
meaningless I'm surprised the compiler doesn't at least issue a warning. 
I suppose you get away with it because compile time type erasure gets 
rid of any type arguments and as there can be only one type of argument 
anyway a warning would be superfluous.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#23588 — Re: <? extends String>

On 4/23/13 8:37 AM, lipska the kat wrote:
> On 23/04/13 14:55, Steven Simpson wrote:
>> On 23/04/13 11:31, Donkey Hottie wrote:
>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>> public static String generateWindowsArgument(List<? extends String>
>>>> args) {
>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>> </offtopic>
>>
>> It's a matter of habit drawn from the general principle that if I don't
>> need to modify the list, I don't impose the additional, unnecessary
>> constraint on the caller, regardless of the element type.
>
> I don't understand this. In the first place List<? extends String>  says
> nothing about your ability to modify the list, you can add and remove
> Strings to your hearts content,
Wrong.

List<? extends String> listOfStuff = new ArrayList<String>();

listOfStuff.add("foo"); // compiler error here!

> secondly the only type you can pass as
> argument to generateWindowsArgument is List<String> so the construct is
> redundant anyway In fact, given that >>extends String<< is effectively
> meaningless I'm surprised the compiler doesn't at least issue a warning.
In general, it is only meaningless in that String cannot be extended in 
the current implementation of String. As Steven pointed out, that may 
not be the case for future implementations, and the compiler will never 
know that.
> I suppose you get away with it because compile time type erasure gets
> rid of any type arguments and as there can be only one type of argument
> anyway a warning would be superfluous.
Erasure is a runtime phenomenon, don't get it confused with compile-time 
static type safety.  the <? extends String> is an edge case that makes 
less sense, but if you treat it like you'd treat any other construct, 
which does no harm BTW, then you simplify your reasoning for the general 
case.

[toc] | [prev] | [next] | [standalone]

#23589 — Re: <? extends String>

On 23/04/13 16:50, Daniel Pitts wrote:
> On 4/23/13 8:37 AM, lipska the kat wrote:
>> On 23/04/13 14:55, Steven Simpson wrote:
>>> On 23/04/13 11:31, Donkey Hottie wrote:
>>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>>> public static String generateWindowsArgument(List<? extends String>
>>>>> args) {
>>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>>> </offtopic>
>>>
>>> It's a matter of habit drawn from the general principle that if I don't
>>> need to modify the list, I don't impose the additional, unnecessary
>>> constraint on the caller, regardless of the element type.
>>
>> I don't understand this. In the first place List<? extends String>  says
>> nothing about your ability to modify the list, you can add and remove
>> Strings to your hearts content,
> Wrong.
>
> List<? extends String> listOfStuff = new ArrayList<String>();
>
> listOfStuff.add("foo"); // compiler error here!

erk, you're right, well I never, however it doesn't say anything about 
the list outside of the method, how therefor does it avoid 'impose[ing] 
the additional, unnecessary constraint on the caller' what constraint 
does it avoid ?

>> secondly the only type you can pass as
>> argument to generateWindowsArgument is List<String> so the construct is
>> redundant anyway In fact, given that >>extends String<< is effectively
>> meaningless I'm surprised the compiler doesn't at least issue a warning.
> In general, it is only meaningless in that String cannot be extended in
> the current implementation of String. As Steven pointed out, that may
> not be the case for future implementations, and the compiler will never
> know that.

Well I reckon there's more chance of finding Elvis serving me with my 
weekly fish and chips but OK, I suppose there's a rempote possibility it 
might happen one day.

>> I suppose you get away with it because compile time type erasure gets
>> rid of any type arguments and as there can be only one type of argument
>> anyway a warning would be superfluous.
> Erasure is a runtime phenomenon,

Erasure happens at compile time, generics are all about compile time 
type checking, erasure removes type arguments at compile time after type 
checking has occurred, the runtime system doesn't know anything about 
type erasure or generics

http://docs.oracle.com/javase/tutorial/java/generics/erasure.html

[snip]

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#23590 — Re: <? extends String>

On 4/23/13 9:30 AM, lipska the kat wrote:
> On 23/04/13 16:50, Daniel Pitts wrote:
>> On 4/23/13 8:37 AM, lipska the kat wrote:
>>> On 23/04/13 14:55, Steven Simpson wrote:
>>>> On 23/04/13 11:31, Donkey Hottie wrote:
>>>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>>>> public static String generateWindowsArgument(List<? extends String>
>>>>>> args) {
>>>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>>>> </offtopic>
>>>>
>>>> It's a matter of habit drawn from the general principle that if I don't
>>>> need to modify the list, I don't impose the additional, unnecessary
>>>> constraint on the caller, regardless of the element type.
>>>
>>> I don't understand this. In the first place List<? extends String>  says
>>> nothing about your ability to modify the list, you can add and remove
>>> Strings to your hearts content,
>> Wrong.
>>
>> List<? extends String> listOfStuff = new ArrayList<String>();
>>
>> listOfStuff.add("foo"); // compiler error here!
>
> erk, you're right, well I never, however it doesn't say anything about
> the list outside of the method, how therefor does it avoid 'impose[ing]
> the additional, unnecessary constraint on the caller' what constraint
> does it avoid ?
In *this* case none.  In the General case.

List<? extends MyFoo> fooList1;
List<MyFoo> fooList2;

fooList1 can be assigned an instance of List<MyFoo>, or List<MySubFoo>.
fooList2 can *only* be be assigned an instance of List<MyFoo>, not 
List<MySubFoo>.  This is an unnecessary constraint on the caller.

Again, in the case of "String", there isn't a difference. but that is a 
special edge case which needn't change the general behavior.

>
>>> secondly the only type you can pass as
>>> argument to generateWindowsArgument is List<String> so the construct is
>>> redundant anyway In fact, given that >>extends String<< is effectively
>>> meaningless I'm surprised the compiler doesn't at least issue a warning.
>> In general, it is only meaningless in that String cannot be extended in
>> the current implementation of String. As Steven pointed out, that may
>> not be the case for future implementations, and the compiler will never
>> know that.
>
> Well I reckon there's more chance of finding Elvis serving me with my
> weekly fish and chips but OK, I suppose there's a rempote possibility it
> might happen one day.
>
>>> I suppose you get away with it because compile time type erasure gets
>>> rid of any type arguments and as there can be only one type of argument
>>> anyway a warning would be superfluous.
>> Erasure is a runtime phenomenon,
>
> Erasure happens at compile time, generics are all about compile time
> type checking, erasure removes type arguments at compile time after type
> checking has occurred, the runtime system doesn't know anything about
> type erasure or generics
>
> http://docs.oracle.com/javase/tutorial/java/generics/erasure.html
>
> [snip]
>
> lipska
>

[toc] | [prev] | [next] | [standalone]

#23591 — Re: <? extends String>

23.04.2013 19:58, Daniel Pitts kirjoitti:
>>>> On 23/04/13 14:55, Steven Simpson wrote:
>>>>> On 23/04/13 11:31, Donkey Hottie wrote:
>>>>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>>>>> public static String generateWindowsArgument(List<? extends String>
>>>>>>> args) {
>>>>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>>>>> </offtopic>
>>>>>
>>>>> It's a matter of habit drawn from the general principle that if I
>>>>> don't
>>>>> need to modify the list, I don't impose the additional, unnecessary
>>>>> constraint on the caller, regardless of the element type.
>>>>
> 
> List<? extends MyFoo> fooList1;
> List<MyFoo> fooList2;
> 
> fooList1 can be assigned an instance of List<MyFoo>, or List<MySubFoo>.
> fooList2 can *only* be be assigned an instance of List<MyFoo>, not
> List<MySubFoo>.  This is an unnecessary constraint on the caller.
> 
> Again, in the case of "String", there isn't a difference. but that is a
> special edge case which needn't change the general behavior.

Thanks for the explanation and discussion. I'm a bit wiser now.

-- 

Today is the first day of the rest of the mess.

[toc] | [prev] | [next] | [standalone]

#23592 — Re: <? extends String>

On 23/04/13 17:58, Daniel Pitts wrote:
> On 4/23/13 9:30 AM, lipska the kat wrote:
>> On 23/04/13 16:50, Daniel Pitts wrote:
>>> On 4/23/13 8:37 AM, lipska the kat wrote:
>>>> On 23/04/13 14:55, Steven Simpson wrote:
>>>>> On 23/04/13 11:31, Donkey Hottie wrote:
>>>>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>>>>> public static String generateWindowsArgument(List<? extends String>
>>>>>>> args) {
>>>>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>>>>> </offtopic>
>>>>>
>>>>> It's a matter of habit drawn from the general principle that if I
>>>>> don't
>>>>> need to modify the list, I don't impose the additional, unnecessary
>>>>> constraint on the caller, regardless of the element type.
>>>>
>>>> I don't understand this. In the first place List<? extends String>
>>>> says
>>>> nothing about your ability to modify the list, you can add and remove
>>>> Strings to your hearts content,
>>> Wrong.
>>>
>>> List<? extends String> listOfStuff = new ArrayList<String>();
>>>
>>> listOfStuff.add("foo"); // compiler error here!
>>
>> erk, you're right, well I never, however it doesn't say anything about
>> the list outside of the method, how therefor does it avoid 'impose[ing]
>> the additional, unnecessary constraint on the caller' what constraint
>> does it avoid ?
> In *this* case none.

Actually, in a way, List<? extends String> as a parameter to a method 
might be considered as breaking encapsulation ... you are actually 
exposing part of the internal workings of a component.

>  In the General case.

Yes well this isn't the general case and I'm not convinced that writing
List<? extends String> as a parameter type because one day in the 
distant future String might be mutable is a reason to do it, it's nasty 
pointless and unnecessary complexity.

Just my opinion of course. :-)


lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#23595 — Re: <? extends String>

On 4/23/13 11:33 AM, lipska the kat wrote:
> On 23/04/13 17:58, Daniel Pitts wrote:
>> On 4/23/13 9:30 AM, lipska the kat wrote:
>>> On 23/04/13 16:50, Daniel Pitts wrote:
>>>> On 4/23/13 8:37 AM, lipska the kat wrote:
>>>>> On 23/04/13 14:55, Steven Simpson wrote:
>>>>>> On 23/04/13 11:31, Donkey Hottie wrote:
>>>>>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>>>>>> public static String generateWindowsArgument(List<? extends String>
>>>>>>>> args) {
>>>>>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>>>>>> </offtopic>
>>>>>>
>>>>>> It's a matter of habit drawn from the general principle that if I
>>>>>> don't
>>>>>> need to modify the list, I don't impose the additional, unnecessary
>>>>>> constraint on the caller, regardless of the element type.
>>>>>
>>>>> I don't understand this. In the first place List<? extends String>
>>>>> says
>>>>> nothing about your ability to modify the list, you can add and remove
>>>>> Strings to your hearts content,
>>>> Wrong.
>>>>
>>>> List<? extends String> listOfStuff = new ArrayList<String>();
>>>>
>>>> listOfStuff.add("foo"); // compiler error here!
>>>
>>> erk, you're right, well I never, however it doesn't say anything about
>>> the list outside of the method, how therefor does it avoid 'impose[ing]
>>> the additional, unnecessary constraint on the caller' what constraint
>>> does it avoid ?
>> In *this* case none.
>
> Actually, in a way, List<? extends String> as a parameter to a method
> might be considered as breaking encapsulation ... you are actually
> exposing part of the internal workings of a component.

What about the internal workings? That it accepts a List of things it 
can treat as Strings. I'm not seeing how that's breaking any encapsulation.

You're actually providing a guarantee that you won't be adding stuff to 
this List (since it is a compiler error to do so).
>
>>  In the General case.
>
> Yes well this isn't the general case and I'm not convinced that writing
> List<? extends String> as a parameter type because one day in the
> distant future String might be mutable is a reason to do it, it's nasty
> pointless and unnecessary complexity.
Sometimes if a general rule works for a special case, then it is easier 
to follow that rule than to "optimize" for that special case.

The general rule here is
"if you aren't writing to it, use <? extends T>"
>
> Just my opinion of course. :-)

Of course. Same goes for so much that is posted here by everyone.  Some 
are better opinions than others, but always on a case-by-case basis :-)

[toc] | [prev] | [next] | [standalone]

#23616 — Re: <? extends String>

On 23/04/13 20:26, Daniel Pitts wrote:
> On 4/23/13 11:33 AM, lipska the kat wrote:
>> On 23/04/13 17:58, Daniel Pitts wrote:
>>> On 4/23/13 9:30 AM, lipska the kat wrote:
>>>> On 23/04/13 16:50, Daniel Pitts wrote:
>>>>> On 4/23/13 8:37 AM, lipska the kat wrote:
>>>>>> On 23/04/13 14:55, Steven Simpson wrote:
>>>>>>> On 23/04/13 11:31, Donkey Hottie wrote:
>>>>>>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>>>>>>> public static String generateWindowsArgument(List<? extends
>>>>>>>>> String>
>>>>>>>>> args) {
>>>>>>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>>>>>>> </offtopic>

[snip]

>> Actually, in a way, List<? extends String> as a parameter to a method
>> might be considered as breaking encapsulation ... you are actually
>> exposing part of the internal workings of a component.
>
> What about the internal workings? That it accepts a List of things it
> can treat as Strings. I'm not seeing how that's breaking any encapsulation.

No, it is a bit of a leap I agree, allow me to elucidate.

Using List<? extends <final class>> as a parameter exposes the fact that 
the internal workings do not modify the list ... think about it, what 
additional information does it convey about the internal workings of the 
method ...

Tenuous maybe but no more tenuous that justifying the use of
List<? extends String> by saying that String may be made mutable in future.

You know what, this sort of thing makes me really quite angry. Years of 
looking at other peoples crappy code has left me with a pathological 
aversion to this type of pointless academic fluff. What is more worrying 
is that there is a good chance that this sort of nonsense is being 
propagated down the academic chain to tomorrows graduates. More 
pointless crappy code to analyze, what fun.

> You're actually providing a guarantee that you won't be adding stuff to
> this List (since it is a compiler error to do so).

Huh ... it is only a compiler error within the scope of the method so 
that point is irrelevant as far as a client is concerned.
If you want to inform clients that the list is not modified do it in the 
right place, in the documentation, not by some obscure twiddling with 
the syntax that relies on the user of the method understanding the 
obscurity.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#23596 — Re: <? extends String>

On 04/23/2013 12:50 PM, Daniel Pitts wrote:
> On 4/23/13 8:37 AM, lipska the kat wrote:
>> On 23/04/13 14:55, Steven Simpson wrote:
>>> On 23/04/13 11:31, Donkey Hottie wrote:
>>>> 23.04.2013 12:48, Steven Simpson kirjoitti:
>>>>> public static String generateWindowsArgument(List<? extends String>
>>>>> args) {
>>>> <offtopic>java.lang.String is final, so nothing can extend it.
>>>> </offtopic>
>>>
>>> It's a matter of habit drawn from the general principle that if I don't
>>> need to modify the list, I don't impose the additional, unnecessary
>>> constraint on the caller, regardless of the element type.
>>
>> I don't understand this. In the first place List<? extends String>  says
>> nothing about your ability to modify the list, you can add and remove
>> Strings to your hearts content,
> Wrong.
>
> List<? extends String> listOfStuff = new ArrayList<String>();
>
> listOfStuff.add("foo"); // compiler error here!
>
[ SNIP ]

One reason (good simple example, btw) of why I don't even bugger about 
with constructs like this, when

List<Parent> listOfStuff = new ArrayList<Parent>();

listOfStuff.add(new Child());

(with Child being a class that extends Parent) works just fine and is 
easier to intuitively understand.

This is just my opinion, but there is something wrong about a language 
when the example you presented fails to compile, which it does fail to 
do. It's counter-intuitive, bespeaks mediocre design, and I avoid it.

AHS

[toc] | [prev] | [next] | [standalone]

#23602 — Re: <? extends String> (was: exec problem is JDK 1.7.0_21)

Steven Simpson wrote:
> Also, just because a class is final now, it might not be in the future.  

Not applicable to 'java.lang.String'.

It will never be non-final.

> It's harder to make an already published class final than to make a 
> final one non-final, because a currently final class won't have any 
> derivations that could be affected by its change of finality.  

You cannot speak in such general terms about 'java.lang.String'. 

> <potentially-dodgy-generalization>Finality is not final; non-finality 
> is.</potentially-dodgy-generalization> That said, it's not likely to 
> happen to String, and maybe there would be other consequences that keep 
> it unlikely.  Nevertheless, my code will remain neutral on this matter, 
> whatever happens.

You're solving a non-existent problem. The finality and immutability of 'String' 
are wired into the promises of the Java language and the type's special treatment by 
the compiler and runtime.

> Furthermore, the class could be re-factored to use (say) CharSequence.  
> By sticking to the principle that is correct whether String or 
> CharSequence is used, I worry less about the specifics of the type in 
> use as I make the change.

Whatever floats your boat. But defensive programming against scenarios that 
won't occur is not really a best practice.

Yes, you can predict that certain scenarios will not occur.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#23603 — Re: <? extends String>

On 23/04/13 22:12, Lew wrote:
> Steven Simpson wrote:
>> Also, just because a class is final now, it might not be in the future.
> Not applicable to 'java.lang.String'.
>
> It will never be non-final.

[...]

> You're solving a non-existent problem.

I concede that my arguments given so far are not compelling.

> The finality and immutability of 'String'
> are wired into the promises of the Java language and the type's special treatment by
> the compiler and runtime.

A particularly good point that I hadn't considered.


> But defensive programming against scenarios that
> won't occur is not really a best practice.

Perhaps I now have a more compelling argument.  Consider:

import java.util.List;

class ExtendsTest {
     // Two methods with identical functionality
     static void foo1(List<? extends String> list) { }
     static void foo2(List<String> list) { }

     interface Bar<T> {
         void bar(List<? extends T> list);
     }

     static class Adapter implements Bar<String> {
         public void bar(List<? extends String> list) {
             foo1(list);
             foo2(list); // error
         }
     }
}

Suppose foo1 and foo2 may have been written with no generic interface in 
mind, perhaps even before Bar was conceived.  Bar comes along, and the 
functionalities of foo1/foo2 are deemed suitable in meeting Bar.bar's 
contract.  How does one now adapt foo2 to Bar?

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#23593

On 23/04/13 10:48, Steven Simpson wrote:
> Does that work correctly for anything to be thrown at CommandLineToArgvW?

No, you idiot.

<http://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx>

If the argument is:

C:\foo bar\

...quotes are needed around it to escape the space:

"C:\foo bar\"

...but a quote at the end will be misinterpreted as a literal quote, and 
result in:

C:\foo bar"

...if it's allowed at all.  The documentation was not clear on whether 
quotes needed to be around the whole argument, or could be used within:

C:\foo" "bar

But then you have to watch for:

C:\foo\ bar\

...which has to be escaped as something like these:

C:\foo"\ "bar\
"C:\foo\ bar"\

The simplest option might be to do as before, but just put the 'final' 
quote immediately before any trailing backslashes:

import java.util.*;
import java.util.regex.*;

public final class WindowsArgumentGenerator {
     private WindowsArgumentGenerator() { }

     private static final Pattern slashSequence = Pattern.compile("(\\\\*)\"");

     private static final Pattern spaces = Pattern.compile("\\s");

     private static boolean needsQuotes(CharSequence s) {
         return spaces.matcher(s).find();
     }

     public static String
         generateWindowsArgument(List<? extends CharSequence> args) {
         StringBuilder out = new StringBuilder();
         String sep = "";

         for (final CharSequence arg : args) {
             out.append(sep);
             sep = " ";

             final boolean quoted = needsQuotes(arg);
             if (quoted)
                 out.append('"');

             final int startOffset = out.length();

             Matcher m = slashSequence.matcher(arg);
             int lastEnd = 0;
             while (m.find()) {
                 out.append(arg.subSequence(lastEnd, m.start()));
                 lastEnd = m.end();

                 final String slashes = m.group(1);

                 /* Double the slashes and add one, then add the
                  * quote. */
                 out.append(slashes)
                     .append(slashes)
                     .append('\\')
                     .append("\"");
             }
             out.append(arg.subSequence(lastEnd, arg.length()));

             if (quoted) {
                 int i = out.length();
                 while (i > startOffset && out.charAt(i - 1) == '\\')
                     i--;
                 out.insert(i, '"');
             }
         }

         return out.toString();
     }

     public static void main(String[] args) throws Exception {
         for (int i = 0; i < args.length; i++)
             System.out.printf("argv[%d]=[%s]%n", i, args[i]);
         System.out.println(generateWindowsArgument(Arrays.asList(args)));
     }
}


Trying it out (in bash):

$ java WindowsArgumentGenerator 'hello world'
argv[0]=[hello world]
"hello world"
$ java WindowsArgumentGenerator '"hello world"'
argv[0]=["hello world"]
"\"hello world\""
$ java WindowsArgumentGenerator '"hello" "world"'
argv[0]=["hello" "world"]
"\"hello\" \"world\""
$ java WindowsArgumentGenerator 'hello" " world'
argv[0]=[hello" " world]
"hello\" \" world"
$ java WindowsArgumentGenerator 'hello' '""' 'world'
argv[0]=[hello]
argv[1]=[""]
argv[2]=[world]
hello \"\" world
$ java WindowsArgumentGenerator 'c:\program files\' 'world'
argv[0]=[c:\program files\]
argv[1]=[world]
"c:\program files"\ world
$ java WindowsArgumentGenerator 'c:\program files\\' 'world'
argv[0]=[c:\program files\\]
argv[1]=[world]
"c:\program files"\\ world
$ java WindowsArgumentGenerator 'c:\program files\\\' 'world'
argv[0]=[c:\program files\\\]
argv[1]=[world]
"c:\program files"\\\ world




-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#23599

Am 23.04.2013 21:56, schrieb Steven Simpson:
> $ java WindowsArgumentGenerator 'c:\program files\\\' 'world'
> argv[0]=[c:\program files\\\]
> argv[1]=[world]
> "c:\program files"\\\ world

That doesn't look right. A correct escaping would be
"c:\program files\\\\\\" world

You have to double the number of backslashes if they preceed a quote.
Also, you have to add another backslash if the quote does not terminate
the argument.

Here's my attempt to the do the escaping:
http://sourceforge.net/p/lejos/code/HEAD/tree/trunk/org.lejos.nxt.ldt/src/main/java/org/lejos/nxt/ldt/util/LeJOSNXJUtil.java#l421

[toc] | [prev] | [next] | [standalone]

#23604

On 23/04/13 21:31, Sven Köhler wrote:
> Am 23.04.2013 21:56, schrieb Steven Simpson:
>> $ java WindowsArgumentGenerator 'c:\program files\\\' 'world'
>> argv[0]=[c:\program files\\\]
>> argv[1]=[world]
>> "c:\program files"\\\ world
> That doesn't look right. A correct escaping would be
> "c:\program files\\\\\\" world
>
> You have to double the number of backslashes if they preceed a quote.

I took it to mean that such a quote is literal, and should be present in 
the string provided by argv.  If I were to pass that line to 
CommandLineToArgvW, I would expect it either to fail because the first 
(and only) argument is quoted, but does not have a closing quote, or 
succeed by inferring the missing quote, yielding the following list of 
one argument:

c:\program files\\\" world



> Also, you have to add another backslash if the quote does not terminate
> the argument.

Again, I took it to mean that the first two rules produce the same 
result, so \\\" and \\" both produce \".

> Here's my attempt to the do the escaping:
> http://sourceforge.net/p/lejos/code/HEAD/tree/trunk/org.lejos.nxt.ldt/src/main/java/org/lejos/nxt/ldt/util/LeJOSNXJUtil.java#l421

I haven't looked in detail at it, but do note your comment:
> * How decoding works:
> * 2n backslashes + quote => n backslashes + closing quote
> * 2n+1 backslashes + quote => n backslashes + inner quote
> * n backslashes not followed by a quote => n backslashes

From 
<http://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx> 
(with my emphasis):
>
>   * 2/n/ backslashes followed by a quotation mark produce /n/
>     backslashes followed by a quotation mark.
>   * (2/n/) + 1 backslashes followed by a quotation mark *again*
>     produce /n/ backslashes followed by a quotation mark.
>   * /n/ backslashes not followed by a quotation mark simply produce
>     /n/ backslashes.
>
>

Where are you getting the notion that the first two rules imply 
different quotes?  I interpret both as being literal (inner, right?).

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web