i.java
Rijndael.javaTripleDES.java
> Please help.
>
> Daniel B. Davis
>
> Errors:
> Microsoft Windows [Version 6.0.6001]
> Copyright (c) 2006 Microsoft Corporation. All rights reserved.
>
> C:\temp\gnu-crypto-2.0.1>ant docs
> Buildfile: build.xml
>
> -init:
-2.0.1>ant docs
Buildfile: build.xml
-init:
[mkdir] Created dir: C:\temp\gnu-crypto-2.0.1\classes
[mkdir] Created dir: C:\temp\gnu-crypto-2.0.1\lib
-check-args:
-build-jce-jar:
[echo] About to compile Java Cryptography Extension (JCE) sources...
[javac] Compiling 83 source files t
gnu crypto, now merged into classpath.
> I downloaded the classpath and the sources are there, but no docs
> (no javadoc html, no .pdf programmer handbook).
>
> Classpath has javadoc online, but seems to only cover the official
> java API stuff, not gnu crypto. Could someon
ources are there, but no docs (no javadoc
html,
no .pdf programmer handbook).
Classpath has javadoc online, but seems to only cover the official java API
stuff, not gnu crypto.
Could someone please tell me where I can find docs that reflect the current
state of gnu crypto
as in classpath 0.96 ? I
Another patch from Ricky.
Brian
--- Begin Message ---
Hi,
I was reading through the hacking.texinfo file and found a few odd uses
of English, and parts that didn't make sense.
I altered these, but I suggest that someone look through my
modifications to make sure I didn't lose any of the origina
Julian Scheid wrote:
> Mark Wielaard wrote:
> > I checked in stubs for all java and javax subpackages.
> > But now that I run gjdoc it seems that it does not like the fact that
> > there are tags in it. It gives errors like:
> > "WARNING: Invalid Unicode character 0x0 in javadoc markup has b
Hi,
On Mon, 2002-05-06 at 21:07, Julian Scheid wrote:
> The clean solution of this problem would require gjdoc to parse HTML,
> something that wasn't necessary so far and needs to be implemented.
>
> But Javadoc requires the ... structure and so,
> to be compatible with Javadoc, Gjdoc needs to p
#x27;s quiet
possible that there are still problems, especially with inner/outer
classes. I'll take a look at that tonight.
I assume you got the warnings when generating docs for the classpath
tree, so I should be able to reproduce them.
> I got a response from RMS and he would like
Hi,
On Sun, 2002-05-05 at 22:37, Julian Scheid wrote:
> Some hints for Classpath documentation authors:
>
> - All package docs are missing (the package.html file
> in the package directories.) This makes the index
> page look somewhat deserted (the right table column
Julian Scheid <[EMAIL PROTECTED]> writes:
> Some hints for Classpath documentation authors:
>
> - All package docs are missing (the package.html file
> in the package directories.) This makes the index
> page look somewhat deserted (the right table column
>
Some hints for Classpath documentation authors:
- All package docs are missing (the package.html file
in the package directories.) This makes the index
page look somewhat deserted (the right table column
ought to contain the summaries.)
- There are some classes whose method comments
> From: Geoff Berry [mailto:[EMAIL PROTECTED]]
>
> Brian Jones <[EMAIL PROTECTED]> writes:
>
> > Shouldn't we use some of these keywords in the source code?
> > My thoughts are that after tagging the source for a release and then
> > doing the export then it is obvious to anyone even outside the u
Brian Jones wrote:
> Shouldn't we use some of these keywords in the source code?
> My thoughts are that after tagging the source for a release and then
> doing the export then it is obvious to anyone even outside the usual
> classpath developer what version of the file they are dealing with and
>
Brian Jones <[EMAIL PROTECTED]> writes:
> Shouldn't we use some of these keywords in the source code?
> My thoughts are that after tagging the source for a release and then
> doing the export then it is obvious to anyone even outside the usual
> classpath developer what version of the file they a
Shouldn't we use some of these keywords in the source code?
My thoughts are that after tagging the source for a release and then
doing the export then it is obvious to anyone even outside the usual
classpath developer what version of the file they are dealing with and
when it was last edited, etc.
Apparently my thinking has at least something in common with Sun's.
(Whether that is a good thing or bad thing is debateable). The
"@serialized" tag I proposed for commenting serializable fields is actually
already part of the latest Javadoc spec. You might want to read up on it as
a few tags h
It depends on what method is used to serialize the class.
If the default method is used, you need to declare transient everything
that is not part of the documented serialized form.
If you write your own writeObject method, declaring things transient
is not needed since you'll have to do everyth
"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> A question about serialization. Do we have to make any instance variables
> that aren't supposed to be serialized in the spec as transiet or something?
> If we don't have to do that, we need to document which variables are
> serialized in our code.
A question about serialization. Do we have to make any instance variables
that aren't supposed to be serialized in the spec as transiet or something?
If we don't have to do that, we need to document which variables are
serialized in our code. This keeps people from changing their names or
elimi
19 matches
Mail list logo
