This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 28240 - There should be some system property suppressing startup warnings for deprecated things.
Summary: There should be some system property suppressing startup warnings for depreca...
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on: 24056
Blocks: 27926
  Show dependency tree
 
Reported: 2002-10-24 09:01 UTC by Jan Jancura
Modified: 2008-12-22 17:50 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Jancura 2002-10-24 09:01:04 UTC
We need some way how to suppress startup warnings
for deprecated things during cont. build. May be
there should be special constant for problems with
DEPRECATED functionality which has no impact to users.
Comment 1 Jesse Glick 2002-10-24 14:00:23 UTC
OK, not exactly a bug, but useful for buildmasters. Specifics:

- only applies to developer-oriented deprecation messages with no
particular user impact

- a system property would suffice

- or, a special ErrorManager domain or logging level (details TBD)

- should apply to layer CDATA warnings, module deprecation warnings,
any stack traces printed from first uses of deprecated code,
layer-obsoleted manifest section warnings, missing SVUID notices,
DataLoader(Class) constructor, more? All notices printed during
current NB dev start, and I guess S1S start too.

- default will be turned on, buildmasters can turn off. Yes I want
this by default on even for releases; netbeans.logger.console=false
for releases, so all of this goes to ide.log not actual console; but
we need these warnings enabled so as to alert third-party (off-nb.org)
module developers to deprecated usages.
Comment 2 Jesse Glick 2002-10-24 22:01:12 UTC
Also: check for dupe entries in layers; nbresboot: and nbrescurr:
protocol uses.
Comment 3 rbalada 2002-10-25 15:49:41 UTC
Jesse, do you have some plan/timeframe for this issue?
Comment 4 Jan Chalupa 2002-10-25 16:07:56 UTC
I have the same question. Would be nice if we had this in place as a
general solution to the 200210230100 q-build "stoppers". However,
should the implementation take more than a week, we should probably
push the q-build with those few specific fixes done so far.

Jesse, what's your take on this?
Comment 5 Jesse Glick 2002-10-25 17:42:21 UTC
My take? Feels like a P4 enhancement to me. I'm not sure why any of
these deprecation messages were labelled "Q-build stoppers". The point
is that the functionality being used probably still works as before
but may be causing some undesirable effects and may produce
instability in the module, or sometimes just hurt performance or UI or
something - i.e. module owner should look at the warning when they get
a chance and evaluate for themselves how important it is. Much like
@deprecated in Javadoc or the stronger messages in C/C++ "lint".

I assumed that the continuous/production builds check for stack traces
and warning printlns are merely visual noise, an annoyance when
looking at other stuff. Surely alarm bells do not go off when NB/S1S
code compiles against deprecated APIs, but the build log faithfully
reports it, and Q-build reports do not. Did I miss something?

Implementation should be only a few hours, but I was working mostly on
#19443 and similar and was not planning to spend time on this for a
few days at least, since there are schedule dependencies on the other
stuff I am doing for the Projects team.

Also not sure that filing issues for every deprecation use (issue
#27926) is a good use of time. All developers should occasionally
watch the startup log when running routine test builds, and look for
things relating to them. We don't file issues for compilation against
deprecated APIs; developers are expected to notice once in a while
from the compiler warnings, and do something about it. In a few less
common cases it might really be urgent for something to be changed, in
which case filing issues is helpful.

BTW another warning to suppress: relative Class-Path entries (thanks
Jim Warhol for catching).
Comment 6 Jan Chalupa 2002-10-29 17:20:40 UTC
Ok, I understand it's not realistic to have this done for the 10/23
q-build. We'll promote it leaving some of the "stoppers" unresolved.
It would still be nice to have this enhancement implemented soon so
that the deprecation related warnings can be optionally supressed.
Comment 7 Jesse Glick 2002-10-30 16:22:19 UTC
Also ExecInfo, ModuleDescription stack traces.
Comment 8 Jesse Glick 2002-11-02 21:44:16 UTC
And InstanceDataObject warning re. use of [] in .instance names.
Comment 9 Jesse Glick 2002-11-03 16:25:08 UTC
Fixed. See nbbuild/build.properties; pass

-Dsanitystart.args.additional=-J-DErrorManager.minimum=17

to the Ant run which includes sanity-check if you want to suppress
these messages.

Core developers need only remember to use these idioms for showing
deprecations:

ErrorManager em = ErrorManager.getDefault();
if (em.isLoggable(ErrorManager.WARNING)) {
    em.log(ErrorManager.WARNING, "Warning: blah blah blah");
}
if (em.isNotifiable(ErrorManager.INFORMATIONAL)) {
    em.notify(ErrorManager.INFORMATIONAL, new Throwable("first use
called here"));
}

committed   * Up-To-Date  1.46        nbbuild/build.properties
committed   * Up-To-Date  1.5         openide/deprecated/manifest.mf
committed   * Up-To-Date  1.3        
openide/deprecated/src/org/openide/modules/ModuleDescription.java
committed   * Up-To-Date  1.3         openide/execution/manifest.mf
committed   * Up-To-Date  1.3        
openide/execution/src/org/openide/execution/ExecInfo.java
committed   * Up-To-Date  1.3        
openide/execution/src/org/openide/execution/NbResourceStreamHandler.java