Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
On Thu, 28 Oct 2004 14:00:12 +0100, Peter Reilly <[EMAIL PROTECTED]> wrote: > Steve Loughran wrote: > > > > > How about we just call toString() on every value; its a no-op on all > > strings, and robust on odd stuff? > > This will not work, as we need to call properties.propertyNames() to get > the names. > propertyNames will trigger the Cast exception. > aah. we could prescan the properties and catch any that are of the wrong time and string-them-up(*) . It wont do anything for stuff up the chain, of course. -steve (*) UK term for execution by hanging. which used to take place at the top of my road, >=two hundred years back. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
Steve Loughran wrote: How about we just call toString() on every value; its a no-op on all strings, and robust on odd stuff? This will not work, as we need to call properties.propertyNames() to get the names. propertyNames will trigger the Cast exception. Peter -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
because it is in the root class Object. -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 6:05 PM To: Ant Developers List Subject: Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java How about we just call toString() on every value; its a no-op on all strings, and robust on odd stuff? -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
How about we just call toString() on every value; its a no-op on all strings, and robust on odd stuff? -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
On Thu, 28 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote: > However, it is breaking the usage of properties, for example: I know. But still people "abused" Ant's properties that way, so I wonder whether we need to expect people doing the same with system properties. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Peter Reilly wrote:
>
> > Stefan Bodewig wrote:
> >
> >> On Thu, 28 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> Stefan Bodewig wrote:
> >>>
> >>>
> What if the keys/values are not Strings?
>
>
>
> >>>
> >>> In this case, the "properties" are from
> System.getProperties() and
> >>> not from Project.getProperties() so they are strings.
> >>>
> >>
> >>
> >> Who is going to prevent System.getProperties().put(Object, Class)?
> >>
> >>
> > Nothing...
> > However, it is breaking the usage of properties, for
> example: public
> > class Test {
> >public static void main(String[] args) {
> >Integer i = new Integer(10);
> >System.getProperties().put(i, "10");
> >System.getProperties().list(System.out);
> >}
> > }
>
>
> Acutally:
> Integer i = new Integer(10);
> System.getProperties().put(i, "10");
> Enumeration names = System.getProperties().propertyNames();
>
> Also gives the java.lang.ClassCastException exception.
> Since Properties.propertyNames() is the correct way to
> retieve the names of the system properties, we cannot check
> if the user has messed up the
> contents
> of the properties (without always iterating over the contents and
> removing invalid
> keys and values and *then* calling propertyNames).
>
> Peter
>
> > gets an exception:
> > Caused by: java.lang.ClassCastException: java.lang.Integer
> >at java.util.Properties.enumerate(Properties.java:869)
> >at java.util.Properties.list(Properties.java:823)
> >at Test.main(Unknown Source)
> >
> > We could put a check in, but as it is not in the jdk for (is it 10
> > years??), it
> > may not be vital...
> >
The only thing we need to be sure is that is such exception occurs, then
ANT ends throwing a BuildException.
We are not suppose to fence for every bad API use of every user or every
IDE.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
Peter Reilly wrote:
Stefan Bodewig wrote:
On Thu, 28 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
Stefan Bodewig wrote:
What if the keys/values are not Strings?
In this case, the "properties" are from System.getProperties() and
not from Project.getProperties() so they are strings.
Who is going to prevent System.getProperties().put(Object, Class)?
Nothing...
However, it is breaking the usage of properties, for example:
public class Test {
public static void main(String[] args) {
Integer i = new Integer(10);
System.getProperties().put(i, "10");
System.getProperties().list(System.out);
}
}
Acutally:
Integer i = new Integer(10);
System.getProperties().put(i, "10");
Enumeration names = System.getProperties().propertyNames();
Also gives the java.lang.ClassCastException exception.
Since Properties.propertyNames() is the correct way to retieve the names
of the system properties, we cannot check if the user has messed up the
contents
of the properties (without always iterating over the contents and
removing invalid
keys and values and *then* calling propertyNames).
Peter
gets an exception:
Caused by: java.lang.ClassCastException: java.lang.Integer
at java.util.Properties.enumerate(Properties.java:869)
at java.util.Properties.list(Properties.java:823)
at Test.main(Unknown Source)
We could put a check in, but as it is not in the jdk for (is it 10
years??), it
may not be vital...
Peter
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
Stefan Bodewig wrote:
On Thu, 28 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
Stefan Bodewig wrote:
What if the keys/values are not Strings?
In this case, the "properties" are from System.getProperties() and
not from Project.getProperties() so they are strings.
Who is going to prevent System.getProperties().put(Object, Class)?
Nothing...
However, it is breaking the usage of properties, for example:
public class Test {
public static void main(String[] args) {
Integer i = new Integer(10);
System.getProperties().put(i, "10");
System.getProperties().list(System.out);
}
}
gets an exception:
Caused by: java.lang.ClassCastException: java.lang.Integer
at java.util.Properties.enumerate(Properties.java:869)
at java.util.Properties.list(Properties.java:823)
at Test.main(Unknown Source)
We could put a check in, but as it is not in the jdk for (is it 10
years??), it
may not be vital...
Peter
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
On Thu, 28 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote: >> >>What if the keys/values are not Strings? >> >> > In this case, the "properties" are from System.getProperties() and > not from Project.getProperties() so they are strings. Who is going to prevent System.getProperties().put(Object, Class)? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
Stefan Bodewig wrote: On 28 Oct 2004, <[EMAIL PROTECTED]> wrote: fix for previous fix - use getProperty() and not get() What if the keys/values are not Strings? In this case, the "properties" are from System.getProperties() and not from Project.getProperties() so they are strings. The issue is that System.getProperties().get() was used rather that System.getProperties().getProperty() get() may bypass the default resolving logic in the jdk (looking at the code, this seems to be the case) Peter There must be a very old bug lurking in Bugzilla that was resolved by not assuming that the Ant properties table only contains Strings. I'm not sure whether the system properties table gets abused in a similar way by anybody. If so, this is a backwards incompatible change, I guess. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types CommandlineJava.java PropertySet.java
On 28 Oct 2004, <[EMAIL PROTECTED]> wrote: > fix for previous fix - use getProperty() and not get() What if the keys/values are not Strings? There must be a very old bug lurking in Bugzilla that was resolved by not assuming that the Ant properties table only contains Strings. I'm not sure whether the system properties table gets abused in a similar way by anybody. If so, this is a backwards incompatible change, I guess. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
