BUG in WLE IDL compiler

Hi,
I want to report a bug in the WLE5.0 IDL compiler. It occurs in the
generated stub, skeleton and implementation files (*c,*s and _i)
files. Here is a description of the problem:
Say we have the following IDL:
Filename:filewithmoduleM1.idl
module M1 {
#include "BoundaryClasses\CORBA\Types\M1Complex.idl"
interfaceService {
boolean method1 (
interface Factory {
Service findService ();
The IDL compiler loses track of the Module M1 and does not scope the
interfaces inside the module. Henck even if we register a factory called
APSBalReporting::Factory it is registered as Factory. The problem gets
more interesting if we have another module that includes the first as
shown below:
Filename:filewithmoduleM2.idl
#include filewithmoduleM1.idl
module M2 {
#include "BoundaryClasses\CORBA\Types\M1Complex.idl"
interface Service {
boolean method2 (
interface Factory {
Service findService ();
Here it thinks that Service and Factory are the ones for module M1 and
so generates the return type as M1::Factory and M1::Service instead of
M2::Factory and M2::Service.
The IDL compiler used to work fine with code such as the above
previously.
Please let me know if you have any feedback for this bug and if any of
you have tried it.
Thanks,
Raman Ramesh
678-358-3581
mailto:[email protected]
www.cicube.com

BEA customers who need this problem corrected must use WLE 5.1. A patch to WLE 5.0
or WLE 5.0.1 is not available.
Wendell MacKenzie wrote:
We received a patch that fixed this problem under WLE 5.01. There were problems
back porting the fix into the 5.0 release. Talk to Tom Hegadorn.
Mary Ann Slavin wrote:
Actually that is Clarify CASE 162819 not a Clarify CR number. That particular
problem has been corrected in WLE 5.1. This problem cannot be patched in WLE
5.0.1, so if you have encountered this problem, you should upgrade to WLE 5.1
and it is corrected as part of the base product, no patch required.
MAS
Wendell MacKenzie wrote:
You have 2 choices:
- upgrade to Version 5.1 (which includes CR162819)
- obtain the patch from BEA support for CR162819 to fix a bug in the IDL
compiler
that caused Module and Interface scope names to work incorrectly. Also,
where
nesting of IDL #includes exceeded 1 level deep, this caused problems.
You will have to install the patch onto version 5.01.
Regards,
Wendell MacKenzie
Ram Ramesh wrote:
Hi,
I want to report a bug in the WLE5.0 IDL compiler. It occurs in the
generated stub, skeleton and implementation files (*c,*s and _i)
files. Here is a description of the problem:
Say we have the following IDL:
Filename:filewithmoduleM1.idl
module M1 {
#include "BoundaryClasses\CORBA\Types\M1Complex.idl"
interfaceService {
boolean method1 (
interface Factory {
Service findService ();
The IDL compiler loses track of the Module M1 and does not scope the
interfaces inside the module. Henck even if we register a factory called
APSBalReporting::Factory it is registered as Factory. The problem gets
more interesting if we have another module that includes the first as
shown below:
Filename:filewithmoduleM2.idl
#include filewithmoduleM1.idl
module M2 {
#include "BoundaryClasses\CORBA\Types\M1Complex.idl"
interface Service {
boolean method2 (
interface Factory {
Service findService ();
Here it thinks that Service and Factory are the ones for module M1 and
so generates the return type as M1::Factory and M1::Service instead of
M2::Factory and M2::Service.
The IDL compiler used to work fine with code such as the above
previously.
Please let me know if you have any feedback for this bug and if any of
you have tried it.
Thanks,
Raman Ramesh
678-358-3581
mailto:[email protected]
www.cicube.com

Similar Messages

Bug in the JIT compiler?

Hi All,
I don't know if I have found a bug in the JIT compiler.
uname -a : Linux kiloo-server2 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux
java -version:
java version "1.6.0_12";
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
all in our server module runs fine, until we try to rescale/transform an Image from a rss feed. after this a CompilerThread0 is started and never stops.
it just keeps running at 100% on core0
so right now we are running our server module with the -Xint option.. this is of course not an ideal solution.
Before we moved the server module to linux, it was running on a windows machine (the same code), and there was no JIT compilerthreads problems.
Is there anybody who has experienced anything like this, and is there a workaround to it?
BR
Kristian

Kristian_Iversen wrote:
Hi All,
I don't know if I have found a bug in the JIT compiler.To start with you would need to reduce the code from your "server module" to a very small piece of code that demonstrates the problem.

IDL compiler crashes when......

Hi,
I've found that the IDL compiler crashes when trying to compile an idl that contains
a declaration similar to the following:
struct S {
union U switch(long) {
case 1:
long a;
case 2:
short b;
} y;
The crash occurs with both NT and Solaris 8 versions of Tuxedo 8.0's $TUXDIR/bin/idl
that I've tried.
Any ideas?
Thanks,
Dave.

Dave,
Looks strange... I suggest that you open a case with BEA support.
Regards,
Peter.
David Watson wrote:
Hi,
I've found that the IDL compiler crashes when trying to compile an idl that contains
a declaration similar to the following:
struct S {
union U switch(long) {
case 1:
long a;
case 2:
short b;
} y;
The crash occurs with both NT and Solaris 8 versions of Tuxedo 8.0's $TUXDIR/bin/idl
that I've tried.
Any ideas?
Thanks,
Dave.

Bug while editing and compiling the procedure

Bug while editing and compiling the procedure in Sql Developer 1.5.4
the error is
ora -00904 "ATTRIBUTE" Invalid Identifier
Edited by: user4448643 on Mar 16, 2009 5:09 AM

I'm not trying to be snippy but this is the answer I got from you in another thread about the same issue:
+"I'm not sure I said it's being worked on - the bug is logged and in the queue.+
+Support will tell you to move to a supported version of the database, this is true. The same is true for the forum, if you are on an unsupported database version you're encouraged to move to a supported release.+
+If you need to work with 9i, then use SQL Developer 1.5.3, the error is not in that release."+
When I read that I got that I should not assume the bug was being worked on and that the SQL Developer team sees 9i as having a short remaining life.
JB

Orbix idl compiler errors

Environment:
Orbix 3.01 (with 2 patches...)
Weblogic 5.1
Jdk1.3
NT sp 6
I ran ejbc -idl to generate the interfaces for a simple bean. Boy did
it generate a bunch of files.
When I run the Orbix idl command I get the following:
C:\projects\idl\com\xelus\soa\ping>idl -Ic:\projects\idl Ping.idl
IDL Compiler: Ping.idl
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
20: Warning : identifier Exception clashes with keyword
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
I am guessing that the BEA product supports a more recent version of the
IDL spec than that in the Orbix product.
Are there flags that I can add the to ejbc command to make the idl more
friendly to the Orbix idl compiler? Is there a minimum Orbix revision
that I have to be at to work with the idl generated by ejbc -idl?
I also did this with a simple rmi interface as well and found similar
errors though many fewer idl files!
thanks for any help,
don.

I have sp3 installed and the flag was not recognized by ejbc. Do I have to wait for 5.1.1?
thanks,
don.
Eduardo Ceballos wrote:
Try -idlNoValueTypes... this is an experimental option. Should work, provided your Remote interface reduces reasonably (usably) without value types.
Don Schaefer wrote:
Environment:
Orbix 3.01 (with 2 patches...)
Weblogic 5.1
Jdk1.3
NT sp 6
I ran ejbc -idl to generate the interfaces for a simple bean. Boy did
it generate a bunch of files.
When I run the Orbix idl command I get the following:
C:\projects\idl\com\xelus\soa\ping>idl -Ic:\projects\idl Ping.idl
IDL Compiler: Ping.idl
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
20: Warning : identifier Exception clashes with keyword
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
Pragma ID: bad format ID ( must be of type IDL, DCE or LOCAL format ).
I am guessing that the BEA product supports a more recent version of the
IDL spec than that in the Orbix product.
Are there flags that I can add the to ejbc command to make the idl more
friendly to the Orbix idl compiler? Is there a minimum Orbix revision
that I have to be at to work with the idl generated by ejbc -idl?
I also did this with a simple rmi interface as well and found similar
errors though many fewer idl files!
thanks for any help,
don.

Bug in Oracle Java Compiler???

Hello!
I think I found a bug in OJC. Take a look in these files:
------ File MyInterface1.java -------
public interface MyInterface1
public void aMethod1();
public void aMethod2();
------ File MyInterface2.java -------
public interface MyInterface2 extends MyInterface1
public void aMethod1(String s1);
public void aMethod2(String s2);
------ File MyAbstractClass.java -------
abstract public class MyAbstractClass implements MyInterface2
public void aMethod1()
------ File MyImplClass.java -------
public class MyImplClass extends MyAbstractClass
public void aMethod2()
public void aMethod1(String s)
When compiling these files, the following error should be found:
"javac MyImplClass.java
MyImplClass.java:1: MyImplClass should be declared abstract; it does not define
aMethod2(java.lang.String) in MyAbstractClass
public class MyImplClass extends MyAbstractClass
^
1 error"
This is the error found by javac (J2SE 1.3), as expected.
But when I compile using OJC 9.0.2.579 (JDeveloper 9.0.2.829) no error is found, and the compiler generates MyImplClass.class. This should not happen!!!
Even if I implement aMethod2(String s) in MyImplClass, how can I trust that OJC is generating the bytecode, so that the method invocation is occuring correctly during runtime?
I have a component library based on class hierarchy like the one in the example, and I would not like to modify it because of this possible bug in OJC.
Thanks
Gleber/Daniel/Augusto

Gleber,
As per current plans the 903 release is expected to be on OTN in the next 5-7 weeks. Feel free to ping me at [email protected] if this bug is preventing you from moving forward. I'll try to resolve your issue with a workaround.
Regards,
Arun

Bug in spec or compiler?

Hello!
I have some problems with the jsr14 specification and the compiler implementation. I am not a native english speaker, but I think I can understand the specification correctly.
In the spec8.pdf document "Adding Generics to the Java Programming Language - Participant Draft Specification" on page 16 example 20: this should not compile but it does compile with jsr14 prototype 1.2 (javac 1.4.0_01)! Why? Anyone tried this?
In the same spec page 14: 6.1: "the erasure of a type variable is [...] if the bound consists of interface tyes only, the interface among the erasures of all interface types which has the least canonical name, using lexicographic ordering."
This sounds crazy, and the compiler does it different. It always uses the first parameter (following extends)! You can see this using "javap -c" on the bytecode. So, what�s right?
In the spec, page 3: "if a type parameter X has more than one bound, then it is a compiletime error to reference a member of an object whose declared type is X, unless that member is an accessible member of class java.lang.object"
Well, why is this an error? It compiles without any errors!
And another point: in the spec are examples of type variables with the "A implements I" syntax, which is not allowed. The compiler uses "extends" only. The example code is even on the same page (Page 3). Oh, oh!
Maybe I am wrong in some parts, and you can help me. (I cant believe, that I found three bugs in five hours) Any comments?

There were no answers to my questions, yet. Here is some sample code to show my problems:
In the spec8.pdf document "Adding Generics to the Java
Programming Language - Participant Draft
Specification" on page 16 example 20: this should not
compile but it does compile with jsr14 prototype 1.2
(javac 1.4.0_01)! Why? Anyone tried this?Here is the code:
class C<A> { A id (A x) {} }
interface I<A> { A id(A x); }
// should not compile, but does compile!
public class D extends C<String> implements I<Integer> {
String id(String x) {}
Integer id(Integer x) {}
In the same spec page 14: 6.1: "the erasure of a type
variable is [...] if the bound consists of interface
tyes only, the interface among the erasures of all
interface types which has the least canonical name,
using lexicographic ordering."
This sounds crazy, and the compiler does it different.
It always uses the first parameter (following
extends)! You can see this using "javap -c" on the
bytecode. So, what�s right?Here is the code:
interface IA{ public void testA(); }
interface IB{ public void testB(); }
interface IC{ public void testC(); }
public class Test<A extends IB & IA & IC>{
public A value; // javap tells me, that value has type IB!
In the spec, page 3: "if a type parameter X has more
than one bound, then it is a compiletime error to
reference a member of an object whose declared type is
X, unless that member is an accessible member of class
java.lang.object"
Well, why is this an error? It compiles without any
errors!Here is the code:
public class Test2<A extends IA & IB & IC>{
private A value;
public static void main(String[] args){
value.testA(); // where is the problem
value.testB(); // it works!
And another point: in the spec are examples of type
variables with the "A implements I" syntax, which is
not allowed. The compiler uses "extends" only. The
example code is even on the same page (Page 3). Oh,
oh!Here is the code:
class ReprChange<A implements ConvertibleTo<B>,
B implements ConvertibleTo<A>> {....
Maybe I am wrong in some parts, and you can help me.
(I cant believe, that I found three bugs in five
hours) Any comments?Again: is anyone here who can tell me what is right?

Ridiculous bug in oracle jdeveloper compiler ojc with jdk1.4

With simple class:
public class Test
public Test()
public String toString()
return null;
public static void main(String[] args) throws Exception
Test test = new Test();
System.out.println("ooo" + test);
After compile it with ojc (ojc Test.java) and run it with jdk 1.4.1_01 (java Test), it throws
java.lang.NullPointerException
at java.lang.String.concat(String.java:1541)
But it works ok if compile it with standard java compiler(javac).

Hi,
Thanks for reporting this. It's a bug. I've logged it as 2809860, and you can track this on metalink.oracle.com.
Brian
JDev Team

9.0.3 "Bug" report regarding paths, compiling, and running

I don't know if this is a bug or some kind of strange feature but it caused me to lose about an hour and a half of work before I figured out what was going on.
BACKGROUND:
I have a project UVDebug.jpr. It's full pathname is :
C:\My Documents\OracleJDev\Visia\UVDebug\UVDebug.jpr
Now this project has one file in it: UVDebug.java, however, this java source code file doesn't live in a subfolder of the folder containing the project. Shouldn't be a problem. It's path is
C:\My Documents\OracleJDev\Visia\VisiaProject\src\debug\visia\UVDebug.java
As far as I know now, the files you add to a project can live anywhere.
The output path (where the class files get created/saved) IS a subfolder of the project folder. It's path is
C:\My Documents\OracleJDev\Visia\UVDebug\classes
THIS WORKS:
If I FIRST click the rebuild project button, the class gets created in the correct folder:
C:\My Documents\OracleJDev\Visia\UVDebug\classes\debug\visia\UVDebug.class
If I then click the red bug button to run the project in debug mode, it works fine.
THIS DOES NOT WORK, BUT IT SHOULD:
If I DO NOT first click the rebuild project button, but instead, just go directly to clicking the red bug button to run it, then it is supposed to compile the source into a class and then run the class. However, the class does not get created and when it goes to run, it throws a class not found exception.
If the source code UVDebug.java DOES live in a sub folder of the folder containing the project, then clicking the red bug button WILL compile it and run it. I.e. the source code lives in
C:\My Documents\OracleJDev\Visia\UVDebug instead of
C:\My Documents\OracleJDev\Visia\VisiaProject\src\debug\visia
However if the source code does not live in a subfolder of the folder containing the project, you must first compile the project as a separate step before you click the red bug button to run it.
I don't know why the situation that didn't work didn't work -- it should have worked as far as I understand. Am I wrong here? Do all source code files and output class files have to be in subfolders of the project if you want to click only red bug instead of rebuild all and red bug?
Mark Hayworth
Cincinnati Ohio

I really don't know exactly what happened as what you have described should all work.
Try those following steps:
- Completely clean out your output path
including any .cdi files you might have
at the root of your output path
- Go back in jdev and make sure the runner
option is to make the application before
running
- Run (and/or) debug and it should work, does it?
Michel

Reporting a bug for the C++ compiler

How do I report a bug to Oracle regarding the C++ compiler ? I am using Solaris Studio 12.3.

Here is an alternative implementation, as a file called has_xxx_test_ex.cpp, also supported by the mpl and tti code for introspecting a class/struct for a class template of a given name taking typename ( or class ) type parameters:
struct stype { template< typename T > struct xxx {}; };
typedef void boost_mpl_has_xxx_has_xxx_template_substitute0_tag ;
template < template < typename U0 > class U >
struct boost_mpl_has_xxx_has_xxx_template_substitute0
    typedef boost_mpl_has_xxx_has_xxx_template_substitute0_tag type ;
template < template < typename U0 , typename U1 > class U >
struct boost_mpl_has_xxx_has_xxx_template_substitute1
    typedef boost_mpl_has_xxx_has_xxx_template_substitute0_tag type ;
template < typename T >
class has_xxx_template
    template < typename U , typename V = boost_mpl_has_xxx_has_xxx_template_substitute0_tag >
    struct has_xxx_template_test
        static const bool value = false ;
    template < typename U >
    struct has_xxx_template_test <     U ,
                                    typename boost_mpl_has_xxx_has_xxx_template_substitute0
                                        < typename U :: xxx < > > :: type
                                 >
        static const bool value = true ;
    template < typename U >
    struct has_xxx_template_test <    U ,
                                    typename boost_mpl_has_xxx_has_xxx_template_substitute1
                                        < typename U :: xxx < > > :: type
                                 >
        static const bool value = true ;
    template < typename U >
    struct has_xxx_template_introspect : has_xxx_template_test < U > { } ;
    public :
        static const bool value = has_xxx_template_introspect < T > :: value ;
int main()
    has_xxx_template<stype> aclass;
    return 0;
When this is compiled with the C++ compiler of 12.3 with this command line:
CC +d -library=stlport4 -features=tmplife -features=tmplrefstatic -g -erroff=%none -KPIC -c -o "has_xxx_test_ex2.o" "has_xxx_test_ex2.cpp"
the result is:
"has_xxx_test_ex2.cpp", line 30: Warning (Anachronism): Using xxx as a template without a declaration.
"has_xxx_test_ex2.cpp", line 54:     Where: While specializing "has_xxx_template<stype>".
"has_xxx_test_ex2.cpp", line 54:     Where: Specialized in non-template code.
"has_xxx_test_ex2.cpp", line 30: Error: Template template-parameter U<U0> requires a class template argument.
"has_xxx_test_ex2.cpp", line 54:     Where: While specializing "has_xxx_template<stype>".
"has_xxx_test_ex2.cpp", line 54:     Where: Specialized in non-template code.
"has_xxx_test_ex2.cpp", line 39: Warning (Anachronism): Using xxx as a template without a declaration.
"has_xxx_test_ex2.cpp", line 54:     Where: While specializing "has_xxx_template<stype>".
"has_xxx_test_ex2.cpp", line 54:     Where: Specialized in non-template code.
"has_xxx_test_ex2.cpp", line 39: Error: Template template-parameter U<U0, U1> requires a class template argument.
"has_xxx_test_ex2.cpp", line 54:     Where: While specializing "has_xxx_template<stype>".
"has_xxx_test_ex2.cpp", line 54:     Where: Specialized in non-template code.
"has_xxx_test_ex2.cpp", line 36: Error: Multiple declaration for has_xxx_template<stype>::has_xxx_template_test.
"has_xxx_test_ex2.cpp", line 54:     Where: While specializing "has_xxx_template<stype>".
"has_xxx_test_ex2.cpp", line 54:     Where: Specialized in non-template code.
3 Error(s) and 2 Warning(s) detected.

Visibroker - java - IDL Compilation

Hi;
I am using the trial version of Visibroker 5.2.1 to develop a CORBA 2.4 compliant client Application.
After compiling the IDL File using idl2java command, I tried to compile
the stub java files using javac *.java command. It throws lot of errors.
The main error is:
"can not resolve the symbol class MethodPointer"
"package portable"
"new org.omg.CORBA.portable.MethodPointer"
I had put three .jar file namely lm.jar,vbsec.jar,vbjorb.jar in the classpath and I am running the machine in Windows 2000 Machine.
Can anyboby kindly answer what could be the possible reason ???
Thanks.

You have to use "idl to java" compiler bundled with Visibroker instead of JDK one.

Bug in Netbeans Java compiler?

I think Netbeans (or Java itself?) has a major flaw in its compiler design.
Explain to me why the following code is not compilable. Specifically, why it should complain about line 8:
cannot find symbol
symbol : variable Selected
When I clearly declared it a couple lines above it!
Now the fact that it was declared in an "If" clause is a lame excuse, because there is an unconditional Else clause which ALSO declares the same Object array. So either way, the Object array gets declared exactly ONCE. Not zero, not twice. In
EVERY SINGLE LOGICAL CASE.
So why was someone on crack when they designed Java/Netbeans? This is a BS error.
1     if (president.compareTo("Bush") == 0) {
2           Object Selected[] = listWarCriminals.getSelectedValues();
3       }
4       else {
5           Object Selected[] = listPresidents.getSelectedValues();
6       }
7
8       for (int n=0; n<Selected.length; n++) {
9           name = Selected[n].toString();
10          JOptionPane.showMessageDialog(frame, name, "Result", JOptionPane.INFORMATION_MESSAGE);
11      }

Please don't
[url=http://forum.java.sun.com/thread.jspa?threadID=51
76269&messageID=9681394#9681394]crosspost!Although for a topic this stupid it can't be bad to share the love.

Bug in Fortran-95 compiler (Linux-x86, compiler 8.3, dated 2009/03/06)

The following test code is incorrectly flagged as being in error:
module confuse
implicit none
interface submod
     module procedure suba
     module procedure subb
end interface
contains
subroutine suba(nz,info,n)
    integer, intent (in) :: nz
    integer, intent (out) :: info
    integer, optional, intent (in) :: n
    info = 0
end subroutine suba
subroutine subb(n,nz,info,m)
    integer, intent (in) :: n, nz,m
    integer, intent (out) :: info
    integer :: nzz
    info = 0
    nzz = 0
    call suba(nzz,info,n = n)
end subroutine subb
end module confuse
module deps
use confuse
contains
subroutine prolng(ierr)
integer, intent(inout) :: ierr
integer :: cnvtx=2
integer :: nz=0
integer :: info
ierr=0
call submod(nz,info,n=cnvtx)
if(info.ne.0)ierr=1
return
end subroutine prolng
end module depsThe error message is
"ambig.f90", Line = 35, Column = 25: ERROR: More than one actual argument has been specified for a dummy argument.
The message goes away if the keyword argument name is changed from 'n' to something else, such as 'ni'.

About a month ago, I reported this bug to Sun through the prescribed bug report Web interface, and received an automated reply announcing internal review ID of 1464791. However, there was no follow-up E-mail acknowledging the recognition of the bug and a bug number.
Sorry, I do not have a paid support subscription.

Java to idl compiler

Hi,
Can somebody tell me the link for javatoidl compiler? I have tried the following (I missed the complete URL) but its not there.
developer earlyAccess jdk12 idltojava.html
Zulfi.

Langauge might be a barrier Language is not the problem. The problem is your attitude.
for me but I fully
understand your aims and obj. And u will never achieve
your goal. My relationship is serialized with Java. If
u are against any community member , u are indirectly
rather actually against the binding force i.e java.Blah blah blah. What a bunch of nonsense. I'm against people who are so incompetent or lazy that they need and expect the forum members to do everything for them. Simple as that. This is not frickin' Lord of the Rings here dude.
Your unholy activities will never oust me from this
forum and I will continue exploring, practicing and
spreading the message of java.It's Java. It's just software. It's not a religion. Get over yourself.
However it will surely
annoy u and belittle u so much that u wont be able to
intrigue against any other community member. And that
would be your greatest defeat.Um, sure, whatever.
(Rolls eyes so hard he can see his own brain.)
Thats the end of this chapter.Doubtful.

[Bug] Compiler bug in JDev 10.1.3.0.4 (SU5)

Hello,
I would like to report a bug with Java 5 compiler in JDev 10.1.3.0.4 (SU5) build JDEV_ADF_10.1.3_NT_030125.0900.3673 regarding covariant return types.
As of Java 5, it's now possible to override a method with a different return type as long as the new return type is a subclass of the overridden method's return type. JDeveloper compiler will manage that correctly (no compilation error), but will result in a java.lang.AbstractMethodError if the overriding definition come from an interface.
So the reproduction case is :
public interface Interface1 {
public Object myMethod();
public interface Interface2 extends Interface1 {
public String myMethod();
public abstract class AbstractInterface2 implements Interface2 {
public class MyClass extends AbstractInterface2 {
public String myMethod() {
return "Hello"!;
public static void main(String... args) {
Interface1 myObject = new MyClass();
myObject.myMethod();
}I did not test with other JDev version.
Regards,
Simon Lessard

quick workaround is to set project output directory to the WEB-INF/classes directory and compile the jsp from jdeveloper, oc4j then updates the loaded class file without re-compiling the jsp.
This works fine, but if I let OC4J try to compile the JSP problem still occurs, anyone have any ideas why either of these problems occur?

BUG in WLE IDL compiler

Similar Messages

Maybe you are looking for