[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: api docs, java source



Hi

Matthew Johnson wrote:
> On Wed Dec 16 04:28, Pablo Duboue wrote:
>> [...]
>> The objective of packing java libraries is so people don't need to
>> fetch and compile them themselves. If we only provide stripped
>> libraries with no source they will be good for execution but not for
>> development.
> 
> See above, policy (I thought?) says that we don't provide stripped
> libraries, since in Java it doesn't give much of a performance
> improvement, but it's very useful for things like debugging and (iirc?)
> eclipse completion.
> 
> Matt
>  

I could not find anything about this in the current policy. My last
draft did however mention this as a "should" for java code, but not JNI
which was not mentioned at all. In the second draft (that I am working
on) JNI "must" be stripped like regular shared libraries.

Should I bump that should on compiling with "debug enabled" for java
code to a must?

Matthew Johnson wrote:
> On Tue Dec 15 21:05, Onkar Shinde wrote:
> > Please file a bug. The docs should go to /usr/share/doc/junit4/api.
> > [ ... ]
>
> I thought it was there, either currently or in the new draft. It
> certainly should be. The new version of javahelper I just uploaded
> does this for you and also generates a doc-base file for it.

This is in the current draft and will also be in the new draft, though
with a slight modification that allows for api-$part as well. This is
the current practice for libservlet2.4-java - which generates a separate
javadoc for its servlet and its jsp jar. I believed it made sense to
make this separation - while jsp depends on servlet they are two
different specifications.

On a related note: The current (as well as the future) draft currently
specifies that the api should be installed in
/usr/share/doc/${libpackage}/api and not
/usr/share/doc/${docpackage}/api (though it can do so by simply placing
a symlink from ${libpackage}/api to ${docpackage}/api).

I figured now would be a great time to mention it in case there are
people who disagree[1].

Sylvestre Ledru wrote:
> Le mercredi 16 décembre 2009 à 04:13 -0500, Pablo Duboue a écrit :
> [...]

> > $ javac -help
> > Usage: javac <options> <source files>
> > where possible options include:
> >   -g                         Generate all debugging info
> >   -g:none                    Generate no debugging info
> >   -g:{lines,vars,source}     Generate only some debugging info
> OK, thanks.
> Is it interesting to have in the Debian context?
> (ie, does Java debugging tools are actually using them?)
>
> Sylvestre

(As far as I could tell no one addressed this, so here goes)

Not just the java debug tools but also the JVMs; without debug info you
lose information from stack traces - e.g. what line the exception was
thrown from.

With:
javac -g Test.java && java Test
Exception in thread "main" java.lang.RuntimeException
        at Test.main(Test.java:3)

Without:
javac -g:none Test.java && java Test
Exception in thread "main" java.lang.RuntimeException
        at Test.main(Unknown Source)

By default openjdk's javac compiles with -g:lines,source (taken from the
manpage).

~Niels

[1] It could save me another draft! ;-)


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: