GNU classpath contribution question
Hi, I have read the FAQ on contributing to GNU classpath, and I am still left with a question: Let's say for example standard Java defines some constant like FileFormat.BINARY. The Javadoc does not specify the value of this constant. I want to write a replacement for FileFormat, so I write a program System.out.println(FileFormat.BINARY) and run it against Sun's implementation. I find out that the value is 1, and I put that in my implementation. Is this legit for the purposes of contribuing to classpath? Thanks, Ken Larson, Larson Technologies, Inc.
Re: GNU classpath contribution question
Hi Ken, what you describe is called black box testing and is a legit mean. cya Robert Ken Larson wrote: > Hi, > > I have read the FAQ on contributing to GNU classpath, and I am still > left with a question: > > Let's say for example standard Java defines some constant like > FileFormat.BINARY. The Javadoc does not specify the value of this > constant. I want to write a replacement for FileFormat, so I write a > program > > System.out.println(FileFormat.BINARY) and run it against Sun's > implementation. I find out that the value is 1, and I put that in my > implementation. > > Is this legit for the purposes of contribuing to classpath? > > > Thanks, > > > Ken Larson, > Larson Technologies, Inc. > > > signature.asc Description: OpenPGP digital signature
Re: GNU classpath contribution question
Hi Ken, On Wed, 2006-02-01 at 16:09 -0500, Ken Larson wrote: > System.out.println(FileFormat.BINARY) and run it against Sun's > implementation. I find out that the value is 1, and I put that in my > implementation. > > Is this legit for the purposes of contribuing to classpath? Normally public constants are listed in the public documentation. Otherwise you can look them up in the O'Reilly or Addison-Wesley books. Checking constants to make sure different implementations use the same public interface is fine. In general public user visible constants like this should be similar to make us more compatible with other implementations (especially since constants are embedded into the .class file when compiling sources) so programs work as is with our implementation. You can also add a Mauve test to make sure we stay compatible. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: GNU classpath contribution question
Ken Larson wrote: Let's say for example standard Java defines some constant like FileFormat.BINARY. The Javadoc does not specify the value of this constant. Actually, it probably does: http://java.sun.com/j2se/1.5.0/docs/api/constant-values.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GNU classpath contribution question
Hi Ken, > Let's say for example standard Java defines some constant like > FileFormat.BINARY. The Javadoc does not specify the value of this > constant. I want to write a replacement for FileFormat, so I write a > program > > System.out.println(FileFormat.BINARY) and run it against Sun's > implementation. I find out that the value is 1, and I put that in my > implementation. > > Is this legit for the purposes of contribuing to classpath? First of all, if a constant is not in the JavaDoc, it is most likely initialized with a value that may differ in different environments in the static initializer of a class and the value you get from System.out.println(FileFormat.BINARY) may be right, but others are also possible. This might be the case for platform dependend constants, language specific constants etc. To really answer your questions, I would think that this is ok. At least this is what we do in lots of Mauve test cases (Mauve is our testsuite for compatibility testing). /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: GNU classpath contribution question
On Wed, Feb 01, 2006 at 04:09:00PM -0500, Ken Larson wrote: > Hi, > > I have read the FAQ on contributing to GNU classpath, and I am still > left with a question: > > Let's say for example standard Java defines some constant like > FileFormat.BINARY. The Javadoc does not specify the value of this > constant. I want to write a replacement for FileFormat, so I write a > program > > System.out.println(FileFormat.BINARY) and run it against Sun's > implementation. I find out that the value is 1, and I put that in my > implementation. > > Is this legit for the purposes of contribuing to classpath? In that case, I'd say yes. The number 1 is not copyrightable, and you need the correct value for interoperability. With recent J2SE API documentation, Sun publishes constants and serialization layouts, so I'd hope that the question is moot these days. In general, it depends on the information. If, say, the Java bytecode format was ammended to include annotations for the source code each bytecode in a class corresponds to, for better debugger support, and there was an javax.bytecode.annotations.debugger API to work on those annotations, then harvesting the annotations programmatically would not result in something one could safely put into GNU Classpath to quickly finish the missing classes. :) Sometimes the values Sun uses also don't make sense outside Sun's world, for example when selecting a default provider for some javax.xml SPI. That's pretty runtime dependant. cheers, dalibor topic > > > Thanks, > > > Ken Larson, > Larson Technologies, Inc. > >
Re: GNU classpath contribution question
Roman Kennke writes: > Hi Ken, > > > Let's say for example standard Java defines some constant like > > FileFormat.BINARY. The Javadoc does not specify the value of this > > constant. I want to write a replacement for FileFormat, so I write a > > program > > > > System.out.println(FileFormat.BINARY) and run it against Sun's > > implementation. I find out that the value is 1, and I put that in my > > implementation. > > > > Is this legit for the purposes of contribuing to classpath? > > First of all, if a constant is not in the JavaDoc, it is most likely > initialized with a value that may differ in different environments No, that's simply impossible. If a constant is part of a public interface it must _not_ change between platforms that support that public interface. This is because the compiler inlines the values of integer constants. It must do that because otherwise static final fields couldn't be used in tableswitch instructions. This is probably a bug in the design... Andrew.
