On 1/27/06, Mariano <[EMAIL PROTECTED]> wrote:
> Hi, I am new at the mail list and I want to know if the java.math package is
> being developed at the moment.
Sure, there is at least one proposed implementation of the java.math
package which can be found at
http://issues.apache.org/jira/browse/HAR
[ http://issues.apache.org/jira/browse/HARMONY-24?page=all ]
Tim Ellison resolved HARMONY-24:
Resolution: Fixed
Vladimir,
Fixed in LUNI module java.net.URLEncoder at repo revision 372920.
Please check that this fully resolves your problem.
> jav
Hi, I am new at the mail list and I want to know if the java.math package is
being developed at the moment.
Thanks!
Mariano
[ http://issues.apache.org/jira/browse/HARMONY-20?page=all ]
Tim Ellison resolved HARMONY-20:
Resolution: Fixed
George,
Fixed in LUNI module java.utils.Collections.java at repo revision 372905.
Please check that this fully resolves your problem.
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
reasons Mark and others described.
I'll go review, but can you summarize?
Sure
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL
PROTECTED]
http://mail-archives.apache.org/mod_mbox/incubator-
[ http://issues.apache.org/jira/browse/HARMONY-50?page=all ]
Geir Magnusson Jr updated HARMONY-50:
-
Component: Classlib
> java.io.RandomAccessFile should accept all modes that are defined in the
> specification, including "rws" and "rwd"
> -
[ http://issues.apache.org/jira/browse/HARMONY-50?page=all ]
Geir Magnusson Jr reassigned HARMONY-50:
Assign To: Tim Ellison
> java.io.RandomAccessFile should accept all modes that are defined in the
> specification, including "rws" and "rwd"
>
[ http://issues.apache.org/jira/browse/HARMONY-44?page=all ]
Geir Magnusson Jr closed HARMONY-44:
Resolution: Fixed
patch applied. tests pass
thanks
> some security2 unit tests log redundant information
> -
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> reasons Mark and others described.
>
> I'll go review, but can you summarize?
Sure
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL
PROTECTED]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601
> This ties us hard to JUnit. That's my only worry. I'd like to also
> keep in consideration how ant, maven, etc can drive this aspect of testing..
Definitely. However 'system-related' scenarious are usually quite
complicated and can hardly perform the required environment settings
(tools instal
Various bits snipped...
On Fri, Jan 27, 2006 at 10:45:35AM -0500, Geir Magnusson Jr wrote:
> If we are going to do javadoc for java*, and
> we have to to be a serious implementation, I'd
> like to ensure that there's no confusion with
> the spec.
+1 (as in, confusion == bad)
> I'd lik
Leo Simons wrote:
On Fri, Jan 27, 2006 at 06:05:23AM -0500, Geir Magnusson Jr wrote:
Zsejki Sorin Mikl�s wrote:
Geir Magnusson Jr wrote:
Zsejki Sorin Mikl�s wrote:
Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
No. IMO, we should *not* be creating a parallel set of
Sorry for being away during the major part of your discussion. Hope
I'm still not too late.
As I can see currently we have only one 'exotic' situation - some
tests which are based on providers and use so many provider's
fucntionality that cannot be replaced with mock objects in a
reasonable time.
George Harley wrote:
OK. What I am driving at is extending the basic JUnit test runner with a
JUnit decorator that could be employed to decide - at runtime - on
whether or not certain test cases in the test suite should be run. The
decorator could also write out what tests got skipped.
T
George Harley wrote:
Hi Geir,
> This is why I advocate making a "separate tree" for the system tests
- make it clear that they are not the general unit tests...
Right. But rather than being a separate directory tree in the source
repository that separate tree could be realised as a logica
Mikhail Loenko wrote:
Well, I like things clean and simple too :)
We could develop our own implementations for unit tests, it would take
the same efforts as develop our own provider. It's a huge amount of work.
Now we use BouncyCastle provider for the purpose of unit testing:
it's open source,
Mikhail Loenko wrote:
On 1/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
If the test can be configured by a few people only who works on that
specific area and those people are aware of those tests why not just
print a log when the test is skipped?
Because the same set of people that wi
Stepan Mishura wrote:
Sounds dirty. How about security-x?
Ok. I named it by analogy with x-net. Your variant works for me.
x-net has the same issue for me. I figure that net-x is better too
because it will sit next to net in a directory/IDE package tree, etc...
(just like security-x ne
OK, let's see your contribution.
Meanwhile I've gone through the security2 unit tests; there are some of them
that *can not* do verification in some 'exotic' configurations, I've made them
reporting failure in this case.
And there are a few tests that *can* verify in some 'exotic' configuration o
Hi Mikhail,
Comments inlined below ...
Best regards,
George
IBM UK
Mikhail Loenko wrote:
Hi George,
On 1/27/06, George Harley <[EMAIL PROTECTED]> wrote:
Sure. And it should be the role of the test framework to inform users
about which tests got run, passed, failed, got skipped etc.
Tim Ellison wrote:
Geir Magnusson Jr wrote:
We will have javadoc of our code, and we do need need to have notes re
our impl of java*.*, but I think at all times we should be pointing to
the spec javadoc, and not re-writing it.
As previously stated, I disagree on this and believe that we have
On 1/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> > If the test can be configured by a few people only who works on that
> > specific area and those people are aware of those tests why not just
> > print a log when the test is skipped?
>
> Because the same set of people that will be bother
>
>Sounds dirty. How about security-x?
>
Ok. I named it by analogy with x-net. Your variant works for me.
Thanks,
Stepan
On 1/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
> Sounds dirty. How about security-x?
>
> Stepan Mishura wrote:
> > I agree with the proposal and I'm ready to st
FWIW, for onlookers...
I don't think the answer to tims question was very clear just yet.
The default assignee is "unassigned". I have a hunch it was "project
lead" (jira has mandatory project leads, silly tool) until recently,
which is set to geir.
cheers,
LSD
On Thu, Jan 26, 2006 at 04:49:28A
On Fri, Jan 27, 2006 at 06:05:23AM -0500, Geir Magnusson Jr wrote:
> Zsejki Sorin Mikl?s wrote:
> >Geir Magnusson Jr wrote:
> >>Zsejki Sorin Mikl?s wrote:
> >>>Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
> >>
> >>No. IMO, we should *not* be creating a parallel set of jav
Hi Geir,
> This is why I advocate making a "separate tree" for the system tests
- make it clear that they are not the general unit tests...
Right. But rather than being a separate directory tree in the source
repository that separate tree could be realised as a logical JUnit test
suite group
Hi George,
On 1/27/06, George Harley <[EMAIL PROTECTED]> wrote:
> Sure. And it should be the role of the test framework to inform users
> about which tests got run, passed, failed, got skipped etc.
see below
> > It would not disturb most of the people because the test will pass in 'bad'
> > envi
Well, I like things clean and simple too :)
We could develop our own implementations for unit tests, it would take
the same efforts as develop our own provider. It's a huge amount of work.
Now we use BouncyCastle provider for the purpose of unit testing:
it's open source, everyone can download it
Geir Magnusson Jr wrote:
> We will have javadoc of our code, and we do need need to have notes re
> our impl of java*.*, but I think at all times we should be pointing to
> the spec javadoc, and not re-writing it.
As previously stated, I disagree on this and believe that we have to
create descript
Hi Mikhail,
None of my test messages to the list from this account seem to have reached
their destination. I'll keep my fingers crossed for this response though...
Mikhail Loenko wrote:
On 1/27/06, George Harley1 <[EMAIL PROTECTED]> wrote:
But because we live in a less than ideal world the
Mikhail Loenko wrote:
On 1/27/06, George Harley1 <[EMAIL PROTECTED]> wrote:
But because we live in a less than ideal world there will, no doubt, be
some tests that will demand an
environment that is impossible or at the very least difficult to mock up
for the majority of developers/testers.
On 1/27/06, George Harley1 <[EMAIL PROTECTED]> wrote:
> But because we live in a less than ideal world there will, no doubt, be
> some tests that will demand an
> environment that is impossible or at the very least difficult to mock up
> for the majority of developers/testers.
I'm absolutely agree
Zsejki Sorin Miklós wrote:
Geir Magnusson Jr wrote:
Zsejki Sorin Miklós wrote:
Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
No. IMO, we should *not* be creating a parallel set of javadoc for
J2SE. There already is the standard set produced by the expert grou
Geir Magnusson Jr wrote:
Zsejki Sorin Miklós wrote:
Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
No. IMO, we should *not* be creating a parallel set of javadoc for
J2SE. There already is the standard set produced by the expert group
(part of the spec).
To cl
Tim Ellison wrote:
Zsejki Sorin Miklós wrote:
Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
Strictly speaking, no. To be called "Java" you have to pass the JCK
that AIUI does not test the javadoc tool. In any case, I think having a
javadoc would be cool. Do you ha
Geir Magnusson Jr wrote:
Zsejki Sorin Miklós wrote:
Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
No. IMO, we should *not* be creating a parallel set of javadoc for
J2SE. There already is the standard set produced by the expert group
(part of the spec).
I m
I don't see this as "either/or" but as both.
We need javadoc. Clearly. Every java programmer is used to it, and
tools use it.
That said, we do need documentation beyond what javadoc offers.
Question for d'Oxygen :) nerds is it too painful to write regular
docs in it - i.e. independent
Zsejki Sorin Miklós wrote:
Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
No. IMO, we should *not* be creating a parallel set of javadoc for
J2SE. There already is the standard set produced by the expert group
(part of the spec).
I'm not interested in going down
[
http://issues.apache.org/jira/browse/HARMONY-52?page=comments#action_12364201 ]
Vladimir Strigun commented on HARMONY-52:
-
Ive found small testcase for the issue:
public static void main(String[] args) throws Exception{
byte[] arr = {'a
Sounds dirty. How about security-x?
Stepan Mishura wrote:
I agree with the proposal and I'm ready to start working on a patch for
splitting 'security2' into suggested components and integrating them with
the current build.
Also I'd like to suggest a name for a new component: 'x-security'.
Tha
Mikhail Loenko wrote:
Do you mean that for a single test that verifies 10 lines of code
working on very specific configuration I have to create a parallel test tree?
The model I had in my head was based on two things - making it easy for
the casual browser to figure out what is what, and mak
java.io.File.hashCode() returns incorrect value
---
Key: HARMONY-53
URL: http://issues.apache.org/jira/browse/HARMONY-53
Project: Harmony
Type: Bug
Components: Classlib
Environment: windows
Reporter: Vladimir Ivano
Hi,
> I agree with all this. The unit tests are one style of test for
> establishing the correctness of the code. As you point out the unit
> tests typically require a well-defined environment in which to run, and
> it becomes a judgment-call as to whether a particular test's
> environmental r
Zsejki Sorin Miklós wrote:
> Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
Strictly speaking, no. To be called "Java" you have to pass the JCK
that AIUI does not test the javadoc tool. In any case, I think having a
javadoc would be cool. Do you have any skills in this a
Hi Sunny,
I agree that the Java code documentation should use javadoc mark-up.
The native code is a good candidate for Doxygen-style comments, with the
advantage that if you want to generate docs that cover native and java
code (like we did for the porting guide) the Doxygen tool can cross 'the
la
Hi Sunny,
As far as I can tell, Doxygen seems to work just fine with Javadoc-style
comments. So comments could still be written using Javadoc markup (keeping
Eclipse content-assist happy) while leaving the way open for Doxygen to be
the chosen documentation tool for Harmony.
Best regards,
G
java.io.ByteArrayOutputStream.toString(String) throws
IllegalCharsetNameException instead of UnsupportedEncodingException
--
Key: HARMONY-52
URL: http://issue
Anton Avtamonov wrote:
>> Note that I could create my own provider and test with it, but what I would
>> really want is to test how my EncryptedPrivateKeyInfo works with
>> AlgorithmParameters from real provider as well as how my other classes work
>> with real implementations of crypto Engines.
>>
java.io.Writer : write(String) should write String as atomic operation.
---
Key: HARMONY-51
URL: http://issues.apache.org/jira/browse/HARMONY-51
Project: Harmony
Type: Bug
Components: Classlib
Doesn't Harmony need Javadoc anyway just in order to be called "Java"?
Sunny Chan wrote:
Hi all,
I am more of a lurker :-) but I have an opinion on this matter.
If I were to develop a java class library I would stick to Javadoc.
Remember, things like Eclipse have support for javadoc embedded
50 matches
Mail list logo
