Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37518 > unrolled thread

Problem compiling with 9 for 8

Back to article view | Back to comp.lang.java.programmer

Contents

  Problem compiling with 9 for 8 Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-10-02 10:51 -0500
    Re: Problem compiling with 9 for 8 Arne Vajhøj <arne@vajhoej.dk> - 2017-10-02 14:25 -0400
      Re: Problem compiling with 9 for 8 Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-10-02 14:49 -0500
        Re: Problem compiling with 9 for 8 Arne Vajhøj <arne@vajhoej.dk> - 2017-10-02 16:10 -0400
          Re: Problem compiling with 9 for 8 Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-10-02 16:08 -0500
            Re: Problem compiling with 9 for 8 Arne Vajhøj <arne@vajhoej.dk> - 2017-10-02 19:46 -0400
              Re: Problem compiling with 9 for 8 Arne Vajhøj <arne@vajhoej.dk> - 2017-10-02 20:03 -0400
                Re: Problem compiling with 9 for 8 Arne Vajhøj <arne@vajhoej.dk> - 2017-10-02 20:12 -0400
                  Re: Problem compiling with 9 for 8 Arne Vajhøj <arne@vajhoej.dk> - 2017-10-02 20:24 -0400
                    Re: Problem compiling with 9 for 8 Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-10-03 10:32 -0500
                      Re: Problem compiling with 9 for 8 Arne Vajhøj <arne@vajhoej.dk> - 2017-10-03 20:48 -0400
                        Re: Problem compiling with 9 for 8 Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-10-04 17:27 -0500

#37518 — Problem compiling with 9 for 8

I want to compile this program with the Java 9 compiler but with but 
with the --release 8 option so that it will run on a Java 8 runtime. 
The --add-modules option is not available if the --release options is 
specified.  Anybody know what the solution is?  Am I going at this the 
wrong way?

C:\Users\Knute Johnson>javac --release 8 -Xlint:unchecked -cp 
.;com/knutejohnson
/rosen/javax.mail.jar com/knutejohnson/rosen/PHD2Alarms.java
.\com\knutejohnson\rosen\AlarmDialog2.java:9: error: package 
javafx.scene.media
does not exist
import javafx.scene.media.*;
^
.\com\knutejohnson\rosen\AlarmDialog2.java:60: error: cannot find symbol
         AudioClip clip = null;
         ^
   symbol:   class AudioClip
   location: class AlarmDialog2


Thanks,

-- 

Knute Johnson

[toc] | [next] | [standalone]

#37519

On 10/2/2017 11:51 AM, Knute Johnson wrote:
> I want to compile this program with the Java 9 compiler but with but 
> with the --release 8 option so that it will run on a Java 8 runtime. The 
> --add-modules option is not available if the --release options is 
> specified.  Anybody know what the solution is?  Am I going at this the 
> wrong way?
> 
> C:\Users\Knute Johnson>javac --release 8 -Xlint:unchecked -cp 
> .;com/knutejohnson
> /rosen/javax.mail.jar com/knutejohnson/rosen/PHD2Alarms.java
> .\com\knutejohnson\rosen\AlarmDialog2.java:9: error: package 
> javafx.scene.media
> does not exist
> import javafx.scene.media.*;
> ^
> .\com\knutejohnson\rosen\AlarmDialog2.java:60: error: cannot find symbol
>          AudioClip clip = null;
>          ^
>    symbol:   class AudioClip
>    location: class AlarmDialog2

Have you tried putting Java 8 jfxrt.jar explicit in classpath?

Arne

[toc] | [prev] | [next] | [standalone]

#37520

On 10/2/2017 13:25, Arne Vajhøj wrote:
> On 10/2/2017 11:51 AM, Knute Johnson wrote:
>> I want to compile this program with the Java 9 compiler but with but 
>> with the --release 8 option so that it will run on a Java 8 runtime. 
>> The --add-modules option is not available if the --release options is 
>> specified.  Anybody know what the solution is?  Am I going at this the 
>> wrong way?
>>
>> C:\Users\Knute Johnson>javac --release 8 -Xlint:unchecked -cp 
>> .;com/knutejohnson
>> /rosen/javax.mail.jar com/knutejohnson/rosen/PHD2Alarms.java
>> .\com\knutejohnson\rosen\AlarmDialog2.java:9: error: package 
>> javafx.scene.media
>> does not exist
>> import javafx.scene.media.*;
>> ^
>> .\com\knutejohnson\rosen\AlarmDialog2.java:60: error: cannot find symbol
>>          AudioClip clip = null;
>>          ^
>>    symbol:   class AudioClip
>>    location: class AlarmDialog2
> 
> Have you tried putting Java 8 jfxrt.jar explicit in classpath?
> 
> Arne
> 

No but that file is not included in Java 9.  It compiles fine if I don't 
have the --release 8 option and it compiled fine under Java 8.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#37521

On 10/2/2017 3:49 PM, Knute Johnson wrote:
> On 10/2/2017 13:25, Arne Vajhøj wrote:
>> On 10/2/2017 11:51 AM, Knute Johnson wrote:
>>> I want to compile this program with the Java 9 compiler but with but 
>>> with the --release 8 option so that it will run on a Java 8 runtime. 
>>> The --add-modules option is not available if the --release options is 
>>> specified.  Anybody know what the solution is?  Am I going at this 
>>> the wrong way?
>>>
>>> C:\Users\Knute Johnson>javac --release 8 -Xlint:unchecked -cp 
>>> .;com/knutejohnson
>>> /rosen/javax.mail.jar com/knutejohnson/rosen/PHD2Alarms.java
>>> .\com\knutejohnson\rosen\AlarmDialog2.java:9: error: package 
>>> javafx.scene.media
>>> does not exist
>>> import javafx.scene.media.*;
>>> ^
>>> .\com\knutejohnson\rosen\AlarmDialog2.java:60: error: cannot find symbol
>>>          AudioClip clip = null;
>>>          ^
>>>    symbol:   class AudioClip
>>>    location: class AlarmDialog2
>>
>> Have you tried putting Java 8 jfxrt.jar explicit in classpath?
> 
> No but that file is not included in Java 9.  It compiles fine if I don't 
> have the --release 8 option and it compiled fine under Java 8.

Yes. But does it work?

It is my understanding that:

javac --release 8 ...

is really a short version of:

javac -source 1.8 -target 1.8 -Xbootclasspath:pathtojava8jar ...

And if that is correct then it still need the old jar files
to build against.

And maybe it just don't find jfxrt.jar automatically.

Arne

[toc] | [prev] | [next] | [standalone]

#37522

On 10/2/2017 15:10, Arne Vajhøj wrote:
> Yes. But does it work?

Yes it does.

I guess I shouldn't read the docs because they say:

--release release

     Compiles against the public, supported and documented API for a 
specific VM version. Supported release targets are 6, 7, 8, and 9.

     Note:

     When using --release for a version of the Java Platform that 
supports modules, you can’t use --add-modules to access internal JDK 
modules, nor can you use --add-exports to access internal JDK APIs in 
the modules.

And with no further information supplied that implies to me that you 
don't need to have JDK 8 installed (or parts of it) to get it to compile.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#37523

On 10/2/2017 5:08 PM, Knute Johnson wrote:
> On 10/2/2017 15:10, Arne Vajhøj wrote:
>> Yes. But does it work?
> 
> Yes it does.
> 
> I guess I shouldn't read the docs because they say:
> 
> --release release
> 
>      Compiles against the public, supported and documented API for a 
> specific VM version. Supported release targets are 6, 7, 8, and 9.
> 
>      Note:
> 
>      When using --release for a version of the Java Platform that 
> supports modules, you can’t use --add-modules to access internal JDK 
> modules, nor can you use --add-exports to access internal JDK APIs in 
> the modules.
> 
> And with no further information supplied that implies to me that you 
> don't need to have JDK 8 installed (or parts of it) to get it to compile.

As I explained then I believe that --release replaces -source (that
set the language itself version), -target (that set the generated Java
byte code version) and -Xbootclasspath (that set the javart.jar used
and therefore the version used).

So I do not expect the Java compiler to have a list of the entire
Java API for all 4 versions and verify usage against that.

So I am not surprised that Java 8 is needed.

If Java 8 javac automatically find jfxrt.jar then I would lean
towards that Java 9 javac with --release 8 does not to be a
bug.

Arne

[toc] | [prev] | [next] | [standalone]

#37524

On 10/2/2017 7:46 PM, Arne Vajhøj wrote:
> As I explained then I believe that --release replaces -source (that
> set the language itself version), -target (that set the generated Java
> byte code version) and -Xbootclasspath (that set the javart.jar used
> and therefore the version used).

I found the documentation:

https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6

<quote>
The --release N flag is conceptually a macro for:

-source N -target N -bootclasspath $PATH_TO_rt.jar_FOR_RELEASE_N
</quote>

Arne

[toc] | [prev] | [next] | [standalone]

#37525

On 10/2/2017 8:03 PM, Arne Vajhøj wrote:
> On 10/2/2017 7:46 PM, Arne Vajhøj wrote:
>> As I explained then I believe that --release replaces -source (that
>> set the language itself version), -target (that set the generated Java
>> byte code version) and -Xbootclasspath (that set the javart.jar used
>> and therefore the version used).
> 
> I found the documentation:
> 
> https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6 
> 
> 
> <quote>
> The --release N flag is conceptually a macro for:
> 
> -source N -target N -bootclasspath $PATH_TO_rt.jar_FOR_RELEASE_N
> </quote>

But I was wrong about the implementation.

It does not use the old rt.jar.

https://bugs.openjdk.java.net/browse/JDK-8058150

<quote>
For JDK N and --release M, M < N, signature data of the documented APIs 
of release M of the platform is needed. This data is stored in the 
$JDK_ROOT/lib/ct.sym file, which is similar, but not the same, as the 
file of the same name in JDK 8. The ct.sym file is a ZIP file containing 
stripped-down class files corresponding to class files from the target 
platform versions.
</quote>

So --release should work without the old rt.jar, but zipinfo on
ct.sym reveals that JavaFX is not included in it.

So therefore an actual old jfxrt.jar is needed.

Arne

[toc] | [prev] | [next] | [standalone]

#37526

On 10/2/2017 8:12 PM, Arne Vajhøj wrote:
> But I was wrong about the implementation.
> 
> It does not use the old rt.jar.
> 
> https://bugs.openjdk.java.net/browse/JDK-8058150
> 
> <quote>
> For JDK N and --release M, M < N, signature data of the documented APIs 
> of release M of the platform is needed. This data is stored in the 
> $JDK_ROOT/lib/ct.sym file, which is similar, but not the same, as the 
> file of the same name in JDK 8. The ct.sym file is a ZIP file containing 
> stripped-down class files corresponding to class files from the target 
> platform versions.
> </quote>
> 
> So --release should work without the old rt.jar, but zipinfo on
> ct.sym reveals that JavaFX is not included in it.
> 
> So therefore an actual old jfxrt.jar is needed.

Some googling reveals that ct.sym was introduced as far
back as Java 6.

Arne

[toc] | [prev] | [next] | [standalone]

#37528

On 10/2/2017 19:24, Arne Vajhøj wrote:
> On 10/2/2017 8:12 PM, Arne Vajhøj wrote:
>> But I was wrong about the implementation.
>>
>> It does not use the old rt.jar.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8058150
>>
>> <quote>
>> For JDK N and --release M, M < N, signature data of the documented 
>> APIs of release M of the platform is needed. This data is stored in 
>> the $JDK_ROOT/lib/ct.sym file, which is similar, but not the same, as 
>> the file of the same name in JDK 8. The ct.sym file is a ZIP file 
>> containing stripped-down class files corresponding to class files from 
>> the target platform versions.
>> </quote>
>>
>> So --release should work without the old rt.jar, but zipinfo on
>> ct.sym reveals that JavaFX is not included in it.
>>
>> So therefore an actual old jfxrt.jar is needed.
> 
> Some googling reveals that ct.sym was introduced as far
> back as Java 6.
> 
> Arne
> 

Well that explains why some of my other programs didn't have that 
problem when I compiled them with --release 8.

Thanks for figuring that out for me.

Next I have to figure out this whole module thing.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#37551

On 10/3/2017 11:32 AM, Knute Johnson wrote:
> Next I have to figure out this whole module thing.

I think the critical part is to not associate modules
with loadable/unloadable plugins, but to see it as
a grouping above package level that adds another
layer of visible/non-visible on top of the existing.

Arne

[toc] | [prev] | [next] | [standalone]

#37558

On 10/3/2017 19:48, Arne Vajhøj wrote:
> On 10/3/2017 11:32 AM, Knute Johnson wrote:
>> Next I have to figure out this whole module thing.
> 
> I think the critical part is to not associate modules
> with loadable/unloadable plugins, but to see it as
> a grouping above package level that adds another
> layer of visible/non-visible on top of the existing.
> 
> Arne

Alright, I'll do that, thanks.


-- 

Knute Johnson

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web