Community
Participate
Working Groups
Hi I am building a Cobol compiler that generates native JVM classes. For the purpose of interlanguage communication, there is a need for a Java classe to be able to call a Cobol class and that a Cobol classes be able to call a Java class. Currently, JDT is considering a IcompilationUnit as an association between a JVM ".class" and a Java ".java" file. In other term, valid and well formed JVM classes put in the JVM classpath are not recognized by JDT (when compiling Java class that reference such non Java class) if they do not have a corresponding Java source file. My request is to relax the specification of a JVM class by removing the unecessary association of a JVM class with its correcponding Java file. Or may be a better way to solve this point, to add a customisation of the file associations betwwen a suffix like ".cob" and the JVM ".class". It would be conceavable then to have a Adda compiler, a Fortran compiler, a C compiler...all of them generating JVM classes and supporting interlanguage communication with Java classes. Regards PS: As an example of such intercommunication language call, I have build a CobUnit Framework based on JUnit...Each Cobol unit test case extends the TestCase class of the JUnit FrameWork...that's fine...But for puttinh the collection of all CobUnit testcases, I do not need to have a CObUnit TestSuite. The JUNit TestSuite is already there but I cannot use it as the CobUnit classes are not recognized by JDT.
You can use the generated .class files from your Cobol environment inside a class folder. They could then be "visible" inside normal Java source code.
Hi Olivier It does not seem to work as follow: 1/ List of the "bin" Directory part of the classpath. BASIC_ZONED_DECIMAL.class existsn but there is no "ALL.class", the TestSuite java class that instanciates the Cobol class. D:\Eclipse\2.1.2\eclipse\workspace\cob.unit.cmp\bin>dir Le volume dans le lecteur D s'appelle WD1 Le numéro de série du volume est F814-2CD5 Répertoire de D:\Eclipse\2.1.2\eclipse\workspace\cob.unit.cmp\bin 05/02/2004 17:59 <REP> . 05/02/2004 17:59 <REP> .. 05/02/2004 18:00 476 ALL.class 05/02/2004 17:59 <REP> BASIC_ZONED_DECIMAL 05/02/2004 17:59 26 738 BASIC_ZONED_DECIMAL.class 05/02/2004 17:36 309 Pippo.class 3 fichier(s) 27 523 octets 3 Rép(s) 22 445 006 848 octets libres D:\Eclipse\2.1.2\eclipse\workspace\cob.unit.cmp\bin> 2/ The TestSuite ALL java source. public class ALL { public static Test suite() { TestSuite suite = new TestSuite("Test for Cobol Data Type"); //$JUnit-BEGIN$ suite.addTest(new TestSuite(BASIC_ZONED_DECIMAL.class)); //$JUnit-END$ return suite; } } You can reproduce the same abnormal behavior with JUnit itself (unrecognized JVM class file when the java source is not available). See bug #49452 Regards
Hi again Olivier I made a mistake in my previous comment. In fact, the ADD class is generated as show in the directory list, but the JUNit execution of ALL.class gives the following result: Failed to invoke suite(): java.lang.Error: Unresolved compilation problem: BASIC_ZONED_DECIMAL cannot be resolved or is not a type Regards
Hi Following is the trace of the execution of the Java class ALL from a WXP console with the Sun JDK 1.4.1_02. As it is working fine within this context (compilation and execution of ALL.java as listed in the comment#2), I change the Severity from "enhancement" to "major". D:\Eclipse\2.1.2\eclipse\workspace\cob.unit.cmp>java -verbose -cp %CP% junit.te xtui.TestRunner ALL [Opened D:\j2sdk1.4.1_02\jre\lib\rt.jar] [Opened D:\j2sdk1.4.1_02\jre\lib\sunrsasign.jar] [Opened D:\j2sdk1.4.1_02\jre\lib\jsse.jar] [Opened D:\j2sdk1.4.1_02\jre\lib\jce.jar] [Opened D:\j2sdk1.4.1_02\jre\lib\charsets.jar] ... [Loaded java.lang.NoSuchMethodException from D:\j2sdk1.4.1_02\jre\lib\rt.jar] [Loaded junit.framework.Assert] [Loaded junit.framework.TestCase] [Loaded com.pac.cob.rts.CobolCase] [Loaded com.pac.cob.rts.CobolProgram] [Loaded BASIC_ZONED_DECIMAL] [Loaded junit.framework.ComparisonFailure] Regards
Hi After some discussions about this problem, we decided to push it as critical since most of our user cases are a mix of java and cobol applications. As a matter of fact, it can be easily reproduced with the standalone JDT by the following steps: 1/ Define a class Bar in a source Bar.java with a method void bar() {} 2/ Define a main class Foo in a source Foo.java that references the method Bar.bar() 3/ Compile and run both. everything is fine 4/ Save Bar.class from the bin directory in a temp directory 5/ Delete from the Java project the Bar.java source and refresh the whole directory 6/ Restore the Bar.class in the initial bin directory 7/ Recompile Foo.java:==> error "Bar cannot be resolved or is not a type" Regards Francis ANDRE
This isn't a valid test case. If you intend such class files to be on the build path, then simply put them on it... using class folders. Storing them directly into the builder output is just wrong. And again, we don't care about attached sources when compiling, so the fact the files were produced by other tools shouldn't make any difference as long as they are valid class files.
Please also paste in the contents of your .classpath file. I suspect you did not set it up correctly, it should point at the cobol .class files somehow; until you specify this, they will not be referenceable from Java sources as not on the classpath.
While trying to reduce the scope of the problem, I reproduce it with the standalone JDT itself. Here the steps to follow it 1/ In the "default package", define a Java class "foo" 2/ In a "foo" package, define a foo.bar class 3/ reference the "foo.class" of the "foo" type in a third class: compile ok 3/ copy the foo.class and the foo/bar.class in a class folder 4/ remove the foo.java, the foo.bar class and the foo package 5/ the "foo.class" or the "foo" type referenced in the third java class is unknown:error "foo cannot be resolved or is not a type" In fact, just a directory with the same name as the "default package" class is enough to make it unrecognize from the JDT. Regards
What is a "foo.bar" class ? Please attach testcase.
Created attachment 8574 [details] Test case for: foo cannot be resolved (or is not a valid type) for the field third.afoo
Reproduced, thanks. Changing title to reflect actual problem. Kent: setup is following: 1. Define project with src & lib folder: P/src/X.java public class X { foo f1; foo.bar b1; } P/lib/foo.class P/lib/foo/bar.class when compiling X, an error is reported against 'foo f1' as we resolve it to the package 'foo'. javac accepts this code using following command line D:\workspace\P\src>javac X.java -classpath ..\lib -d ..\bin [parsing started X.java] [parsing completed 62ms] [loading ..\lib\foo\bar.class] [loading D:\JDK1.4.2\jre\lib\rt.jar(java/lang/Object.class)] [loading ..\lib\foo.class] [checking X] [wrote ..\bin\X.class] [total 437ms]
Hi I have seen the target milestone as 3.0 M9...Would it be possible to have also a patch for 2.1.2?? Thanks Regards
Is it possible for you to rename the class that collides with the package name? This would let you proceed immediately with no changes from us, and is likely the only solution we can provide in the 2.1.x stream in the short term.
That's not possible since the generated class and the generated package/directory have the same name by construction (a cobol program FOO.cob generates FOO.class and FOO.WORKING_STORAGE.class and others FOO.*.class). So, we will have to switch to 3.0 sooner or later...
Philippe - I tried the example & I get the following with javac: D:\test2>javac -verbose X.java -classpath ..\lib -d ..\bin [parsing started X.java] [parsing completed 32ms] [loading D:\jdk1.4.2\jre\lib\rt.jar(java/lang/Object.class)] [loading ..\lib\foo.class] X.java:3: cannot resolve symbol symbol : class bar location: class foo foo.bar b1; ^ [checking X] [total 235ms] 1 error
Actually, I cannot get Javac to accept this code any longer. I wonder what I did wrong. However, in our case, we cannot resolve 'foo' where javac only gets confused on 'bar' (since it picked 'foo' to be the class). i.e., the following program should compile clear: public class X { foo f1; }
So I have tried Philippe's example with JDK1.3, 1.4.2 & 1.5 and none of them will allow you access the type foo.bar. We can change our lookup in the type/package collision case to answer the type instead of the package, but its not going to change the fact that you cannot refer to any types inside the package.
Switched the collision case so we now answer the type instead of the package. Released change into HEAD.
Created attachment 9891 [details] Test case that compiles and runs with JDK 1.4.1_02 I have modified the small case with a method public void print() in each classes. It compiles and executes fine with me. java -version java version "1.4.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06) Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode) D:\Eclipse\bugs>java third in foo in foo.bar Regards
Hi I have reopened the case since I would like to understand where is the problem since it compiles and executes fine with my environment????. I added a new attachement that shows the compiled classes as well as the java source code. Moreover, I added a method public void print() in each java class and execution gives the correct printed result.
Change third.java to look like the following & you'll see the problem: //import foo.bar; public class third { foo afoo; foo.bar abar; // rest remains the same With the changes released yesterday, we compile & run your example fine. But if you change the example to use qualified type references (as Philippe did in his test) instead of imports, then you will see the collision case with javac, as well as our compiler.
Added regression tests in class CollisionCase.
Verified for 3.0 M9 with build I200405190010.
