This is actually a complicated question. If a user sets
JAVAC_MAX_WARNINGS=true globally, there are two things we can do:
We can listen to the user and exit with an error the moment one of these
files comes along (in this case, we know there will be [deprecation]
warnings), or we can ignore the user's request for the particular
makefile by resetting JAVAC_MAX_WARNINGS=false.
I went with the latter simply because it allows for a full build with
"make JAVAC_MAX_WARNINGS=true", which makes for easy bookkeeping.
-Sasha
On 8/17/2011 8:37 PM, Brad Wetmore wrote:
This is a little late, but catching up on a bunch of back email.
Why did you add:
+JAVAC_MAX_WARNINGS = false
in places like:
+JAVAC_MAX_WARNINGS=false
+JAVAC_LINT_OPTIONS=-Xlint:all,-deprecation
+JAVAC_WARNINGS_FATAL=true
The default is false (NOP) already:
jdk/make/common/shared/Defs-java.gmk
ifeq ($(JAVAC_MAX_WARNINGS), true)
JAVAC_LINT_OPTIONS += -Xlint:all
endif
Just seems like additional overhead for the maintainer to understand,
instead of just the two lines.
Brad
On 7/20/2011 10:28 AM, Alexandre Boulgakov wrote:
"JAVAC_MAX_WARNINGS = true" is the same as "JAVAC_LINT_OPTIONS =
-Xlint:all", so the only warnings being ignored are deprecation
warnings.
-Sasha
On 7/19/2011 8:10 PM, Xuelei Fan wrote:
About the makefile. In some makefiles, you added:
JAVAC_MAX_WARNINGS = false
JAVAC_LINT_OPTIONS = -Xlint:all,-deprecation
JAVAC_WARNINGS_FATAL = true
But some others, the more strict rules are applied:
JAVAC_MAX_WARNINGS = true
JAVAC_WARNINGS_FATAL = true
What's the underlying warnings that we cannot always use the following
options:
JAVAC_MAX_WARNINGS = true
JAVAC_WARNINGS_FATAL = true
Thanks,
Xuelei (Andrew)
On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote:
Hello Sean,
Have you had a chance to look at this webrev?
Thanks,
Sasha
On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote:
Hello,
Here's an updated webrev:
http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/
I've reexamined the @SuppressWarnings("unchecked") annotations, and
added comments to all of the ones I've added. I was was also able to
remove several of them by using covariant return types on
sun.security.x509.*Extension.get(String) inherited from Object
CertAttrSet<T>.get(String). I've also updated the consumers of
sun.security.x509.*Extension.get(String) to use the more specific
return type, removing several casts and
@SuppressWarnings("unchecked")
annotations.
Also, please take a closer look at my changes to
com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry,
final CodeSource) in
src/share/classes/com/sun/security/auth/PolicyFile.java lines
1088-1094. The preceding comment and the behavior of
Subject.getPrincipals(Class<T>) seem to be more consistent with the
updated version, but I wanted to make sure.
The classes where I added serialVersionUID's are either new or have
the same serialVersionUID as the original implementation.
Thanks,
Sasha
On 7/18/2011 5:33 PM, Brad Wetmore wrote:
(Apologies to folks without access to the older sources.)
On 07/18/11 15:00, Sean Mullan wrote:
On 7/18/11 5:35 PM, Alexandre Boulgakov wrote:
Is there an easy way to see when a class was added to the JDK?
For standard API classes, you can use the @since javadoc tag which
will indicate
the release it was first introduced in.
Standard, exported API classes. Some of the underlying support
classes for API packages like java.*.* weren't always @since'd
properly.
For internal classes, there is no easy way, since most don't
have an
@since tag.
I would probably write a script that checks the rt.jar of each of
the JREs that
are archived at /java/re/jdk. The pathnames should be fairly
consistent, just
the version number is different.
Don't know which classes you're talking about here, but some classes
started out in other jar files and eventually wound up in rt.jar.
Also, some files live in files other than rt.jar. I usually go to
the source when looking for something. If it's originally from
JSSE/JGSS/JCE, you'll need to look on our restricted access machine.
When I'm looking for something that is in the jdk/j2se workspaces, I
go right to the old Codemgr data, specifically the nametable file,
because many times the files you want may be in a src/<arch>/classes
instead of src/share/classes.
% grep -i SunMSCAPI.java
<RE-repository>/5.0/latest/ws/j2se/Codemgr_wsdata/nametable
% grep -i SunMSCAPI.java
<RE-repository>/6.0/latest/ws/j2se/Codemgr_wsdata/nametable
src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4
a217f6b0 6c833bd3 d4ef32be
That will usually give you a good starting point.
Brad
Depending on rt.jar or not.
Chris, do you have any other ideas?
--Sean
