Hi Nathan
This test:
public class test {
public static void main(String[] args) throws Exception {
String s1 = string 1;
Object o = s1;
System.out.println(s1.compareTo(o));
s1.compareTo(new Object());
}
}
once compiled with javac 1.4 runs the same way on
Stepan
+1.
I just proposed similar modification to classpath of each modules in
another thread, which will make the IDE(Eclipse at least) user easier to
run test.
Stepan Mishura wrote:
Hi George,
Some time ago we agreed to copy resource files to classpath (i.e. bin/test
directory). I saw
IMHO, we should avoid creating duplicate tests. I guess that in this case
the second test was created just only mark that we tested both methods
(readBoolean and writeBoolean).
I think that if there is no unique (different from other scenarios used to
check class implementation) testing scenario
I can see one reason to copy resources - if we want to produce
a single downloadable binary image of the test suite.
Other than that it does not make much sense to me.
The image might be usefull for kind of regular QA cycles later.
Thanks,
Mikhail
2006/4/20, Paulex Yang [EMAIL PROTECTED]:
I suspect inclusion of the resource files (with path renaming) could
be handled by a zip/tar task rather than by copying every time the
tests are run. So I don't think this is a good reason.
Regards,
Mark.
On 4/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I can see one reason to copy
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the resources
sounds good to me, but I don't understand the need to have their output
go to new sub-folders under bin. Why not just have test resources go
under the existing bin/test and main resources go under bin/main
Looks like the (unrelated?) change to the classpath broken another test. I get:
Failed to load resource: hyts_des-ede3-cbc.test1.cipherText
junit.framework.AssertionFailedError: Failed to load resource:
hyts_des-ede3-cbc.test1.cipherText at
Interesting it passed on Windows but fails on Linux :-(
Thanks,
Stepan.
On 4/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
Looks like the (unrelated?) change to the classpath broken another test. I
get:
Failed to load resource: hyts_des-ede3-cbc.test1.cipherText
Hi Stepan,
As I recall it ( I've not my morning coffee yet so it could get a bit
unreliable here :-) ) the motivation for wanting resource files on the
classpath was to enable serialization data files to be read in by test
programs without depending on specific file locations. Copying such
Paulex Yang wrote:
Stepan
+1.
I just proposed similar modification to classpath of each modules in
another thread, which will make the IDE(Eclipse at least) user easier
to run test.
Hi Paulex,
Your proposed modification to the Eclipse .classpath file doesn't add
src/test/resources to the
Mark Hindess wrote:
I suspect inclusion of the resource files (with path renaming) could
be handled by a zip/tar task rather than by copying every time the
tests are run. So I don't think this is a good reason.
Regards,
Mark.
Hi Mark,
The resource files don't get copied every time the
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification and
outputs:
Cannot nest output folder 'text/bin/main' inside output folder 'text/bin'
I have no idea what happened, so I took
George Harley wrote:
Paulex Yang wrote:
Stepan
+1.
I just proposed similar modification to classpath of each modules in
another thread, which will make the IDE(Eclipse at least) user easier
to run test.
Hi Paulex,
Your proposed modification to the Eclipse .classpath file doesn't add
Hi gang,
On Thu, Apr 20, 2006 at 11:14:56AM +0700, Stepan Mishura wrote:
Some time ago we agreed to copy resource files to classpath (i.e. bin/test
directory). I saw that you added corresponing targets to build files. But
now I realized that I don't understand why we should copy them instead
Hi Mark,
Sorry, I misunderstood your append. Please ignore my response. I really
need to go for a coffee :-)
Best regards,
George
George Harley wrote:
Mark Hindess wrote:
I suspect inclusion of the resource files (with path renaming) could
be handled by a zip/tar task rather than by
On 4/20/06, George Harley [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
I suspect inclusion of the resource files (with path renaming) could
be handled by a zip/tar task rather than by copying every time the
tests are run. So I don't think this is a good reason.
Regards,
Mark.
Hi
On 4/20/06, George Harley wrote:
Hi Stepan,
As I recall it ( I've not my morning coffee yet so it could get a bit
unreliable here :-) ) the motivation for wanting resource files on the
classpath was to enable serialization data files to be read in by test
programs without depending on
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification and
outputs:
Cannot nest output folder 'text/bin/main' inside output folder
'text/bin'
Hi Paulex,
Just
Stepan,
In your original commit for HARMONY-315, you made this change:
classpath
pathelement path=${hy.crypto.src.test.resources}/
/classpath
I'm not sure how this relates to this JIRA but it is this that breaks
the test. Why not remove/fix this
On 4/20/06, Leo Simons [EMAIL PROTECTED] wrote:
Hi gang,
On Thu, Apr 20, 2006 at 11:14:56AM +0700, Stepan Mishura wrote:
Some time ago we agreed to copy resource files to classpath (i.e. bin/test
directory). I saw that you added corresponing targets to build files. But
now I realized that
Hi Paulex,
I pressed send a bit too soon there. This is the sort of classpath set
up I was referring to in the previous message. Please note the bottom
classpathentry element which I think specifies the default output
folder for a project.
classpathentry output=bin/main kind=src
Great, it works!
I modified the line below of the .classpath
classpathentry kind=output path=bin/
to
classpathentry kind=output path=bin/main/
And now it is OK.
George Harley wrote:
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but
George Harley wrote:
Hi Paulex,
I pressed send a bit too soon there. This is the sort of classpath
set up I was referring to in the previous message. Please note the
bottom classpathentry element which I think specifies the default
output folder for a project.
classpathentry
Stepan Mishura wrote:
On 4/20/06, George Harley wrote:
Hi Stepan,
As I recall it ( I've not my morning coffee yet so it could get a bit
unreliable here :-) ) the motivation for wanting resource files on the
classpath was to enable serialization data files to be read in by test
programs
Paulex Yang wrote:
George Harley wrote:
Hi Paulex,
I pressed send a bit too soon there. This is the sort of classpath
set up I was referring to in the previous message. Please note the
bottom classpathentry element which I think specifies the default
output folder for a project.
I think it is rather dangerous way: some people will test when resources
are in src/ while others - when they are moved to bin by tar or something else
So if we want to have a single binary image we have to create it first
(by copying
resources)
Thanks,
Mikhail
2006/4/20, Mark Hindess [EMAIL
George Harley wrote:
Paulex Yang wrote:
George Harley wrote:
Hi Paulex,
I pressed send a bit too soon there. This is the sort of classpath
set up I was referring to in the previous message. Please note the
bottom classpathentry element which I think specifies the default
output folder for
On 4/20/06, George Harley wrote:
Stepan Mishura wrote:
On 4/20/06, George Harley wrote:
Hi Stepan,
As I recall it ( I've not my morning coffee yet so it could get a bit
unreliable here :-) ) the motivation for wanting resource files on the
classpath was to enable serialization data
On 4/20/06, Mark Hindess wrote:
Stepan,
In your original commit for HARMONY-315, you made this change:
classpath
pathelement path=${hy.crypto.src.test.resources}/
/classpath
I'm not sure how this relates to this JIRA
Right, it was better to separate
OK, I'll remove duplicate tests then
Thanks,
Mikhail
2006/4/20, Stepan Mishura [EMAIL PROTECTED]:
IMHO, we should avoid creating duplicate tests. I guess that in this case
the second test was created just only mark that we tested both methods
(readBoolean and writeBoolean).
I think that if
Without the classpath modifications then it works for me on linux.
-Mark.
On 4/20/06, Stepan Mishura [EMAIL PROTECTED] wrote:
On 4/20/06, Mark Hindess wrote:
Stepan,
In your original commit for HARMONY-315, you made this change:
classpath
pathelement
But doesn't work for me.
-Stepan
On 4/20/06, Mark Hindess wrote:
Without the classpath modifications then it works for me on linux.
-Mark.
On 4/20/06, Stepan Mishura [EMAIL PROTECTED] wrote:
On 4/20/06, Mark Hindess wrote:
Stepan,
In your original commit for HARMONY-315, you
You'll recall a while ago when we were discussing moving j.l.String out
from KERNEL to LUNI [1] that the shape of String is something we would
expect VMs JITs to be sensitive to (like all our KERNEL classes), but
that there is significant shared behavior that it is worth sharing
(which is why we
Hi Tim,
I have an objection.
Locking has nothing to do with commit control. Allowing for svn
locking functionality is opening a can of worms. What if somebody
aquires a lock and loses network connectivity for a week (because of a
Hurricane, because he forgot and went on vacation, etc.)? The
Lots of potential projects in the tools area too:
javadoc is still out there as a juicy project
we discussed a while ago,
rmic/d/registry, jar, policytool, jconsole, etc.
something for everyone and a good variety of effort
required for these.
Performance analysis, as broad
Is there some reason why you are not using the message catalog for these
exception messages like we do for others? These are intended to be read
by users so we want them to the NLS-enabled.
Take a look at Msg.java and ExternalMessages.properties in
org.apache.harmony.luni.util.
There are
Etienne Gagnon wrote:
Hi Tim,
I have an objection.
Sure, that's why I asked!
Locking has nothing to do with commit control.
Yes it does, your commit will fail if I have the lock; but I am abusing
it to achieve a somewhat different goal of 'inadvertent modification'.
Allowing for svn
Daniel,
Regretfully, we have no specific top level design documentation.
However, the general design of the RMI package is described rather
well in public sources.
For example, you could check the Java RMI: Remote Method Invocation
book by Troy Bryan Downing or Sun's jGuru RMI course at
Daniel,
We started our development as a clean room implementation
of the package following the spec; and we found it -the spec
(JRMP included)- to be vague and incomplete making it impossible
for us to get interoperability without doing code inspection
or reverse engineering, which was not
Tim Ellison wrote:
Yes it does, your commit will fail if I have the lock; but I am abusing
it to achieve a somewhat different goal of 'inadvertent modification'.
OK, we both agree on the abuse part. ;-P
If we cannot contact the lock holder we simply break/steal the lock.
Right. But, locks
Well, the reason is we did not discuss the topic here
2006/4/20, Tim Ellison [EMAIL PROTECTED]:
Is there some reason why you are not using the message catalog for these
exception messages like we do for others? These are intended to be read
by users so we want them to the NLS-enabled.
Take
Performance analysis sounds interesting...
Any links/pointers to get started?
And hey, who was to put the source code tar on the web x-( ?
Are you guys posting this project on Summer of code??
Regards,
Sanket
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent:
Archie Cobbs wrote:
Etienne Gagnon wrote:
Tim Ellison wrote:
Not really. I can add the warning, but I was looking for a way to
ensure people did not mistakenly change String or did not read the
doc/dev list. By failing people's commit and making them explicitly
acquire the token first they
Dear all,
on behalf of ITC I have updated our contribution of the package
java.math including some recent optimizations (HARMONY-199). I think
it would be interesting to compare our implementation with the one
donated by Intel (HARMONY-39). In order to do that, it would be nice
to have a
Geir Magnusson Jr wrote:
3) Lock down function and behavior tightly with tests - that if
modified, tests will break, and that should raise an alarm to the
committer.
One easy way would be to add a test that compares the String.java source
code with a saved version, and that fails if unequal.
To celebrate the opening of my 100th JIRA earlier today, I thought I'd
produce some simple statistics - using 138 lines of ugly Perl - for
the HARMONY JIRAs.
The columns are key, percentage, count. The letters in the bars
are the first characters of the Resolutions from the first table.
Not
Vasily,
I was not looking for public general designs of RMI, I do
know them very well :) thanks anyway...
I asked about specific design docs of your implementation
and the architecture behind it; I'm sure you did it in order to
design the package before coding it, but its ok if you do
not
Zakharov, Vasily M wrote
Daniel,
We started our development as a clean room implementation
of the package following the spec; and we found it -the spec
(JRMP included)- to be vague and incomplete making it impossible
for us to get interoperability without doing code inspection
or reverse
Etienne Gagnon wrote:
Hi Tim,
I have an objection.
Locking has nothing to do with commit control. Allowing for svn
locking functionality is opening a can of worms. What if somebody
aquires a lock and loses network connectivity for a week (because of a
Hurricane, because he forgot and went on
Hi Daniel,
indeed it makes sense to compare the performance both implementations of
java.math package
using the real applications. If you have any results could you plase to make
them public?
I want to look at them. Besides I'd pefer to slightly correct you about the
SVN repository already
Hi Mark,
Do you mean that the test tests/api/javax/crypto/CipherTest.java passes on
you linux without classpath modification?
Thanks,
Stepan.
On 4/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
Without the classpath modifications then it works for me on linux.
-Mark.
On 4/20/06, Stepan
Since I probably share some responsibility in the String is special topic
being brought up, I wanted to try out the golden ticket bit for some
further enhancements.
I've made some changes to String to add the new Java 5 APIs related to code
points, StringBuilder, etc.
I've posted a proposed
BTW: Here's a direct link to the patch -
http://issues.apache.org/jira/secure/attachment/12325649/String_java_5_metho
ds3.txt
-Original Message-
From: Nathan Beyer [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 20, 2006 9:30 PM
To: harmony-dev@incubator.apache.org
Subject: Java 5
Mark
Is there some reason why you are not putting new regression tests into an
existing PropertyDescriptorTest?
Thanks,
Mikhail
[ http://issues.apache.org/jira/browse/HARMONY-237?page=all ]
Mikhail Loenko reassigned HARMONY-237:
--
Assign To:
On 4/21/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Mark
Is there some reason why you are not putting new regression tests into an
existing PropertyDescriptorTest?
Yes. I opened the JIRA on 22nd March almost a month before the
current test was integrated. ;-)
-Mark.
It did when I submitted the patch.
-Mark.
On 4/21/06, Stepan Mishura [EMAIL PROTECTED] wrote:
Hi Mark,
Do you mean that the test tests/api/javax/crypto/CipherTest.java passes on
you linux without classpath modification?
Thanks,
Stepan.
On 4/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
I have been watching this issue closely because it will directly
affect my work on BootJVM with the (minimal) native part
of java.lang.String . I am in favor of a stricter control on this
class in the interest of making sure we do not make mistakes
such as what you anticipate that
Oh, I see - thanks!
- Stepan.
On 4/21/06, Mark Hindess wrote:
But I can't see how. It is a tirvial fix though changing cipherText
on line 554 to 'ciphertext' to match the case of the checked in file
name.
-Mark.
On 4/21/06, Mark Hindess [EMAIL PROTECTED] wrote:
It did when I submitted
58 matches
Mail list logo
