Re: problems with freetype.dll, jdk 8 and windows

[Hendrik Schreiber]

> On Mar 7, 2016, at 17:50, Phil Race  wrote:
> 
> On 03/07/2016 08:11 AM, Hendrik Schreiber wrote:
>> - System Setup: freetype is listed as a requirement for Linux and Solaris. 
>> But not for Windows.
> 
> I don't think that is completely accurate.

What I meant to point out is, that the README document has a section called 
“System Setup”. It seems to specify needed requisites for different platforms, 
namely Linux, Solaris, Windows and Mac OS X.

Under none of the “Windows” headings, freetype is listed. But clearly, to build 
the JDK for Windows, you need freetype installed or at least the sources 
accessible.

But that’s beside the point. I’m sure one can guess and assume one’s way 
through the whole thing just fine.

I really just wanted to list some things that would have made it easier *for 
me* to get going, assuming that it would also make it easier for other people. 
IMHO, a little verbosity does not hurt in such a document.

Please don’t take my email as an annoyance. I just wanted to point some things 
out that most people working with the JDK for years would probably never 
notice, simply because they have no need to read the README file in the first 
place.

Cheers!

-hendrik

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

[David DeHaven]

>> I've updated the webrev, hopefully one last time with feedback from Joe 
>> Darcy.
>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/
>> 
>> - Relocated package Javadoc to above the package declaration in 
>> package-info.java
>> - Reworded the Javadoc on the default JSObject ctor
>> 
>> A point was brought up that the default ctor could probably be 
>> package-private, but there's no time to investigate what the impact would be 
>> so I will file a follow-up issue to investigate doing that at a later date.
>> 
> This looks okay. Also I assume ServiceLoader.loadInstalled is what you want 
> as you only want to find implementations in the run-time image.

Correct.

-DrD-

Re: problems with freetype.dll, jdk 8 and windows

[Phil Race]

On 03/07/2016 08:11 AM, Hendrik Schreiber wrote:

- System Setup: freetype is listed as a requirement for Linux and Solaris. But 
not for Windows.


I don't think that is completely accurate. There is  some additional mention
in Unix sections regarding what to install to make your life easier,
but the README has (since JDK7) listed freetype as required without 
limiting it to specific platforms.


i.e. In JDK9 the "configure" section says :-


*|--with-freetype=|*/path/
select the freetype files to use.

Expecting the freetype libraries under |lib/| and the headers under 
|include/|.


Version 2.3 or newer of FreeType is required. On Unix systems required 
files can be available as part of your distribution .


---


-phil.

Re: problems with freetype.dll, jdk 8 and windows

[Hendrik Schreiber]

>> 
>> BTW—Something that puzzles me but probably has a straight forward 
>> explanation: Why is there no freetype.dll in the pre-built JDKs (either 8 or 
>> 9)? Shouldn’t that be in there somewhere? I was thinking that would be a 
>> great source for a correctly built binary lib..
> 
> If by "pre-built" you mean the Oracle JDKs, they don't use/require freetype - 
> only OpenJDK does.

Ah! Thanks, David, for pointing this out. I was not aware of it.

-hendrik

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

[Kevin Rushforth]

Dave,

Just to tie up the loose end about the default JSObject constructor: No 
it cannot be package private. JavaFX WebView extends this class.


-- Kevin


Alan Bateman wrote:



On 05/03/2016 18:54, David DeHaven wrote:
I've updated the webrev, hopefully one last time with feedback from 
Joe Darcy.

http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/

- Relocated package Javadoc to above the package declaration in 
package-info.java

- Reworded the Javadoc on the default JSObject ctor

A point was brought up that the default ctor could probably be 
package-private, but there's no time to investigate what the impact 
would be so I will file a follow-up issue to investigate doing that 
at a later date.


This looks okay. Also I assume ServiceLoader.loadInstalled is what you 
want as you only want to find implementations in the run-time image.


-Alan

Re: RFR: 8151351: HotSpot build process should regard --with-native-debug-symbols.

[Yasumasa Suenaga]

Thanks Erik, I understood.
I closed this issue with Won't Fix.


Yasumasa


On 2016/03/07 23:36, Erik Joelsson wrote:

Hello Yasumasa,

In build-infra, we still have the old Hotspot build present for reference in 
hotspot/make. The new build currently resides in hotspot/makefiles. Basically 
no files in hotspot/make are used by the new build. After we switch in JDK 9, 
we will have both build systems available for a short while (1-2 weeks if we 
don't see any major trouble) before we remove the old and move the new build 
into hotspot/make.

To be clear, we do not use vm.make.

/Erik

On 2016-03-07 15:29, Yasumasa Suenaga wrote:

Hi Erik,


If you like, you can take it for a spin yourself by cloning 
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good 
shape right now on Linux.


Thanks! It looks good to me.

BTW, Does build-infra use hotspot/make/linux/makefiles/vm.make ?
vm.make have a bug in this issue yet.
However, build-infra seems to use make/common/NativeCompilation.gmk .
If so, I will close this issue.
(Will hotspot/make remove at JDK-8150601 ? )


Thanks,

Yasumasa


On 2016/03/07 18:54, Erik Joelsson wrote:

Hello Yasumasa,

Yes, it is indeed JEP 284 and I have verified that the new build there works as expected 
with the "internal" setting.

If you like, you can take it for a spin yourself by cloning 
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good 
shape right now on Linux.

/Erik

On 2016-03-07 10:34, Yasumasa Suenaga wrote:

Hi David,

Does "new hotspot build" mean JEP 284?
If it so and this issue does not occur on JEP 284, I will close this issue.

Thanks,

Yasumasa
2016/03/07 16:57 "David Holmes" :


Hi Yasumasa,

On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:

Hi all,

When I build fastdebug JDK (--enable-debug) with

--with-native-debug-symbols=internal,

build process generated *.debuginfo for libjsig and libjvm.
I think that build process should regard --with-native-debug-symbols.

As I wrote in the bug report we are getting very close to the switch
over to the new hotspot build and I'm assuming/hoping this is already
addressed there. We are avoiding non-urgent changes to the hotspot build
in the meantime to ease the change over.

Thanks,
David


I've uploaded webrev. Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/

I cannot access JPRT. So I need a sponsor.


Thanks,

Yasumasa

Re: RFR: 8151351: HotSpot build process should regard --with-native-debug-symbols.

[Erik Joelsson]

Hello Yasumasa,

In build-infra, we still have the old Hotspot build present for 
reference in hotspot/make. The new build currently resides in 
hotspot/makefiles. Basically no files in hotspot/make are used by the 
new build. After we switch in JDK 9, we will have both build systems 
available for a short while (1-2 weeks if we don't see any major 
trouble) before we remove the old and move the new build into hotspot/make.


To be clear, we do not use vm.make.

/Erik

On 2016-03-07 15:29, Yasumasa Suenaga wrote:

Hi Erik,

If you like, you can take it for a spin yourself by cloning 
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty 
good shape right now on Linux.


Thanks! It looks good to me.

BTW, Does build-infra use hotspot/make/linux/makefiles/vm.make ?
vm.make have a bug in this issue yet.
However, build-infra seems to use make/common/NativeCompilation.gmk .
If so, I will close this issue.
(Will hotspot/make remove at JDK-8150601 ? )


Thanks,

Yasumasa


On 2016/03/07 18:54, Erik Joelsson wrote:

Hello Yasumasa,

Yes, it is indeed JEP 284 and I have verified that the new build 
there works as expected with the "internal" setting.


If you like, you can take it for a spin yourself by cloning 
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty 
good shape right now on Linux.


/Erik

On 2016-03-07 10:34, Yasumasa Suenaga wrote:

Hi David,

Does "new hotspot build" mean JEP 284?
If it so and this issue does not occur on JEP 284, I will close this 
issue.


Thanks,

Yasumasa
2016/03/07 16:57 "David Holmes" :


Hi Yasumasa,

On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:

Hi all,

When I build fastdebug JDK (--enable-debug) with

--with-native-debug-symbols=internal,

build process generated *.debuginfo for libjsig and libjvm.
I think that build process should regard --with-native-debug-symbols.

As I wrote in the bug report we are getting very close to the switch
over to the new hotspot build and I'm assuming/hoping this is already
addressed there. We are avoiding non-urgent changes to the hotspot 
build

in the meantime to ease the change over.

Thanks,
David


I've uploaded webrev. Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/

I cannot access JPRT. So I need a sponsor.


Thanks,

Yasumasa

Re: RFR: 8151351: HotSpot build process should regard --with-native-debug-symbols.

[Yasumasa Suenaga]

Hi Erik,


If you like, you can take it for a spin yourself by cloning 
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good 
shape right now on Linux.


Thanks! It looks good to me.

BTW, Does build-infra use hotspot/make/linux/makefiles/vm.make ?
vm.make have a bug in this issue yet.
However, build-infra seems to use make/common/NativeCompilation.gmk .
If so, I will close this issue.
(Will hotspot/make remove at JDK-8150601 ? )


Thanks,

Yasumasa


On 2016/03/07 18:54, Erik Joelsson wrote:

Hello Yasumasa,

Yes, it is indeed JEP 284 and I have verified that the new build there works as expected 
with the "internal" setting.

If you like, you can take it for a spin yourself by cloning 
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good 
shape right now on Linux.

/Erik

On 2016-03-07 10:34, Yasumasa Suenaga wrote:

Hi David,

Does "new hotspot build" mean JEP 284?
If it so and this issue does not occur on JEP 284, I will close this issue.

Thanks,

Yasumasa
2016/03/07 16:57 "David Holmes" :


Hi Yasumasa,

On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:

Hi all,

When I build fastdebug JDK (--enable-debug) with

--with-native-debug-symbols=internal,

build process generated *.debuginfo for libjsig and libjvm.
I think that build process should regard --with-native-debug-symbols.

As I wrote in the bug report we are getting very close to the switch
over to the new hotspot build and I'm assuming/hoping this is already
addressed there. We are avoiding non-urgent changes to the hotspot build
in the meantime to ease the change over.

Thanks,
David


I've uploaded webrev. Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/

I cannot access JPRT. So I need a sponsor.


Thanks,

Yasumasa

Re: RFR: 8151351: HotSpot build process should regard --with-native-debug-symbols.

[Erik Joelsson]

Hello Yasumasa,

Yes, it is indeed JEP 284 and I have verified that the new build there 
works as expected with the "internal" setting.


If you like, you can take it for a spin yourself by cloning 
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty 
good shape right now on Linux.


/Erik

On 2016-03-07 10:34, Yasumasa Suenaga wrote:

Hi David,

Does "new hotspot build" mean JEP 284?
If it so and this issue does not occur on JEP 284, I will close this issue.

Thanks,

Yasumasa
2016/03/07 16:57 "David Holmes" :


Hi Yasumasa,

On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:

Hi all,

When I build fastdebug JDK (--enable-debug) with

--with-native-debug-symbols=internal,

build process generated *.debuginfo for libjsig and libjvm.
I think that build process should regard --with-native-debug-symbols.

As I wrote in the bug report we are getting very close to the switch
over to the new hotspot build and I'm assuming/hoping this is already
addressed there. We are avoiding non-urgent changes to the hotspot build
in the meantime to ease the change over.

Thanks,
David


I've uploaded webrev. Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/

I cannot access JPRT. So I need a sponsor.


Thanks,

Yasumasa

Re: RFR: 8151351: HotSpot build process should regard --with-native-debug-symbols.

[Yasumasa Suenaga]

Hi David,

Does "new hotspot build" mean JEP 284?
If it so and this issue does not occur on JEP 284, I will close this issue.

Thanks,

Yasumasa
2016/03/07 16:57 "David Holmes" :

> Hi Yasumasa,
>
> On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:
> > Hi all,
> >
> > When I build fastdebug JDK (--enable-debug) with
> --with-native-debug-symbols=internal,
> > build process generated *.debuginfo for libjsig and libjvm.
> > I think that build process should regard --with-native-debug-symbols.
>
> As I wrote in the bug report we are getting very close to the switch
> over to the new hotspot build and I'm assuming/hoping this is already
> addressed there. We are avoiding non-urgent changes to the hotspot build
> in the meantime to ease the change over.
>
> Thanks,
> David
>
> > I've uploaded webrev. Could you review it?
> >http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
> >
> > I cannot access JPRT. So I need a sponsor.
> >
> >
> > Thanks,
> >
> > Yasumasa
> >
>