We Keep Coding

type does not take parameters in generics

I have an interface that takes a generic argument:
package com.lbv.itf;
public interface Segment<T extends Object> {...}
and this was written couple of years back, compiled in 1.6 and built into a jar, say segment.jar
Now, I have a new project using segment.jar and in this new project, I have a class implementing this interface:
package com.lbv.impl;
import com.lbv.itf.Segment;
public class TreeSegment implements Segment<Tree> {...}
compiling this newer class in 1.7 gives this error:
type com.lbv.itf.Segment does not take parameters
It looks so obvious that Segment interface takes the parameter but somehow, that is not visible while compiling the newer class. Is this a known JDK compatibility issue or is there something I am missing? Any help will be of great help.
UPDATE:
It works only if I compile the newer code 1.6 :(. Is there a compatibility issue from 1.6 to 1.7 on generics type parameters?
I am using
Java 1.6 Update 45 64 bit
and
Java 1.7 Update 60 64 bit

This has happend because the legacy code was compiled with the option `
'target=jsr14'
` which stripped off the type parameters so that generated code will stay compatible with older java versions. Unfortunately, 1.7 has stopped supporting this flag resulting in the issue that caught me.

replace classes from sun.security.* packages

I'm trying to upgrade an app from JDK7 to JDK8 which uses the following classes from the sun.security.* packages
sun.security.x509.X509CertImpl
sun.security.pkcs11.SunPKCS11
sun.security.util.DerOutputStream
sun.security.util.DerValue
sun.security.util.ObjectIdentifier
sun.security.pkcs.PKCS10
sun.security.x509.X500Name
sun.security.pkcs11.SunPKCS11
sun.security.pkcs11.wrapper.CK_TOKEN_INFO
sun.security.pkcs.PKCS10
The usage of these classes generates warnings in all cases except for sun.security.pkcs.PKCS10 which causes a compilation error, because this class no longer exists. It seems that it has moved to a different package sun.security.pkcs10.PKCS10.
While I could simply changes this package name and ignore the warnings generated by the other sun.security classes, I understand that you're not supposed to use classes in sun.security packages. How do I go about replacing these classes with their equivalent from the JDK8 public API?

There aren't any equivalents in the JDK8 public API. You should switch to the BouncyCastle API instead.

Is rmic still needed?

Is it true that the rmi interface compiler is not needed for java 1.5 or newer and that just compiling the java file where the UnicastRemoteObject is defined with javac is enough?Rmic still works and it generates a stub class file if you give it the class file of the implementation of the remote object.

According to the RMI tutorial:
http://download.oracle.com/javase/tutorial/rmi/overview.html
Compiling Sources
As with any Java program, you use the
javac compiler to compile the source
files. The source files contain the
declarations of the remote interfaces,
their implementations, any other
server classes, and the client
classes. Note: With versions prior to
Java Platform, Standard Edition 5.0,
an additional step was required to
build stub classes, by using the rmic
compiler. However, this step is no
longer necessary.

See the preamble to the Javadoc for UnicastRemoteObiect. You can avoid using rmic under specific circumstances, i.e. when you construct or export the remote object providing a port number parameter (even zero), for reasons described in the documentation.

#Override for interface methods causes JSP compilation to fail

For some reason, putting #Override on methods overriding interface methods causes JSP compilation to fail in weblogic. Everything is definitely running off of JDK 1.6.0_14, but this Java 5'ism still persists.
Oddly, JSP compilation occasionally fails with a stacktrace pointing at code not necessarily obviously used by the JSP itself.
What's going on here?

The #Override is supposed to only be retained in source so shouldn't come up in byte code. There might an angle you can play in ensuring those classes are complied separately from the JSPs and simply available in the classpath -- rather than the source path.
If that's already the case then it might be a different issue than what is immediately showing.
Used to be the JSP complier was a separate library shipped with the server and not tied to the vm the server is running in. WLS used to use Javelin. Seems like they switched that in 10 to use the Java Compiler API. So it should work fine as long as you have Sun vm Java 1.6. But if there's 'javelin' anything in your stacktrace, definitely check that angle.

I've seen this a lot myself. In Java 6, it is (supposedly) permissible to use #Override on interface implementation methods. In Java 5, this is an error. However in my Java 6 code, sometimes #Override is accepted on interface implementation methods, and sometimes it is not.
To make things weirder, some IDEs (e.g. NetBeans) are fine with it, while IntelliJ IDEA is sometimes ok and sometimes not. I have found, however, that compiling the code in either IDE will ignore the alleged errors being reported by the IDE.
In other words, is the problem manifesting in your IDE? If so, compile the code directly (use the command-line if necessary) and see what happens. The IDE may be reporting spurious errors.

A possible workaround might be to precompile JSP using appc. This could at least allow to circumvent the issue.
Regarding the "real" question, my understanding is that you did upgrade domains, so maybe have a look at the following resources:
Web Applications, JSPs, and Servlets
Backwards Compatibility Flags
Procedure for Upgrading a WebLogic Domain
Select Upgrade Options (related to domain upgrade)
Backward Compatibility Flags
JSPCompilerBackwardsCompatible - Specifies whether to allow JSPs that do not comply with the JSP 2.0 specification
This is a wild guess but maybe some backward compatibility flag is activated and WebLogic keeps using the "old" approach.

I agree with your instinct and the other answers that WLS is using Java 5 somehere. The items below seem like useful tidbits from Oracle/WebLogic resources. I don't have a WebLogic Server 10.3 installation to confirm these:
Weblogic Server 10.3
According to this, at least Weblogic Server 10.3 is required to use Java 6, but I can't see anything the confirms this as authoritative info:
http://forums.oracle.com/forums/thread.jspa?threadID=884263
Re: WebLogic 10.0 supports Java 6?
Posted: Apr 9, 2009 12:26 PM in response to: user8324142
Hi,
Weblogic 10 will not support JDK6.
Please upgrade to Weblogic 10.3 to work with JDK 6.
Checking the Java version
http://download.oracle.com/docs/cd/E12840_01/common/docs103/install/postins.html#wp1090736
Determining Which JDK Version You Are Using
You can determine which version of the JDK you are using by issuing a command, as follows:
Open a command prompt window and go to the appropriate directory:
BEA_HOME\WL_HOME\server\bin (Windows)
BEA_HOME/WL_HOME/server/bin (UNIX)
In both pathnames, BEA_HOME represents the directory in which you have installed your software and WL_HOME represents the wlserver_< version >.
Make sure that your environment is set up properly by entering the following command at the prompt:
setWLSenv.cmd (Windows)
setWLSenv.sh (UNIX)
Enter the following command at the prompt:
java -version
Configuring Java version:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/WLSTuning.html
Setting Java Parameters for Starting WebLogic Server
... Java parameters must be specified whenever you start WebLogic Server. ... Oracle recommends that you incorporate the command into a [startup] script ...
If you used the Configuration Wizard to create your domain, the WebLogic startup scripts are located in the domain-name directory where you specified your domain. By default, this directory is BEA_HOME\user_projects\domain\domain-name, where BEA_HOME is the directory that contains the product installation, and domain-name is the name of the domain directory defined by the selected configuration template. ...
Change the value of the variable JAVA_HOME to the location of your JDK. For example:
set JAVA_HOME=C:\bea\jdk150_03
...

In my mind, #Override makes sense on methods that are overriding methods, not implementing methods.
So if you have an interface:
public interface MyInterface {
public void doSomething();
}
A class that implements that interface is below (MyClassA):
public MyClassA implements MyInterface {
public void doSomething() {
System.out.println("This is from MyClassA");
}
}
Then, the below class extends MyClassA and overrides doSomething, and so then I'd add the #Override annotation.
public MyClassB extends MyClassA implements MyInterface {
#Override
public void doSomething() {
System.out.println("This is from MyClassB");
}
}
I wouldn't do the below (whether or not it is permissable) in any case, since it breaks the idea about overriding something - you're implementing, not overriding the interface:
public MyClassA implements MyInterface {
#Override
public void doSomething() {
System.out.println("This is from MyClassA");
}
}

Why is javac failing on #Override annotation

Eclipse is adding #Override annotations when I implement methods of an interface. Eclipse seems to have no problem with this. And our automated build process from Cruise Control seems to have no problem with this. But when I build from the command-line, with ant running javac, I get this error:
[javac] C:\path\project\src\com\us\MyClass.java:70: method does not override a method from its superclass
[javac] #Override
[javac] ^
[javac] 1 error
Eclipse is running under Java 1.6. Cruise Control is running Java 1.5. My ant build fails regardless of which version of Java I use.

The #Override annotation spec changed in Java 1.6. In Java 1.5, the compiler did not allow the #Override annotation on implemented interface methods, but in 1.6 it does. First search result I found is a blog post here.. It was not well documented, but it did change.
Eclipse is adding it because your Eclipse is set for 1.6 compliance. You should try to keep your build and eclipse environments on the same version of Java. It's unclear to me by your specifying Cruise Control is running Java 5 on whether or not it is compiling using a separate JDK6 or not.
Separate from the above 1.5 vs 1.6 #Override annotation rules, remember that Eclipse has its own compiler implementation (not javac) and will occasionally have different behavior. Whenever something compiles in Eclipse, but not Ant or Maven, you will need to find a way to make both compilers happy.

I can't really explain the problem you're seeing but it seems to be related to the fact that JDK 5 will not allow #Override on implemented methods of an interface, only on overridden methods present in a super class.
JDK 6 will allow #Override on any of them.
If your ant build fails it may be passing a source parameter to javac, asking for JDK 5 compliance.

The direct answer to the question "Why" an error is raised by javac when #Override is used in the context of a method implementation is actually in the java specifications:
"The rationale for this is that a concrete class that implements an interface will necessarily override all the interface's methods irrespective of the #Override annotation, and so it would be confusing to have the semantics of this annotation interact with the rules for implementing interfaces."
See http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6.1.4
But apparently someone changed his mind for java 1.6 and 1.5 u21...

#Override tags for implemented methods are new to Java 1.6. In Java 1.5 #Override is only correct when overriding a method in a base class. Read more here and here.

A lot of people, including me, got busted by this. See here for a bigger SO discussion

Eclipse would be pointing to 1.6 version of Java rather than 1.5.
See here for configuring java version in eclipse.

Ensure that there is only one definition of that interface.
Example:
HttpServletRequest
This is an interface with different specs depending on provider.
Compare pax-web-jetty and apache-felix-jetty. They have different methods.

I have had the same problem when building a project with ANT. The solution to the problem was to change the following property inside the build.properties file:
javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
to:
javac.compiler=modern
That solved the problem and the project got compiled and deployed successfully.