Re: how to build HEADLEDD when using Icedtea

[David Holmes]

On 21/10/2016 2:35 PM, Diaz Soho wrote:

I can build openjdk8u with --disable-headful, but there is no option
to disable headful when I try to build Icedtea.

any ideas?


As I said you need to ask the IcedTea folk. This mailing list is not for 
IcedTea.


David


2016-10-21 11:02 GMT+08:00 David Holmes :

On 21/10/2016 11:52 AM, Diaz Soho wrote:


Hi All,

is there any way to build icedtea with "--disable-headful"?
because I would like to build icedtea for my embedded platform using jamvm
VM.



You'd need to ask the Icedtea folk about that.

David



best Regards,
DiazSoho

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

[Pete Brunet]

Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/

The fix now is to simply remove the copy of the AccessBridgeCalls.c file
into the JDK.

AccessBridgeCalls.c is the implementation of the documented Java Access
Bridge API and is a set of wrapper functions that hides the
complications related to interfacing to JAB's WindowsAccessBridge*.dll. 
In the past users of the API would compile and link to
AccessBridgeCalls.c/obj.

Since the interface implementation of AccessBridgeCalls.c will no longer
be provided the JAB API documentation will be updated to instruct a user
how to create an equivalent of AccessBridgeCalls.c.  The documentation
will also contain a reference to the JAB 2.0.2 download
http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
which does contain AccessBridgeCalls.c and which is compatible with the
current API and related calls into WindowsAccessBridge*.dll.

Pete

On 10/18/16 12:28 PM, Pete Brunet wrote:
> I've updated the webrev.  Please see
> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/
>
> Rather than removing the files needed by Assistive Technology developers
> we have to provide them in JDK.  However since there is a .c file in the
> group of files the files were moved from the include directory to a new
> javaaccessbridge directory.
>
> On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:
>> On 2016-10-14 17:51, Pete Brunet wrote:
>>> Please review the following. 
>>>
>>> The .h files and .c file provided to allow Assistive Technology to
>>> interface to the Java Access Bridge API are being removed from the built
>>> JRE/JDK images.  They are not used much and they can be obtained online
>>> via the OpenJDK web site.  The pubs will be updated to mention the
>>> location of the files.
>>>
>>> Since there is a .c file in this group of files the directory structure
>>> has been changed slightly to remove the include directory. 
>>>
>>> There was one file missing from the group of files needed by developers
>>> and that was moved from the common to the bridge directory.
>>>
>>> The make was updated in response to the above.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167213
>>>
>>> Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/
>> Build changes looks good to me.
>>
>> /Magnus

Re: how to build HEADLEDD when using Icedtea

[Diaz Soho]

I can build openjdk8u with --disable-headful, but there is no option
to disable headful when I try to build Icedtea.

any ideas?

2016-10-21 11:02 GMT+08:00 David Holmes :
> On 21/10/2016 11:52 AM, Diaz Soho wrote:
>>
>> Hi All,
>>
>> is there any way to build icedtea with "--disable-headful"?
>> because I would like to build icedtea for my embedded platform using jamvm
>> VM.
>
>
> You'd need to ask the Icedtea folk about that.
>
> David
>
>>
>> best Regards,
>> DiazSoho
>>
>

Re: RFR: 8168414 Various timeouthandler fixes

[David Holmes]

On 20/10/2016 11:44 PM, Staffan Larsen wrote:



On 20 Oct 2016, at 15:41, David Holmes  wrote:

On 20/10/2016 11:27 PM, Staffan Larsen wrote:

When looking for some timeout handler problems I found a few things that should 
be fixed:

* Strange use of Thread.currentThread().interrupt()


That isn't "strange" it is an idiomatic usage - if you can't propagate the 
InterruptedException to show your caller you have been interrupted then you re-assert the 
interrupt state.


OK, then. In this case it is less “strange” than “wrong”. The cases where this 
is done should not propagate the interrupt state - it only serves to throw 
unexpected exceptions higher up in the call-chain.


If code higher up the call chain can not handle being interrupted and 
interrupt is being used within the program to signal cancellation, then 
it is the higher up code that has a problem. As I said the existing code 
is an idiomatic approach to dealing with cancellation requests.


Cheers,
David



Cheers,
David


* Add logging for timeouts
* Milliseconds sometimes printed as microseconds or nanoseconds
* Should use destroyForcibly() to terminate processes
* No need to sleep in the last iteration when running a command multiple times
* Disable timeout handling timeouts since we do that ourselves

I didn’t want to file individual bugs for all of these, so I have lumped them 
together in one bug.

bug: https://bugs.openjdk.java.net/browse/JDK-8168414 
webrev: 
http://cr.openjdk.java.net/~sla/8168414/webrev.00 


Thanks,
/Staffan

Re: how to build HEADLEDD when using Icedtea

[David Holmes]

On 21/10/2016 11:52 AM, Diaz Soho wrote:

Hi All,

is there any way to build icedtea with "--disable-headful"?
because I would like to build icedtea for my embedded platform using jamvm VM.


You'd need to ask the Icedtea folk about that.

David



best Regards,
DiazSoho

how to build HEADLEDD when using Icedtea

[Diaz Soho]

Hi All,


is there any way to build icedtea with "--disable-headful"?
because I would like to build icedtea for my embedded platform using jamvm VM.


best Regards,
DiazSoho

Re: the Minimum set when install jdk8u

[Diaz Soho]

hi,

Yes, I have set in HDEALESS.

2016-10-21 5:06 GMT+08:00 yumin qi :
> HI, Diaz
>
>   I think you need build headless version (no X11 library etc). set
> BUILD_HEADLESS true.
> Regards
> Yumin
>
> On Thu, Oct 20, 2016 at 6:37 AM, Diaz Soho  wrote:
>>
>> Hi all,
>>
>> when I finish build openjdk, and try to install to a local directory,
>> I find the folder /usr/local/jvm/ include a lots of files , the size
>> is very large.
>>
>> is there any minimun set that I can select to install to my embedded
>> platform?
>> for example:
>> if I would like to run "java -jar " on my embedded
>> platform, then how to figure out the minimum set that should be
>> installed ?
>>
>> Thanks!
>>
>> Best Regards,
>> DiazSoho
>
>

Re: RFR: 8145471: javac changes for enhanced deprecation

[Jonathan Gibbons]

On 10/18/2016 05:00 PM, Jonathan Gibbons wrote:

Jan,

You're correct, the change in make/CompileJavaModules.gmk is not 
necessary. Well spotted.
The changes to the other make/ file are still necessary for the time 
being, to suppress warnings until the sources can be updated with 
appropriate use of @SuppressWarnings.


The use of the literal "true" in TypeEnter is definitely undesirable, 
and I think you are correct in that there does not seem to be an easy 
fix without changing how javac handles deprecation. Generally, I think 
that this would mean that we would mean we would have to defer all 
deprecation reporting until after annotation processing, when we can 
reliably determine the evaluation of the @Deprecated annotation, and 
therefore which sort of warning to generate. This is complicated by 
the fact that the conditions for deprecated warnings and removal 
warnings are slightly different. I will file a JBS entry.


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



-- Jon

On 10/18/2016 06:58 AM, Jan Lahoda wrote:

Overall, seem OK to me. Two comments:
-is the change in make/CompileJavaModules.gmk really needed given the 
adjusted JAVAC_WARNINGS in make/common/SetupJavaCompilers.gmk?


-the reliance on literal "true" in TypeEnter seems suspicious to me. 
What if the value of the attribute is a compile-time constant? I 
suspect this may be non-trivial to fix, so no strict need to fix that 
under this patch, but I think we should have a good idea how we want 
this fixed, and there should be a JBS entry filled for that.


Jan

On 18.10.2016 00:10, Jonathan Gibbons wrote:

Repeat, with subject line.

-- Jon

On 10/17/2016 03:03 PM, Jonathan Gibbons wrote:

Compiler folk, build folk,

Please review this update for javac and some build files, for JEP 277.

The work supports the enhanced Deprecation attribute, and generates a
new warning when items are referenced that are declared with
@Deprecated(forRemoval=true), in line with the proposals in JEP 277.

The warnings are on by default, and can be suppressed with
-Xlint:-removal or @SuppressWarnings("removal").  Because the warnings
are on by default, and because the warnings currently show up when
building JDK, some minor build changes are temporarily required to
suppress the warnings that get generated during the build.

-- Jon

JEP: http://openjdk.java.net/jeps/277
JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/

Re: RFR: 8165804: Revisit the way of loading BreakIterator rules/dictionaries

[Yuka Kamiya]

+1

On 2016/10/21 1:24, Naoto Sato wrote:

Looks good to me.

Naoto

On 10/20/16 1:33 AM, Masayoshi Okutsu wrote:

Hi,

Please review the changes for JDK-8165804 which is a follow-up of
JDK-8076757. Some notes on the changes.

- Removed INCLUDES := $(TEXT_PKG_LD) from
make/gendata/GendataBreakIterator.gmk in order to avoid compiling
non-BreakIterator*.java for the build tool with boot JDK.

- Added sun.util.resources.BreakIteratorResourceBundle which handles
loading of rule data and dictionaries. BreadIteratorResources* are its
subclasses in the java.base and jdk.localedata modules.

- In BreakIteratorResources*, regular ResourceBundle loading of
BreakIteratorInfo* is avoided because a BreakIteratorInfo can't have its
parent chain. For example, BreakIteratorInfo_th doesn't have the value
for key "CharacterData" and BreakIteratorResources_th.handleGetObject()
must return null for "CharacterData" rather than loading rule data given
by the parent BreakIteratorInfo.

- Moved RuleBasedBreakIterator, DictionaryBasedBreakIterator, and
BreakDictionary to sun.text. BreakIteratorProviderTest.java was changed
to deal with this refactoring.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8165804

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8165804/webrev.01

Thanks,
Masayoshi

Re: the Minimum set when install jdk8u

[yumin qi]

HI, Diaz

  I think you need build headless version (no X11 library etc). set
*BUILD_HEADLESS
true.*
*Regards*
*Yumin*

On Thu, Oct 20, 2016 at 6:37 AM, Diaz Soho  wrote:

> Hi all,
>
> when I finish build openjdk, and try to install to a local directory,
> I find the folder /usr/local/jvm/ include a lots of files , the size
> is very large.
>
> is there any minimun set that I can select to install to my embedded
> platform?
> for example:
> if I would like to run "java -jar " on my embedded
> platform, then how to figure out the minimum set that should be
> installed ?
>
> Thanks!
>
> Best Regards,
> DiazSoho
>

Re: RFR(s): 8168409 Update list of tools run by the jtreg timeouthandler

[Dmitry Samersoff]

Staffan,

Could you add
  jhsdb jstack --mixed --pid 
to get mixed stack trace when it possible?

-Dmitry

On 2016-10-20 14:42, Staffan Larsen wrote:
> Please review this small update to the list of tools that the jtreg 
> timeouthandler runs when a timeout is hit. This change removes all calls to 
> the old SA-tools and instead uses Diagnostic Commands to gather the same 
> information. The possible drawback is that Diagnostic Commands do not work on 
> processes where the JVM is completely hung, but in that case we can fallback 
> to running the SA-tools on the core file that is also generated.
> 
> webrev: http://cr.openjdk.java.net/~sla/8168409/webrev.00 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8168409 
> 
> 
> Thanks,
> /Staffan
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

Re: RFR(s): 8168409 Update list of tools run by the jtreg timeouthandler

[Staffan Larsen]

Thanks Marcus for all three reviews!

> On 20 Oct 2016, at 15:50, Marcus Larsson  wrote:
> 
> Hi,
> 
> 
>> On 10/20/2016 01:42 PM, Staffan Larsen wrote:
>> Please review this small update to the list of tools that the jtreg 
>> timeouthandler runs when a timeout is hit. This change removes all calls to 
>> the old SA-tools and instead uses Diagnostic Commands to gather the same 
>> information. The possible drawback is that Diagnostic Commands do not work 
>> on processes where the JVM is completely hung, but in that case we can 
>> fallback to running the SA-tools on the core file that is also generated.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8168409/webrev.00 
>> 
> 
> Looks good to me.
> 
> Thanks,
> Marcus
> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8168409 
>> 
>> 
>> Thanks,
>> /Staffan
> 

Re: RFR: 8165804: Revisit the way of loading BreakIterator rules/dictionaries

[Naoto Sato]

Looks good to me.

Naoto

On 10/20/16 1:33 AM, Masayoshi Okutsu wrote:

Hi,

Please review the changes for JDK-8165804 which is a follow-up of
JDK-8076757. Some notes on the changes.

- Removed INCLUDES := $(TEXT_PKG_LD) from
make/gendata/GendataBreakIterator.gmk in order to avoid compiling
non-BreakIterator*.java for the build tool with boot JDK.

- Added sun.util.resources.BreakIteratorResourceBundle which handles
loading of rule data and dictionaries. BreadIteratorResources* are its
subclasses in the java.base and jdk.localedata modules.

- In BreakIteratorResources*, regular ResourceBundle loading of
BreakIteratorInfo* is avoided because a BreakIteratorInfo can't have its
parent chain. For example, BreakIteratorInfo_th doesn't have the value
for key "CharacterData" and BreakIteratorResources_th.handleGetObject()
must return null for "CharacterData" rather than loading rule data given
by the parent BreakIteratorInfo.

- Moved RuleBasedBreakIterator, DictionaryBasedBreakIterator, and
BreakDictionary to sun.text. BreakIteratorProviderTest.java was changed
to deal with this refactoring.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8165804

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8165804/webrev.01

Thanks,
Masayoshi

Re: RFR: 8168414 Various timeouthandler fixes

[Marcus Larsson]

Hi,


On 10/20/2016 03:27 PM, Staffan Larsen wrote:

When looking for some timeout handler problems I found a few things that should 
be fixed:

* Strange use of Thread.currentThread().interrupt()
* Add logging for timeouts
* Milliseconds sometimes printed as microseconds or nanoseconds
* Should use destroyForcibly() to terminate processes
* No need to sleep in the last iteration when running a command multiple times
* Disable timeout handling timeouts since we do that ourselves

I didn’t want to file individual bugs for all of these, so I have lumped them 
together in one bug.

bug: https://bugs.openjdk.java.net/browse/JDK-8168414 

webrev: http://cr.openjdk.java.net/~sla/8168414/webrev.00 



Looks good to me!

Thanks,
Marcus



Thanks,
/Staffan

Re: RFR(XS): 8168412 Reduce buffering in jtreg timeouthandler

[Marcus Larsson]

Hi,


On 10/20/2016 02:03 PM, Staffan Larsen wrote:

Hi,

Please review this small patch to the jtreg timeouthandler to remove some 
buffering. We create PrintWriters in a couple of places and this patch adds the 
second parameter to the constructor to enable automatic flushing of the 
PrintWriter.

webrev: http://cr.openjdk.java.net/~sla/8168412/webrev.00 



Looks good!

Thanks,
Marcus


bug: https://bugs.openjdk.java.net/browse/JDK-8168412 


Thanks,
/Staffan

Re: RFR(s): 8168409 Update list of tools run by the jtreg timeouthandler

[Marcus Larsson]

Hi,


On 10/20/2016 01:42 PM, Staffan Larsen wrote:

Please review this small update to the list of tools that the jtreg 
timeouthandler runs when a timeout is hit. This change removes all calls to the 
old SA-tools and instead uses Diagnostic Commands to gather the same 
information. The possible drawback is that Diagnostic Commands do not work on 
processes where the JVM is completely hung, but in that case we can fallback to 
running the SA-tools on the core file that is also generated.

webrev: http://cr.openjdk.java.net/~sla/8168409/webrev.00 



Looks good to me.

Thanks,
Marcus


bug: https://bugs.openjdk.java.net/browse/JDK-8168409 


Thanks,
/Staffan

Re: RFR: 8168414 Various timeouthandler fixes

[Staffan Larsen]

> On 20 Oct 2016, at 15:41, David Holmes  wrote:
> 
> On 20/10/2016 11:27 PM, Staffan Larsen wrote:
>> When looking for some timeout handler problems I found a few things that 
>> should be fixed:
>> 
>> * Strange use of Thread.currentThread().interrupt()
> 
> That isn't "strange" it is an idiomatic usage - if you can't propagate the 
> InterruptedException to show your caller you have been interrupted then you 
> re-assert the interrupt state.

OK, then. In this case it is less “strange” than “wrong”. The cases where this 
is done should not propagate the interrupt state - it only serves to throw 
unexpected exceptions higher up in the call-chain.

> 
> Cheers,
> David
> 
>> * Add logging for timeouts
>> * Milliseconds sometimes printed as microseconds or nanoseconds
>> * Should use destroyForcibly() to terminate processes
>> * No need to sleep in the last iteration when running a command multiple 
>> times
>> * Disable timeout handling timeouts since we do that ourselves
>> 
>> I didn’t want to file individual bugs for all of these, so I have lumped 
>> them together in one bug.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8168414 
>> webrev: 
>> http://cr.openjdk.java.net/~sla/8168414/webrev.00 
>> 
>> 
>> Thanks,
>> /Staffan
>> 

Re: RFR: 8168414 Various timeouthandler fixes

[David Holmes]

On 20/10/2016 11:27 PM, Staffan Larsen wrote:

When looking for some timeout handler problems I found a few things that should 
be fixed:

* Strange use of Thread.currentThread().interrupt()


That isn't "strange" it is an idiomatic usage - if you can't propagate 
the InterruptedException to show your caller you have been interrupted 
then you re-assert the interrupt state.


Cheers,
David


* Add logging for timeouts
* Milliseconds sometimes printed as microseconds or nanoseconds
* Should use destroyForcibly() to terminate processes
* No need to sleep in the last iteration when running a command multiple times
* Disable timeout handling timeouts since we do that ourselves

I didn’t want to file individual bugs for all of these, so I have lumped them 
together in one bug.

bug: https://bugs.openjdk.java.net/browse/JDK-8168414 
webrev: 
http://cr.openjdk.java.net/~sla/8168414/webrev.00 


Thanks,
/Staffan

Fwd: the Minimum set when install jdk8u

[Diaz Soho]

Hi all,

when I finish build openjdk, and try to install to a local directory,
I find the folder /usr/local/jvm/ include a lots of files , the size
is very large.

is there any minimun set that I can select to install to my embedded platform?
for example:
if I would like to run "java -jar " on my embedded
platform, then how to figure out the minimum set that should be
installed ?

Thanks!

Best Regards,
DiazSoho

RFR: 8168414 Various timeouthandler fixes

[Staffan Larsen]

When looking for some timeout handler problems I found a few things that should 
be fixed: 

* Strange use of Thread.currentThread().interrupt() 
* Add logging for timeouts 
* Milliseconds sometimes printed as microseconds or nanoseconds 
* Should use destroyForcibly() to terminate processes 
* No need to sleep in the last iteration when running a command multiple times 
* Disable timeout handling timeouts since we do that ourselves 

I didn’t want to file individual bugs for all of these, so I have lumped them 
together in one bug.

bug: https://bugs.openjdk.java.net/browse/JDK-8168414 
webrev: 
http://cr.openjdk.java.net/~sla/8168414/webrev.00 


Thanks,
/Staffan

RFR(XS): 8168412 Reduce buffering in jtreg timeouthandler

[Staffan Larsen]

Hi,

Please review this small patch to the jtreg timeouthandler to remove some 
buffering. We create PrintWriters in a couple of places and this patch adds the 
second parameter to the constructor to enable automatic flushing of the 
PrintWriter.

webrev: http://cr.openjdk.java.net/~sla/8168412/webrev.00 

bug: https://bugs.openjdk.java.net/browse/JDK-8168412 


Thanks,
/Staffan

RFR(s): 8168409 Update list of tools run by the jtreg timeouthandler

[Staffan Larsen]

Please review this small update to the list of tools that the jtreg 
timeouthandler runs when a timeout is hit. This change removes all calls to the 
old SA-tools and instead uses Diagnostic Commands to gather the same 
information. The possible drawback is that Diagnostic Commands do not work on 
processes where the JVM is completely hung, but in that case we can fallback to 
running the SA-tools on the core file that is also generated.

webrev: http://cr.openjdk.java.net/~sla/8168409/webrev.00 

bug: https://bugs.openjdk.java.net/browse/JDK-8168409 


Thanks,
/Staffan

RFR: 8165804: Revisit the way of loading BreakIterator rules/dictionaries

[Masayoshi Okutsu]

Hi,

Please review the changes for JDK-8165804 which is a follow-up of 
JDK-8076757. Some notes on the changes.


- Removed INCLUDES := $(TEXT_PKG_LD) from 
make/gendata/GendataBreakIterator.gmk in order to avoid compiling 
non-BreakIterator*.java for the build tool with boot JDK.


- Added sun.util.resources.BreakIteratorResourceBundle which handles 
loading of rule data and dictionaries. BreadIteratorResources* are its 
subclasses in the java.base and jdk.localedata modules.


- In BreakIteratorResources*, regular ResourceBundle loading of 
BreakIteratorInfo* is avoided because a BreakIteratorInfo can't have its 
parent chain. For example, BreakIteratorInfo_th doesn't have the value 
for key "CharacterData" and BreakIteratorResources_th.handleGetObject() 
must return null for "CharacterData" rather than loading rule data given 
by the parent BreakIteratorInfo.


- Moved RuleBasedBreakIterator, DictionaryBasedBreakIterator, and 
BreakDictionary to sun.text. BreakIteratorProviderTest.java was changed 
to deal with this refactoring.


Issue:
https://bugs.openjdk.java.net/browse/JDK-8165804

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8165804/webrev.01

Thanks,
Masayoshi