Re: RFR(xs): 8221375: Windows 32bit build (VS2017) broken

[Martijn Verburg]

Hi Thomas,

Will do and appreciate the support!

Cheers,
Martijn


On Wed, 27 Mar 2019 at 11:13, Thomas Stüfe  wrote:

>
>
> On Wed, Mar 27, 2019 at 11:08 AM Martijn Verburg 
> wrote:
>
>> Hi Thomas,
>>
>> Release only (we've only created debug builds for x64),
>>
>
> Okay. A number of those errors were debug only.
>
>
>> we do use the treat errors as warnings flag.
>>
>
> Other way around, I hope ;)
>
>
>>
>> You can look at all of our build configurations and build histories at
>> ci.adoptopenjdk.net - and I've copied in Ali Ince who's working for
>> jClarity on Windows 32/64 builds amongst other things.
>>
>> Okay, that's useful.
>
> JDK changes have been pushed (JDK-8221405
> <https://bugs.openjdk.java.net/browse/JDK-8221405> , JDK-8221406
> <https://bugs.openjdk.java.net/browse/JDK-8221406> , JDK-8221407
> <https://bugs.openjdk.java.net/browse/JDK-8221407> , first one in
> jdk/client since awt maintainers asked me to). Hotspot changes still under
> review, we ponder the best way to deal with a supposed vc++ bug here (
> JDK-8221408 <https://bugs.openjdk.java.net/browse/JDK-8221408> ). Feel
> free to test or review.
>
> Note that I do not plan to keep windows 32 bit alive, this was just a
> weekend thing because I needed a 32bit VM on windows for some comparisons.
> So I'd be happy that you guys are regularly building it (if possible
> fastdebug too). Please report any build breaks. When reported promptly,
> with the offending change linked in JBS, the authors will often try to fix
> it themselves.
>
> Cheers, Thomas
>
>
>> Cheers,
>> Martijn
>>
>>
>> On Tue, 26 Mar 2019 at 06:04, Thomas Stüfe 
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 25, 2019 at 10:49 PM Martijn Verburg <
>>> martijnverb...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Snipping much, but commenting on one statement inline below.
>>>>
>>>> On Mon, 25 Mar 2019 at 01:58, David Holmes 
>>>> wrote:
>>>>
>>>>> Hi Thomas,
>>>>>
>>>>> A few queries, comments and concerns ...
>>>>>
>>>>> On 25/03/2019 6:58 am, Thomas Stüfe wrote:
>>>>> > Hi all,
>>>>> >
>>>>> > After a long time I tried to build a Windows 32bit VM (VS2017) and
>>>>> failed;
>>>>>
>>>>> I'm somewhat surprised as I thought someone was actively doing Windows
>>>>> 32-bit builds out there, plus there are shared code changes that
>>>>> should
>>>>> also have been caught by non-Windows 32-bit builds. :(
>>>>>
>>>>
>>>> AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017
>>>> to do so and have hit the same issues (Thomas beat us to reporting!).
>>>>
>>>>
>>> Still curious what you actually build, since I believe not all of the
>>> issues are related to vs2017.
>>>
>>> Do you build release only or also debug? Do you build with
>>> warnings-as-errors disabled?
>>>
>>>
>>>> Hopefully, we'll have that nightly warning system in place for you
>>>> going forward soon.
>>>>
>>>>
>>> That would be helpful.
>>>
>>> Cheers, Thomas
>>>
>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>

Re: RFR(xs): 8221375: Windows 32bit build (VS2017) broken

[Martijn Verburg]

Hi Thomas,

Release only (we've only created debug builds for x64), we do use the treat
errors as warnings flag.

You can look at all of our build configurations and build histories at
ci.adoptopenjdk.net - and I've copied in Ali Ince who's working for
jClarity on Windows 32/64 builds amongst other things.

Cheers,
Martijn


On Tue, 26 Mar 2019 at 06:04, Thomas Stüfe  wrote:

>
>
> On Mon, Mar 25, 2019 at 10:49 PM Martijn Verburg 
> wrote:
>
>> Hi all,
>>
>> Snipping much, but commenting on one statement inline below.
>>
>> On Mon, 25 Mar 2019 at 01:58, David Holmes 
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> A few queries, comments and concerns ...
>>>
>>> On 25/03/2019 6:58 am, Thomas Stüfe wrote:
>>> > Hi all,
>>> >
>>> > After a long time I tried to build a Windows 32bit VM (VS2017) and
>>> failed;
>>>
>>> I'm somewhat surprised as I thought someone was actively doing Windows
>>> 32-bit builds out there, plus there are shared code changes that should
>>> also have been caught by non-Windows 32-bit builds. :(
>>>
>>
>> AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017 to
>> do so and have hit the same issues (Thomas beat us to reporting!).
>>
>>
> Still curious what you actually build, since I believe not all of the
> issues are related to vs2017.
>
> Do you build release only or also debug? Do you build with
> warnings-as-errors disabled?
>
>
>> Hopefully, we'll have that nightly warning system in place for you going
>> forward soon.
>>
>>
> That would be helpful.
>
> Cheers, Thomas
>
>
>> Cheers,
>> Martijn
>>
>

Re: RFR(xs): 8221375: Windows 32bit build (VS2017) broken

[Martijn Verburg]

Hi all,

Snipping much, but commenting on one statement inline below.

On Mon, 25 Mar 2019 at 01:58, David Holmes  wrote:

> Hi Thomas,
>
> A few queries, comments and concerns ...
>
> On 25/03/2019 6:58 am, Thomas Stüfe wrote:
> > Hi all,
> >
> > After a long time I tried to build a Windows 32bit VM (VS2017) and
> failed;
>
> I'm somewhat surprised as I thought someone was actively doing Windows
> 32-bit builds out there, plus there are shared code changes that should
> also have been caught by non-Windows 32-bit builds. :(
>

AdoptOpenJDK is building Win-32 but we only recently swapped to VS2017 to
do so and have hit the same issues (Thomas beat us to reporting!).

Hopefully, we'll have that nightly warning system in place for you going
forward soon.

Cheers,
Martijn

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Martijn Verburg]

Hi Kim,

I like this initiative.  I'm wondering if some of these rules can be easily
codified or written into a jcheck style checker (ccheck?) so that Authors
can adhere to the conventions and not rely on a Human review to pick out
where that convention isn't met.

Cheers,
Martijn


On Wed, 3 Oct 2018 at 20:13, Kim Barrett  wrote:

> I've submitted a JEP for
>
> (1) enabling the use of C++14 Language Features when building the JDK,
>
> (2) define a process for deciding and documenting which new features
> can be used or are forbidden in HotSpot code,
>
> (3) provide an initial list of permitted and forbidden new features.
>
> https://bugs.openjdk.java.net/browse/JDK-8208089
>
>

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Martijn Verburg]

Hi Kevin,

Looks good, I assume as part of the work several existing javapackager bugs
will be swept up along the way?  We use javapackager and are very happy
with what it gives us considering it is "free as in beer", but there are
some significant workarounds required for code signing, especially on Mac
OS X.

Sign us (jClarity) up as early testers :-).

Cheers,
Martijn

On 1 June 2018 at 08:53, Alan Bateman  wrote:

> On 31/05/2018 01:10, Kevin Rushforth wrote:
>
>> I would like to propose the following Draft JEP [1] for discussion.
>>
>> JDK-8200758: Packaging Tool
>>
>> This is intended as a JDK-scope replacement for the existing javapackager
>> tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and
>> was delivered as part of the JavaFX build. The javapackager tool has been
>> removed from Oracle JDK 11 along with the removal of JavaFX.
>>
>> Comments on this JEP are welcome. It is currently not targeted for a
>> specific release, but we are aiming for JDK 12.
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>
>> I read through the draft.
>
> The Goals and Non-Goals looks very reasonable.
>
> The Summary includes "self-contained Java Server ... applications" but the
> JEP doesn't say too much about that part. Can we assume it can be started
> and stopped with /etc/init.d or equivalent scripts, logs with the server
> output etc? A general observation is that most of the issues around
> end-user/GUI applications are clearly documented in the draft, the headless
> application environment case less so. It makes me wonder if this JEP should
> be split so that it initially focuses on the former.
>
> I think it would be useful if the JEP explained what an "application" is.
> Is it a JAR file (with a Main-Class) that is deployed on the class path?
> Can it be a module? What about modules and libraries that the application
> uses. Users of javapackager might know these things but readers of the JEP
> may not.
>
> The JEP mentions that JavaFX will be removed in JDK 11. I assume this
> should be clarified so that it's clear it will no longer be shipped in
> Oracle's JDK. It's a none issue for those using OpenJDK builds as the the
> JavaFX modules were never bundled/imported by default.
>
> There are several references to "server JRE" that probably should be
> clarified as this notion does not exist in OpenJDK. It may be that the JEP
> just needs to clearer as to the modules that it links into the run-time
> image.
>
> There are several references to "application launcher" and "native
> launcher". At some point we need to work out some issues with jlink as it
> it will need to generate native launchers too. The JEP could list it as an
> issue as the development of this JEP will at least touch on some of this.
>
> The draft doesn't have a section on testing. If someone is building
> OpenJDK then will they will require additional tools in the build
> environment and can the tests be run without manual interaction? Also how
> about a developer using the tool, will the generated native packages be
> easy to un-install so they can easily test in a local environment?
>
> -Alan
>

Re: RFR 8190378: Java EE and CORBA modules removal

[Martijn Verburg]

One could almost shed a tear - of joy!  This is exactly the use case for
the module system that the developer community at large will understand.
Thanks for this change and a leaner meaner JDK.

Cheers,
Martijn

On 8 February 2018 at 13:37, Lance Andersen 
wrote:

>
> > On Feb 8, 2018, at 3:04 AM, Alan Bateman 
> wrote:
> >
> > On 07/02/2018 16:57, Lance Andersen wrote:
> >> Hi all,
> >>
> >> I think we are at a point where we are ready to start reviewing  the
> changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188,
> has been  targeted to JDK 11.
> >> The CSR for removing the modules has been approved:
> https://bugs.openjdk.java.net/browse/JDK-8193757 <
> https://bugs.openjdk.java.net/browse/JDK-8193757>
> >>
> >>  The open webrev can be found at:  http://cr.openjdk.java.net/~
> lancea/8190378/open_changes/  lancea/8190378/open_changes/>
> >>
> > 800 KLOC deleted, wonderful!
> >
> > The update to technology-summary.html page means its html title no
> longer matches the contents. We should probably change it to "JCP
> Technologies in JDK 11" for now.
>
> I updated the webrev. Thanks for catching that (btw we missed this for JDK
> 10)
> >
> > The removal of test cases from the tests in tools/launcher/modules
> removes most of the test coverage for the upgrade module path. We'll need
> to replace these sub-tests. Can you create an issue to track that?
>
> I can do that
> >
> > Everything else looks good and it's okay to track residual issues with
> other JIRA issues. I think the important thing is to get this monster patch
> into JDK builds soon so that libraries and the eco system can start to
> adjust.
>
> Thank you Alan for the review
>
> Best
> Lance
> >
> > -Alan
>
>  
>   <
> http://oracle.com/us/design/oracle-email-sig-198324.gif>
>  Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> lance.ander...@oracle.com 
>
>
>
>

Re: RFR(s): 8177681: Remove methods Runtime.getLocalized{Input, Output}Stream

[Martijn Verburg]

That must be oddly satisfying :-D

Cheers,
Martijn

On 7 December 2017 at 03:35,  wrote:

> 2017/12/6 17:33:36 -0500, stuart.ma...@oracle.com:
> > Please review the removal of these methods, which were part of an
> obsolete
> > internationalization mechanism. They were deprecated in JDK 1.1 and
> deprecated
> > for removal in JDK 9. As far as I can see, there is no usage of these
> methods
> > anywhere.
>
> As the developer responsible for deprecating these methods
> in JDK 1.1 -- way back in 1996 --- I heartily approve of this
> change!
>
> - Mark
>

JDK-6253001 - Joinrowset bug - question on whether test code has been migrated?

[Martijn Verburg]

Hi all,

The Adoption Group is having a go at collaboratively walking through the
process of resolving an open bug with the view of writing up the steps for
folks new to OpenJDK.

We picked https://bugs.openjdk.java.net/browse/JDK-6253001 - a fairly
simple, low priority joinrowset bug reported in the sql area.  Our
intention is to investigate the bug, reproduce it and *if* a fix is
required wait until the jdk 10 forests open to submit it there (as it's
only a P4).

-

Of course with older bugs there is a hidden history :-).  The original test
is listed as living in:

com.sun.rowset.tests.smoke.joinrowset.joinrowset3.JoinRowSet3.testJoinRowSet22

However we're unable to find that exact test which means that either:

1.) It's an internal Sun/Oracle test
2.) It's been migrated / replaced by one of the tests in
*jdk/javax/sql/testing/test/rowset/joinrowset/JoinRowSetTests.java*

Does anyone familiar with the tests around the SQL package know the history
here?

Cheers,
Martijn

Re: On what issues could I help clean up for JDK 9

[Martijn Verburg]

Thanks Claes!

That's helpful, we'll pick a few of these over on adoption-discuss and come
back here to start a discussion on the relevant issue(s) before we start.

Cheers,
Martijn

On 2 December 2016 at 13:12, Claes Redestad 
wrote:

> Hi,
>
> I'd suggest start looking at requests for code cleanup, performance
> optimizations or similar that doesn't
> alter any public semantics (such as adding public APIs or subtly changing
> the behavior of existing
> ones).
>
> A few simple JBS searches lists at least some things that look tempting:
>
> "Cleanup":
> https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22Clea
> nup%22%20%26%26%20status%20in%20(Open)%20and%20assignee%20is%20EMPTY
>
> "Optimize":
> https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22Clea
> nup%22%20%26%26%20status%20in%20(Open)%20and%20assignee%20is%20EMPTY
>
> Some, mostly hotspot engineers, use the "starter" label to mark issues
> thought to be good candidates for someone new to the project (this doesn't
> necessarily
> mean "easy"):
> https://bugs.openjdk.java.net/issues/?jql=labels%20in%20(%22
> starter%22)%20%26%26%20status%20in%20(Open)
>
> Hope this helps!
>
> /Claes
>
> On 2016-12-01 22:58, Patrick Reinhart wrote:
>
>> Hi there,
>>
>> I wanted to ask if there is a simple JBS query to find small  clean up
>> parts to help with?
>>
>> Seems to me a good starting point for some „hacking-on-the-OpenJDK-sessio
>> ns“
>>
>>
>> -Patrick
>>
>
>

Re: On what issues could I help clean up for JDK 9

[Martijn Verburg]

There's no JBS query that I know of (I think in the distant past we
discussed adding a low hanging fruit 'Duke' tag?).

Cheers,
Martijn

On 1 December 2016 at 21:58, Patrick Reinhart  wrote:

> Hi there,
>
> I wanted to ask if there is a simple JBS query to find small  clean up
> parts to help with?
>
> Seems to me a good starting point for some „hacking-on-the-OpenJDK-
> sessions“
>
>
> -Patrick

Re: Java language and API improvements

[Martijn Verburg]

Hi Alberto,

Further to this, all of these have been proposed in one form or another
previously during Project Coin during Java 7's development.  I suggest you
have a look at the old coin-dev archives (http://mail.openjdk.java.net/
pipermail/coin-dev/) to see why they weren't taken on board (or were
deferred).

Cheers,
Martijn

On 4 December 2015 at 18:28, Jonathan Yu  wrote:

> Hi Alberto,
>
> It might be easier to discuss these proposals by separating them into
> individual emails, to help keep things focussed.  I'm not even sure if this
> is the right list for Java language discussions.
>
> I'm not an expert but just sharing some quick thoughts...
>
> On Fri, Dec 4, 2015 at 10:22 AM, Alberto Otero Rodríguez <
> alber8...@gmail.com> wrote:
> >
> > *3) Switch with blocks*
> >
> > I think there should be a switch made with blocks in order to permit
> > using variables with the same name and avoid the problems of not putting
> a
> > break. It would be something like:
> >
> > switch(x)
> > {
> > case(1)
> > {
> > int i = 1;
> > ...
> > }
> > case(2)
> > {
> > int i = 2;
> > ...
> > }
> > default
> > {
> > ...
> > }
> > }
> >
>
> This should already be doable today, e.g.
>
> switch (x) {
> case 1: {
> int i = 1;
> break;
> }
> case 2: {
> int i = 2;
> break;
> }
>
> The "break" part is unfortunate but cannot be changed without breaking
> existing code, since code that currently falls through would suddenly start
> behaving differently.
>
>
> > *4) Multiple condition ternary operator*
> >
> > I think it would be useful to be able to do this:
> >
> > String str = condition1 \ condition2 ? stringCondition1 :
> > stringCondition2 : stringElse;
> >
> >
> > Instead of:
> >
> > String str = null;
> > if(condition1)
> > {
> > str = stringCondition1;
> > }
> > else if(condition2)
> > {
> > str = stringCondition2;
> > }.
> > else
> > {
> > str = stringElse;
> > }
> >
>
> Personally, I find even a single ternary operator to sometimes be a bit
> hard to follow in code, and I think having multiple like this would be
> worse.  It can also make stepping through line-by-line in a debugger more
> difficult (a reason that I like to use lots of intermediate variables),
> even if it results in more lines of code.
>
> Cheers,
>
> Jonathan
>

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

[Martijn Verburg]

Hi Attila,

Cool, reached out to a few people (Scala & Clojure in particular) JIC they
missed it and pointed them directly at the JEP and this thread. I think the
API will be all the richer when it hits its 2nd real enemy (so to speak)
:-).

Cheers,
Martijn

On 18 October 2015 at 21:57, Attila Szegedi 
wrote:

> Sure. For what’s it worth, this is for all practical purposes Dynalink, in
> the form I’ve been developing for years as a standalone library on GitHub
> and presenting about it at JVM Language Summits over several years, so I’d
> expect a significant amount of awareness is there.
>
> The primary motivator for this JEP is that I finally came to the point
> where I want to take it out of the jdk.internal.* space and into jdk.*
> space, so it is a supported API available to others as well, not just
> Nashorn. There were already people trying to do so something with the
> jdk.internal.* APIs, e.g. <
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-March/004250.html>
> and discovering that JDK 9 is blocking that path.
>
> For quite long I was reluctant to bring it out into the open as we were
> making lots of improvements on it internally driven by real-world use
> requirements coming from Nashorn, but it was always the intent to
> eventually do so. It was just a matter of finding the right time to do it:
> after it seems to have stabilized internally (so we feel fairly confident
> that there’s nothing in the design that could be invalidated or
> incomplete), but before people really want to use it but can’t. We’re
> obviously somewhat late on “people want to use it" metric, see above linked
> e-mail, but I feel we’re now reached the right time with regard to
> stabilization.
>
> Which of course is not to say that we won’t discuss this with other
> language implementers further; getting the current machinery underlying
> Nashorn out there as an accessible API (with a lot of cleanup and
> exhaustive documentation, as befitting a supported API) is the first step,
> and then when it’s out there and people can - as somene said - kick the
> tires we can mold it further with input from the community as necessary.
>
> On a purely personal sidenote, I’m extremely excited to move forward with
> this. Maybe I’ll eventually write a (highly romanticized, of course) story
> of how Dynalink got started, but if I just look at it chronologically, it
> is something I’ve started thinking about circa 2007, wrote an initial
> prototype in 2008, and the first invokedynamic-based reformulation in 2009,
> a later iteration of which got integrated into Nashorn in 2012, and then
> developed alongside it ever since. So, it’s been part of my work life, on
> and off for good 7-8 years now. I’m obviously thrilled to be taking it to
> maturation with OpenJDK community :-)
>
> Attila.
>
>
> On Oct 17, 2015, at 1:30 PM, Martijn Verburg 
> wrote:
>
> This looks very, very promising.  Would it help to get the language
> maintainers of the most popular scripting/dynamic JVM languages involved
> ASAP?  Happy to contact Groovy, Clojure, Scala, JRuby folks (although I
> suspect many of them are on this list).
>
> Cheers,
> Martijn
>
> On 16 October 2015 at 18:35,  wrote:
>
>> New JEP Candidate: http://openjdk.java.net/jeps/276
>>
>> - Mark
>>
>
>
>

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

[Martijn Verburg]

This looks very, very promising.  Would it help to get the language
maintainers of the most popular scripting/dynamic JVM languages involved
ASAP?  Happy to contact Groovy, Clojure, Scala, JRuby folks (although I
suspect many of them are on this list).

Cheers,
Martijn

On 16 October 2015 at 18:35,  wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/276
>
> - Mark
>

Re: Updating existing JDK code to use InputStream.transferTo()

[Martijn Verburg]

Hi Patrick,

Have you posted the webrev somewhere for review?

Cheers,
Martijn

On 8 May 2015 at 23:53, Patrick Reinhart  wrote:

> Hi Pavel,
>
> I have changed the most obvious files and made a patch of each repo. I
> hope the patches will not be removed…
>
> Cheers
>
> Patrick
>
>
>
>
> > Am 07.05.2015 um 20:44 schrieb Pavel Rappo :
> >
> > Hi Patrick,
> >
> > That's a good idea! I can sponsor them no problem.
> >
> > -Pavel
> >
> >> On 7 May 2015, at 19:13, Patrick Reinhart  wrote:
> >>
> >> Hi there,
> >>
> >> A couple months ago the transferTo() method was added to the JDK. I’m
> regularly joining the local hacker garten and wanted to ask if it maybe
> would be a good task to clean up the JDK code to use this method in such a
> session. Would someone sponsor such changes to be checked in? I would
> suggest that I would post a diff for each changed class to the
> core-libs-dev list.
> >>
> >> Cheers
> >>
> >> Patrick
> >
>
>
>

Low hanging fruit in JBS for the Adoption Group Hackdays to tackle?

[Martijn Verburg]

Hi all,

We had a short discussion in Adoption Group about having its members
triaging issues in JBS to identify low-hanging fruit for new OpenJDK
developers to tackle.

Dalibor sensibly suggested that each project/group was far more familiar
with which issues would be appropriate and that we should simply list those
recommended issues in the Adoption Wiki.

So I'm starting by asking core-libs as I believe it covers the part of
OpenJDK that is most accessible to new OpenJDK developers (please correct
me if I'm wrong!).

FYI - Currently London runs a hackday 1/month and several other user groups
host more ad-hoc events.  We're looking to expand this programme globally,
but would like to firstly have a list of concrete JBS issue for people to
tackle.

Q:  Do some members of this group have some low hanging fruit issues they'd
like to nominate?

Cheers,
Martijn

Re: JDK 9 RFR of JDK-8071434: doc updates for java.lang.Object

[Martijn Verburg]

Perhaps the authors in question would be happy to have a publicly hosted
snippet of that useful information?  I have both books but can appreciate
that there's a *large* number of Java devs who can't afford or get access
to those.

Cheers,
Martijn

On 29 January 2015 at 21:03, Roger Riggs  wrote:

> Hi Joe,
>
> Looks fine (though I don't have the books to verify the references).
>
> Roger
>
>
> On 1/29/2015 3:53 PM, joe darcy wrote:
>
>> Hello,
>>
>> Please review a few doc updates for java.lang.Object:
>>
>>  JDK-8071434: doc updates for java.lang.Object
>> http://cr.openjdk.java.net/~darcy/8071434.0/
>>
>> Patch below.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/java.base/share/classes/java/lang/Object.java 2015-01-29
>> 12:50:41.099429597 -0800
>> +++ new/src/java.base/share/classes/java/lang/Object.java 2015-01-29
>> 12:50:40.771265589 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1994, 2015, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -86,12 +86,11 @@
>>   * for unequal objects may improve the performance of hash
>> tables.
>>   * 
>>   * 
>> - * As much as is reasonably practical, the hashCode method defined by
>> - * class {@code Object} does return distinct integers for distinct
>> - * objects. (This is typically implemented by converting the internal
>> - * address of the object into an integer, but this implementation
>> - * technique is not required by the
>> - * Java™ programming language.)
>> + * As much as is reasonably practical, the hashCode method defined
>> + * by class {@code Object} does return distinct integers for
>> + * distinct objects. (The hashCode may or may not be implemented
>> + * as some function of an object's memory address at some point
>> + * in time.)
>>   *
>>   * @return  a hash code value for this object.
>>   * @see java.lang.Object#equals(java.lang.Object)
>> @@ -344,10 +343,11 @@
>>   * ... // Perform action appropriate to condition
>>   * }
>>   * 
>> - * (For more information on this topic, see Section 3.2.3 in Doug
>> Lea's
>> - * "Concurrent Programming in Java (Second Edition)" (Addison-Wesley,
>> - * 2000), or Item 50 in Joshua Bloch's "Effective Java Programming
>> - * Language Guide" (Addison-Wesley, 2001).
>> + *
>> + * (For more information on this topic, see section 14.2,
>> + * Condition Queues, in Brian Goetz and others'"Java Concurrency in
>> + * Practice" (Addison-Wesley, 2006) or Item 69 in Joshua Bloch's
>> + * "Effective Java (Second Edition)" (Addison-Wesley, 2008).
>>   *
>>   * If the current thread is {@linkplain
>> java.lang.Thread#interrupt()
>>   * interrupted} by any thread before or while it is waiting, then an
>>
>>
>

Re: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in jdk.rmic module

[Martijn Verburg]

Hi Amy,

Thanks - appreciate you digging into the history!

Cheers,
Martijn

On 29 January 2015 at 11:51, Amy Lu  wrote:

>  Thank you Martijn for looking into this.
>
>  The code will be reexamined and fixed later in
>  JDK-8071911: Fix deprecation warnings in jdk.rmic module
>
>  See more background (which I should have given):
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html
>
>  Thanks,
>  Amy
>
>
> On 1/29/15 7:14 PM, Martijn Verburg wrote:
>
> Hi Amy,
>
>  Idle curiosity here - are the warnings being suppressed because there is
> no way of 'resolving' them?
>
>  Cheers,
> Martijn
>
> On 29 January 2015 at 03:09, Amy Lu  wrote:
>
>> I updated the webrev, suppress deprecation warnings for
>> jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered.
>>
>> Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/
>>
>> Thanks,
>> Amy
>>
>> On 1/19/15 2:31 PM, Amy Lu wrote:
>>
>>> Please review these changes to address a few stray deprecation warnings
>>> in the jdk.rmic module:
>>>
>>> JDK-8069255: Suppress deprecation warnings in jdk.rmic module
>>> http://cr.openjdk.java.net/~amlu/8069255/webrev.00/
>>>
>>> I also need a sponsor for this.
>>>
>>> Thanks,
>>> Amy
>>>
>>>
>>
>
>

Re: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in jdk.rmic module

[Martijn Verburg]

Hi Amy,

Idle curiosity here - are the warnings being suppressed because there is no
way of 'resolving' them?

Cheers,
Martijn

On 29 January 2015 at 03:09, Amy Lu  wrote:

> I updated the webrev, suppress deprecation warnings for
> jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered.
>
> Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/
>
> Thanks,
> Amy
>
> On 1/19/15 2:31 PM, Amy Lu wrote:
>
>> Please review these changes to address a few stray deprecation warnings
>> in the jdk.rmic module:
>>
>> JDK-8069255: Suppress deprecation warnings in jdk.rmic module
>> http://cr.openjdk.java.net/~amlu/8069255/webrev.00/
>>
>> I also need a sponsor for this.
>>
>> Thanks,
>> Amy
>>
>>
>

Re: RFR 8065998: Avoid use of _ as a one-character identifier

[Martijn Verburg]

I know this is descending into bike shedding - but I like that split of
definition, shamelessly stealing for my future projects, thanks!

Cheers,
Martijn

On 1 December 2014 at 13:01, Andreas Lundblad 
wrote:

> On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
> > Hi,
> >
> > In a preparation for JDK-8061549, I'd like to rename all uses of '_'
> > as a one-character identifier in the jaxp and jdk repositories. All
> > the uses I was able to find are in tests, and the identifier is used
> > as a name of a catch parameter. The proposed new name is "ignore",
> > but if a different name would be more appropriate, I'll be happy to
> > use it.
>
> To me "ignore" signals "I don't care if this exception occurred." In
> tests, when an exception *should* occurr, I usually name the variable
> "expected". Ignore is a bit shorter though, so in the end it's a matter of
> taste I guess.
>
> -- Andreas
>

Re: RFR 8065998: Avoid use of _ as a one-character identifier

[Martijn Verburg]

If it helps "ignore" is a bit of a defacto std that I've seen many projects
use, it conveys exactly the right intent :-).

Cheers,
Martijn

On 1 December 2014 at 12:10, Jan Lahoda  wrote:

> Hi,
>
> In a preparation for JDK-8061549, I'd like to rename all uses of '_' as a
> one-character identifier in the jaxp and jdk repositories. All the uses I
> was able to find are in tests, and the identifier is used as a name of a
> catch parameter. The proposed new name is "ignore", but if a different name
> would be more appropriate, I'll be happy to use it.
>
> Webrev for the jaxp repository:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jaxp/
>
> Webrev for the jdk repository:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jdk/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8065998
>
> Any comments are appreciated.
>
> Thanks,
> Jan
>

Re: Process API Updates (JEP 102)

[Martijn Verburg]

Hi Roger,

Is there a short survey we could send out to the wider dev community on
this one?  I think just about every day to day Java developer has had to
use Process at some stage in their career.

Cheers,
Martijn


On 24 March 2014 21:11, roger riggs  wrote:

> Hi,
>
> I'm starting to work on JEP 102, Process API Updates for JDK 9.
> The use cases identified include test execution and build systems such
> as Jtreg and Hudson/Jenkins. And there is a use-case for using Java
> to monitor the health of a more complex system where the processes
> are not spawned by the same manager.
>
> The current API of Process itself is pretty complete with the addition of
> a getPid
> method to enable identification of subprocesses spawned by the application
> and allow external identification.  It will not be possible to intercept
> the input,
> output and error streams of an arbitrary process.
>
> From the scope of the JEP, a fairly simple API seems sufficient.
>  - Enumerate the direct children
>  - The rest of the functions are similar to Process
>- to terminate a process, forcibly and normally
>- to destroy a process and all of its children recursively
>- to check if one is alive
>- to waitFor for termination and retrieve the exit status
>
> Are there use cases for which this is insufficient?  Please comment.
>
> Thanks, Roger
>
>

Re: A hole in the serialization spec

[Martijn Verburg]

In the long term will it be possible to just mark j.u.Date as deprecated
since the new Date and Time libs have come in?  Avoids having to fix old
behaviour that folks might be relying on.

Cheers,
Martijn


On 14 February 2014 18:56, David M. Lloyd  wrote:

> Interestingly, if the behavior in this case was to write empty values on
> the write side and read and discard on the read side, both the behavior and
> the serialized format of java.util.Date would be identical to today; though
> other pathological classes might be incompatible, they were already in
> undefined-land.
>
>
> On 02/14/2014 12:01 PM, David M. Lloyd wrote:
>
>> Yes, however given that the lack of reading/writing fields makes it
>> undefined *in general*, you can only say "the behavior is defined as
>> long as this undefined behavior is actually defined in this (risky)
>> manner".
>>
>> Put another way, since the behavior of not reading/writing fields is not
>> defined, this class is then by spec not portable between JVMs (after
>> all, undefined behavior could mean anything at all).  That's why I was
>> saying that the spec should define exactly what will physically happen
>> if you do this (from both the perspective of the "other end" of the
>> serialization API, *and* the wire protocol), even if it's considered
>> poor practice - because then at least you have guaranteed
>> interoperability (which becomes even more important with the knowledge
>> that JDK classes have this issue).
>>
>> On 02/14/2014 10:31 AM, roger riggs wrote:
>>
>>> Hi David,
>>>
>>> I would quibble that the serialized form of java.util.Date is defined.
>>> The behavior is defined by the writeObject and readObject methods.
>>> They write and read a time computed from and restored to the state of
>>> the object.
>>>
>>> Roger
>>>
>>> On 2/14/2014 10:56 AM, David M. Lloyd wrote:
>>>
 On 02/13/2014 11:38 AM, David M. Lloyd wrote:

> On 02/13/2014 10:29 AM, Chris Hegarty wrote:
>
>> On 12 Feb 2014, at 15:24, David M. Lloyd 
>> wrote:
>>
>>  That's a quote from the serialization spec.  I take it to mean,
>>> "Don't write fields and everything might go to hell".  In practice,
>>> if the reading side doesn't read fields, things end up more or less
>>> OK, as evidenced by various classes in the wild.  But it's not hard
>>> to imagine a scenario in which a class change could cause protocol
>>> corruption.
>>>
>>> I think the specifics of the quote relate to this kind of class
>>> change; in particular, if a class is deleted from the hierarchy on
>>> the read side, and that class corresponds to the class that had the
>>> misbehaving writeObject, I suspect that things will break at that
>>> point as the read side will probably try to consume and discard the
>>> field information for that class, which will be missing (it will
>>> start reading the next class' fields instead I think).
>>>
>>
>> Yes, possibly. And who knows what fields/values may be read and
>> mistaken for the wrong object in the hierarchy. So ‘undefined'
>> behaviour seems right to me.
>>
>
> I think the behavior is well-defined, just "bad", which is my
> point.  If
> the exact current is spec'd out as-is then at least we can be
> assured of
> the same bad behavior across implementations.  If the behavior is
> changed such that fields are read/written but discarded, without
> updating the spec, then the "undefined" behavior at least becomes
> safer.
>   If the behavior is changed, *and* the spec is updated, then we get
> both benefits, but at the cost that all previous implementations will
> not be compliant with the spec.
>
> All options seem to have a cost though.
>

 In the JDK, java.util.Date does not read/write fields.  Perhaps others
 as well.  Given that the behavior is presently undefined, that means
 the serialized representation of java.util.Date (and any other such
 non-conforming classes) are also undefined.


>>>
>>
>>
>
> --
> - DML
>

Re: JAXP JEP: Update Xerces implementation in the JDK

[Martijn Verburg]

Makes sense - thanks for the extra explanation!

Cheers,
Martijn


On 3 February 2014 22:49, Alan Bateman  wrote:

> On 03/02/2014 21:13, Martijn Verburg wrote:
>
>> Hi Huizhe,
>>
>> Is there a possibility to look at having a more loosely coupled
>> relationship between Xerces and what is core JDK? I'm thinking about (in
>> combination with) Jigsaw that you could allow the Xerces components to be
>> kept up to date more often (assuming API compatibility etc is retained).
>>
>>  Just to mention that are already service provider interfaces so you can
> deploy with other parser libraries (or a more up to date Xerces). One of
> things that we did as part of preparing for modules (JEP 162, JDK 8) was to
> rev the JAXP API to clean up these the service provider interfaces (for
> SAX, DOM, XSLT, XPath, Validation, Streaming, Datatype) and specify the use
> of the ServiceLoader. So we're in a much better place now.
>
> As regards getting the Xerces code in OpenJDK in sync with the upstream
> project then that clearly would be desirable and probably more of a longer
> term goal. I'll let Joe speak to how much the code has diverged but one
> area of difference is that the original Apache code wasn't really intended
> to ever be on the boot class path or run with a security manager. In any
> case, I think this JEP is a good step as it brings the implementations
> closer and also revs the support on a number of standards.
>
> -Alan
>

Re: JAXP JEP: Update Xerces implementation in the JDK

[Martijn Verburg]

Hi Huizhe,

Is there a possibility to look at having a more loosely coupled
relationship between Xerces and what is core JDK? I'm thinking about (in
combination with) Jigsaw that you could allow the Xerces components to be
kept up to date more often (assuming API compatibility etc is retained).

Cheers,
Martijn


On 3 February 2014 20:19, huizhe wang  wrote:

> Hi,
>
> We'd like to propose a JEP to update the Xerces implementation in the JDK
> and bring it to up to date to the current Xerces release. Please review the
> draft.
>
> Thanks,
> Joe
>
>

Re: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources.

[Martijn Verburg]

As a mostly ;-) silent observer on this list I just wanted to say "Thank
You" to everyone for continuing the diligent work to fix issues like this.
I've seen a host of really useful small improvements go in recently (and
docs definitely count as well) - it doesn't go unnoticed!

Cheers,
Martijn


On 8 October 2013 21:06, Alan Bateman  wrote:

> On 08/10/2013 18:19, Daniel Fuchs wrote:
>
>> Hi,
>>
>> Please find below a fix for:
>>
>> 8024704: Improve API documentation of ClassLoader and ServiceLoader
>>  with respect to enumeration of resources.
>> 
>> >
>>
>> This is a clarification of the implementation of the
>> ServiceLoader.iterator() method, as well as non normative advice
>> for ClassLoader subclasses overriding getResource() or getResources()
>> to consider overriding the other method in order to keep them
>> consistent with each other.
>>
>> 
>> >
>>
> As background to others, the motive for this one stems from a small
> compatibility issue that arose with the JAXP changes to use ServiceLoader
> (it was previous foraging for service configuration files itself). The
> compatibility issue arises with ClassLoader implementations where
> getResource and getResources are inconsistent, and in the JAXP case
> uncovered a server that located an unexpected XML parser.
>
> Daniel - in the @apiNote on getResource it reads "the implementations
> ensure" where it should be "the implementation ensures" or "implementations
> should ensure". Otherwise the wording looks okay to me. Conventions haven't
> been established yet but I would think that @apiNote is a case where you
> can use the full
> line.
>
> -Alan.
>

Re: about JavaOne2012 Finding and Solving Java Deadlocks

[Martijn Verburg]

I've pinged Heinz - M


On 31 October 2012 20:08, Jim Gish  wrote:

> I'd be very interested in this too, and would also like to see the slides.
>
> Thanks,
>Jim
>
> On 10/15/2012 05:50 PM, Mike Duigou wrote:
>
>> The session was a hands on lab so was not recorded that I can tell.
>>
>> Here's the official session page:
>>
>> https://oracleus.activeevents.**com/connect/search.ww?event=**
>> javaone#loadSearch-event=**javaone&searchPhrase=&**
>> searchType=session&tc=0&**sortBy=&p=&i%2811424%29=18653&**
>> i%2810050%29=&i%2810090%29=&i%**2810092%29=&i%2811842%29=&i%**2810086%29=
>>
>> Some of the presenters are subscribers to this list. If they don't
>> respond with the slides perhaps you can contact them.
>>
>> Mike
>>
>> On Oct 13 2012, at 03:44 , fuyou wrote:
>>
>>  hi all
>>>
>>> I  am very interested in session of  HOL6500 - Finding and Solving Java
>>> Deadlocks(JavaOne 2012) .how can i watch video or download  slides.
>>>
>>> Thanks!
>>>
>>> --
>>>==**===
>>>
>>>   fuyou001
>>> Best Regards
>>>
>>
> --
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.g...@oracle.com
>
>

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

[Martijn Verburg]

Hi all,

> On 08/23/2012 11:46 PM, Dan Xu wrote:
>>
>> Please review the fix of CR 7193406 at
>> http://cr.openjdk.java.net/~dxu/7193406/webrev/.
>>
>> It cleans up warnings in the following java files.
>>
>>src/share/classes/java/io/FilePermission.java
>>src/share/classes/java/util/ArrayDeque.java
>>src/share/classes/java/util/Arrays.java
>>src/share/classes/java/util/Collections.java
>>src/share/classes/java/util/HashMap.java
>>src/share/classes/java/util/JumboEnumSet.java
>>src/share/classes/java/util/PriorityQueue.java
>>src/share/classes/java/util/PropertyResourceBundle.java
>>src/share/classes/java/util/jar/JarVerifier.java
>>src/share/classes/java/util/jar/Pack200.java
>>src/share/classes/sun/util/PreHashedMap.java
>>
>>
>>
>> And it enables fatal warning flag in the following make file.
>>
>>make/java/jar/Makefile
>>
>>
>> In FilePermission.java file, I make one change to its method signature,
>>
>>public Enumeration elements()  ==> public Enumeration
>>elements()
>>
>>
>> I am not sure whether it will cause an issue of backward compatibility.
>> Please advise. Thanks!
>>
>> - Dan
>
>
> Hi Dan,
> I'm not sure to like the fact that you introduce some local variables just
> to get ride of some warnings given that Hotspot compilers are sometimes
> sensitive to that.
> I think this practice should be discussed on this list before committing
> this changeset.
>
> so is it a good idea to add a temporary local variable to fix a generics
> warning or should @SuppressWarnings should be set on the whole method ?
>
> Rémi

Is it worth analysing the byte code to see the potential impact of
this extra local
variable?  We did that for a bunch of the javac warnings cleanup in London and
had a defacto rule of 'no byte code changes' or if there was one we'd get a few
Hotspot enthusiasts to analyse it.

Cheers,
Martijn

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi Stuart,

> 
>
> The java.util patches look good and are almost ready to go in. The only
> issue is how to format the Contributed-by line in the changeset comment.
> What I have so far for the comment is:
>
> 7176907: additional warnings cleanup in java.util, java.util.regexp,
> java.util.zip
> Reviewed-by: forax, khazra, smarks
> Contributed-by: ???
>
> The contributed-by line takes one or more email addresses or email/name
> pairs. For an earlier contribution from LJC, see here [1]. This isn't a
> terribly big deal but I want to make sure that credit goes where it's due.
> Can you tell me what I should put for the contributed-by line?

Main Sarkar - sadhak001ATgmail.DOTcom

> The warnings in java.text have already been fixed by Deepak Bhole's
> changeset [2]. Not a problem, this took two minutes to figure out.

Cool, we've adjusted our workflow to take this into account.

> There were a couple questions from earlier in the thread.
>
> On the discussion of when the compiler issues switch fallthrough warnings,
> from what I can tell, the compiler issues a warning whenever there is actual
> code in a case that doesn't end with break, continue, return, or throw. This
> seems independent of whether what follows is another case or the 'default'
> case. If there are several case clauses together with no intervening code,
> this isn't considered a fallthrough and thus there is no warning. This make
> sense, as sometimes you want several different cases to be handled by the
> same code. For example,
>
> switch (ch) {
> case 'a':
> // no warning here
> case 'b':
> someActualWork();
> break;
> // ...
> }

Understood, made sense to us as well.

> Regarding whether there is a style checker for indentation and spacing, I'm
> not aware of a good one that I can recommend. We generally adhere to the
> (very old) Java Coding Conventions [3]. I think most people just deal with
> style issues manually by hand and by eye; I know I do. We do run jcheck [4]
> on every incoming changeset, but the only things it checks in files'
> contents are for trailing whitespace, and CR (as opposed to LF) and TAB
> characters.

OK, we've added jcheck to the list of things to run going forwards.
Perhaps in the
future one of our folks can put together a checkstyle ruleset for
core-lib (controversial!)...
:-)

Thanks for getting this patch merged!

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi all,

We've been working on improving the workflow for our patch review
system and so the new locations for the patches are at:

https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_text.patch
https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_util.patch

Cheers,
Martijn

On 27 June 2012 08:58, Martijn Verburg  wrote:
> Hi Kurchi,
>
>> Thanks for updating this. This looks good to me. I guess Stuart will be
>> sponsoring the patch.
>
> For his sins he's kindly offered to do so yes :-)
>
>> There are a couple of other switch statements in
>>  src/share/classes/java/util/regex/Pattern.java.
>> which are not throwing fallthrough warnings (in Netbeans at least),
>> although there is fallthrough happening from one case to another. From what
>> I notice, only if there is a break statement
>> missing before the "default" case, does Netbeans throw some warning. Is the
>> fallthrough warning technically
>> supposed to be thrown only when the logic falls through to the default case
>> then?
>
> That's my understanding with the javac compiler yes. I think it was the 
> balance
> that the javac folk thought was a sensible compromise in terms of not
> generating
> too many false positive warnings.
>
> Cheers,
> Martijn

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi Kurchi,

> Thanks for updating this. This looks good to me. I guess Stuart will be
> sponsoring the patch.

For his sins he's kindly offered to do so yes :-)

> There are a couple of other switch statements in
>  src/share/classes/java/util/regex/Pattern.java.
> which are not throwing fallthrough warnings (in Netbeans at least),
> although there is fallthrough happening from one case to another. From what
> I notice, only if there is a break statement
> missing before the "default" case, does Netbeans throw some warning. Is the
> fallthrough warning technically
> supposed to be thrown only when the logic falls through to the default case
> then?

That's my understanding with the javac compiler yes. I think it was the balance
that the javac folk thought was a sensible compromise in terms of not
generating
too many false positive warnings.

Cheers,
Martijn

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi all,

Apologies for the delay.  So it was simply a case of human error in
missing that last fallthrough (we wanted to double check that our
warnings script wasn't failing, hence the delay in getting back to
you). I've respun the patch with the extra SuppressWarning.

Hopefully the patch is complete now.

Cheers,
Martijn

On 20 June 2012 17:18, Martijn Verburg  wrote:
> We'll look into it, hopefully have an answer for you shortly - M
>
> On 20 June 2012 17:07, Kurchi Subhra Hazra
>  wrote:
>> Hi,
>>
>>   I was just going through the patches, there are some more fallthrough
>> cases in
>> src/share/classes/java/util/regex/Pattern.java.(for example in line 2247).
>> Are these not generating warnings?
>>
>> - Kurchi
>>
>>
>> On 6/20/12 7:30 AM, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> Apologies, I didn't check that attachments were stripped.  The patches
>> can be found at:
>>
>>
>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch
>>
>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch
>>
>> Cheers,
>> Martijn
>>
>> Hi Martijn,
>> the two patches looks good.
>>
>> A minor nit, why is there a space between the '(' and the readUByte() in
>> readUShort.
>>
>> Thanks for the quick review! No reason on the whitespace, I've fixed that
>> now.
>>
>> Quick question.  Is there a checkstyle or jcheck that we should be
>> applying to any corelib patches going forwards?
>>
>> Cheers,
>> Martijn
>>
>>

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

We'll look into it, hopefully have an answer for you shortly - M

On 20 June 2012 17:07, Kurchi Subhra Hazra
 wrote:
> Hi,
>
>   I was just going through the patches, there are some more fallthrough
> cases in
> src/share/classes/java/util/regex/Pattern.java.(for example in line 2247).
> Are these not generating warnings?
>
> - Kurchi
>
>
> On 6/20/12 7:30 AM, Martijn Verburg wrote:
>
> Hi all,
>
> Apologies, I didn't check that attachments were stripped.  The patches
> can be found at:
>
>
> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch
>
> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch
>
> Cheers,
> Martijn
>
> Hi Martijn,
> the two patches looks good.
>
> A minor nit, why is there a space between the '(' and the readUByte() in
> readUShort.
>
> Thanks for the quick review! No reason on the whitespace, I've fixed that
> now.
>
> Quick question.  Is there a checkstyle or jcheck that we should be
> applying to any corelib patches going forwards?
>
> Cheers,
> Martijn
>
>

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi Remi,

On 20 June 2012 15:08, Rémi Forax  wrote:
> On 06/20/2012 01:51 PM, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> Apologies, I didn't check that attachments were stripped.  The patches
>> can be found at:
>>
>>
>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch
>>
>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch
>>
>> Cheers,
>> Martijn
>
>
> Hi Martijn,
> the two patches looks good.
>
> A minor nit, why is there a space between the '(' and the readUByte() in
> readUShort.

Thanks for the quick review! No reason on the whitespace, I've fixed that now.

Quick question.  Is there a checkstyle or jcheck that we should be
applying to any corelib patches going forwards?

Cheers,
Martijn

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi all,

Apologies, I didn't check that attachments were stripped.  The patches
can be found at:

https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch
https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch

Cheers,
Martijn

On 20 June 2012 09:50, Martijn Verburg  wrote:
> Hi Stuart,
>
> As requested - attached are 2 patch files, one covering util, the other text.
>
> I'm aware some fixes did go in recently, so if these patches are out
> of date and need re-spinning, then please let me know.
>
> Cheers,
> Martijn (on behalf of Adopt OpenJDK)

Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Martijn Verburg]

Hi Stuart,

As requested - attached are 2 patch files, one covering util, the other text.

I'm aware some fixes did go in recently, so if these patches are out
of date and need re-spinning, then please let me know.

Cheers,
Martijn (on behalf of Adopt OpenJDK)

Re: Proposed refactoring: introduce JLS7 language features to core libs

[Martijn Verburg]

Hi all,

On 1 May 2012 10:33, Martijn Verburg  wrote:
> Hi all,
>
>> On 4/25/12 12:07 PM, Stefan Reich wrote:
>>>
>>> Hello,
>>>
>>> is there any interest to accept change sets based on OpenJDK 7 that update
>>> the java classes in jdk/src/share/classes to use
>>>
>>> * multi-catch
>>> * string switch statements as opposed to nested if statements when
>>> comparing strings with string literals
>>> * type inference by removing duplicative type information in the
>>> constructor when using generics
>>> * indexOf(int) when indexOf(String) is used with a String literal that
>>> contains only one character, and similar small-scale improvements?
>>>
>>> The proposed change sets would pass all jtreg tests. If there is interest,
>>> what would be next steps?
>>
>>
>> Hi, yes, there is interest! Thanks for raising this topic.
>>
>> In some respects this seems similar to the "Coinification" work [1] I did
>> during JDK7 development, that is, to use the then-new Project Coin features
>> in the code base of the JDK itself. The goal of that effort was to put some
>> of the Coin features to use in production code, so as to gain experience
>> with them, but not necessarily to "coinify" the entire source base. In fact
>> I've been asked how much of the code base was converted to use the new
>> features. The answer is, I don't know. I'm pretty sure that there is a lot
>> remaining to be done, though.
>>
>> (As an aside, most of the warnings work we've been doing over the past
>> several months is to clean warnings that result from the use of raw types
>> instead of generics. That is, there is lots of code lying around that hasn't
>> been updated to Java 5 generics yet! There are similar refactorings one
>> could apply for Java 5 language features, such as the enhanced-for loop,
>> enums, covariant overrides, autoboxing, etc.)
>>
>> Probably the easiest feature to get started with is diamond (formally known
>> as "type inference for generic instance creation"). It should be fairly
>> simple to find lots of examples where this can be put to use, now that there
>> are bulk change hints available in NetBeans. (Bulk changes are probably also
>> available in Eclipse and IntelliJ Idea.) The good thing about diamond is
>> that it is practically impossible to bugs when doing diamond conversion. In
>> fact, the resulting class files should be byte-for-byte identical to the
>> previous versions. In practice, though, I did join lines where appropriate,
>> since using diamond often shortened the code enough to fit on a single line
>> where it had to be split across lines before.
>>
>> There are a small number of stylistic issues that occur when using diamond;
>> see [2] and [3]. Different people have different styles, and unfortunately
>> different styles have emerged in different areas of code. The main
>> difference seems to be whether diamond is used in assignment and return
>> statements, where the use of diamond is separated from the variable
>> declaration that contains the complete type.
>>
>> In practice what this means is that you should break down your changesets to
>> apply to different functional areas, and then find the right people and the
>> right mailing list to discuss the changes beforehand. (Actually this is
>> probably good practice for any change, not just diamond.)
>>
>> Turning to the other suggestions, I'd say that multi-catch and
>> strings-in-switch are also fairly safe refactorings to propose, although
>> they probably occur much less frequently than diamond. There are some
>> subtleties with applying these refactorings, which will require more
>> scrutiny than applying diamond changes.
>>
>> For example, in some cases there is a catch of Exception that is better
>> expressed as a multi-catch of several Exception subtypes. This might make
>> for better code, but it subtly changes the behavior of the code. For
>> strings-in-switch, a null value of the switch expression results in NPE,
>> whereas (depending on the details, of course) a cascade of if-elses may end
>> up handling null differently.
>>
>> I'm not sure about the indexOf() cases you refer to. I guess I'd have to see
>> some examples before deciding whether these are worthwhile to pursue.
>>
>> In any case, thanks for taking the initiative to work on this stuff. Looking
>> forward to seeing what you come up with.
>>
>> s'marks
>>
>> [1]
>

Re: Proposed refactoring: introduce JLS7 language features to core libs

[Martijn Verburg]

Hi all,

> On 4/25/12 12:07 PM, Stefan Reich wrote:
>>
>> Hello,
>>
>> is there any interest to accept change sets based on OpenJDK 7 that update
>> the java classes in jdk/src/share/classes to use
>>
>> * multi-catch
>> * string switch statements as opposed to nested if statements when
>> comparing strings with string literals
>> * type inference by removing duplicative type information in the
>> constructor when using generics
>> * indexOf(int) when indexOf(String) is used with a String literal that
>> contains only one character, and similar small-scale improvements?
>>
>> The proposed change sets would pass all jtreg tests. If there is interest,
>> what would be next steps?
>
>
> Hi, yes, there is interest! Thanks for raising this topic.
>
> In some respects this seems similar to the "Coinification" work [1] I did
> during JDK7 development, that is, to use the then-new Project Coin features
> in the code base of the JDK itself. The goal of that effort was to put some
> of the Coin features to use in production code, so as to gain experience
> with them, but not necessarily to "coinify" the entire source base. In fact
> I've been asked how much of the code base was converted to use the new
> features. The answer is, I don't know. I'm pretty sure that there is a lot
> remaining to be done, though.
>
> (As an aside, most of the warnings work we've been doing over the past
> several months is to clean warnings that result from the use of raw types
> instead of generics. That is, there is lots of code lying around that hasn't
> been updated to Java 5 generics yet! There are similar refactorings one
> could apply for Java 5 language features, such as the enhanced-for loop,
> enums, covariant overrides, autoboxing, etc.)
>
> Probably the easiest feature to get started with is diamond (formally known
> as "type inference for generic instance creation"). It should be fairly
> simple to find lots of examples where this can be put to use, now that there
> are bulk change hints available in NetBeans. (Bulk changes are probably also
> available in Eclipse and IntelliJ Idea.) The good thing about diamond is
> that it is practically impossible to bugs when doing diamond conversion. In
> fact, the resulting class files should be byte-for-byte identical to the
> previous versions. In practice, though, I did join lines where appropriate,
> since using diamond often shortened the code enough to fit on a single line
> where it had to be split across lines before.
>
> There are a small number of stylistic issues that occur when using diamond;
> see [2] and [3]. Different people have different styles, and unfortunately
> different styles have emerged in different areas of code. The main
> difference seems to be whether diamond is used in assignment and return
> statements, where the use of diamond is separated from the variable
> declaration that contains the complete type.
>
> In practice what this means is that you should break down your changesets to
> apply to different functional areas, and then find the right people and the
> right mailing list to discuss the changes beforehand. (Actually this is
> probably good practice for any change, not just diamond.)
>
> Turning to the other suggestions, I'd say that multi-catch and
> strings-in-switch are also fairly safe refactorings to propose, although
> they probably occur much less frequently than diamond. There are some
> subtleties with applying these refactorings, which will require more
> scrutiny than applying diamond changes.
>
> For example, in some cases there is a catch of Exception that is better
> expressed as a multi-catch of several Exception subtypes. This might make
> for better code, but it subtly changes the behavior of the code. For
> strings-in-switch, a null value of the switch expression results in NPE,
> whereas (depending on the details, of course) a cascade of if-elses may end
> up handling null differently.
>
> I'm not sure about the indexOf() cases you refer to. I guess I'd have to see
> some examples before deciding whether these are worthwhile to pursue.
>
> In any case, thanks for taking the initiative to work on this stuff. Looking
> forward to seeing what you come up with.
>
> s'marks
>
> [1]
> http://stuartmarks.wordpress.com/2010/12/23/jdk7-coin-and-making-libraries-fresh-and-minty/
> [2] http://stuartmarks.wordpress.com/2011/01/24/where-can-diamond-be-used/
> [3] http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/

FYI, Stefan has kindly offered to join the Adopt OpenJDK program
(http://java.net/projects/jugs/pages/AdoptOpenJDK) and we'll all work
together of pre-review of patches, with Stuart's comments as a
starting guideline.

Cheers,
Martijn

Re: Initial preview: JEP-149 Reduced Class instance size

[Martijn Verburg]

Hi Hinkmond,

Is there a corpus of code you can look at in the embedded space to see what
ratio of real-world apps use a lot of reflection?  We have access to a
corpus in the SE space (some Cambridge PhD students that work with us) and
I know Brian/Joe et al use one internally at Oracle as well, would be an
interesting comparison.

Cheers,
Martijn


On 5 April 2012 09:07, Hinkmond Wong  wrote:

> Hi Brian,
>
> One of the issues we have in the Java Embedded group (as David points out
> in his summary), is that while on paper the theoretical max savings seems
> great (as you point out also), in practice as David points out in his note,
> this might be a wash if there are a lot more reflection using classes vs.
> non-reflection using classes in "typical" real-world applications, not the
> low or zero reflection using class ratio that happens in the theoretical
> "best case".
>
> So, a question comes up if we should judge the merit of this change on the
> theoretical "best case" scenario, or should we judge it on real-world
> applicability to "typical" apps (such as a finite set of customer surveyed
> embedded apps that we feel represent a real-world scenario).
>
>
> Thanks,
> Hinkmond
>
>
> On 4/4/12 8:28 PM, Brian Goetz wrote:
>
>> Reducing the number of SoftReferences in ReflectionHelper also seems an
>> attractive target for memory reduction.  Rather than eight soft references
>> (eight extra objects), maintaining a SoftRef to the entire RH, or at least
>> to the part of the RH that is currently SR'ed if the two non-SR'ed fields
>> can't be recomputed, would save you a whole pile of objects per class (and
>> might also reduce pressure on GC, having 8x fewer SRs to process.)
>>
>> Finally, you may be able save an extra field per Class by storing the
>> ReflectionHelper in a ClassValue on Java SE 8, rather than a field.
>>
>> On 4/4/2012 10:50 PM, David Holmes wrote:
>>
>>> http://cr.openjdk.java.net/~**dholmes/JEP-149/webrev/
>>>
>>> This is an early look at a proposed change to reduce the instance size
>>> of Java Class objects in the common case that reflection is not used.
>>>
>>> In SE 7 a java.lang.Class instance is 104 bytes on 32-bit systems. It
>>> consists of the 8-byte object header, 19 declared fields and 5 injected
>>> fields (fields added by the VM as-if they were declared in
>>> java.lang.Class but which do not appear in the Java source code). There
>>> are 10 reference fields associated with reflection caching that can be
>>> moved to a helper object with no impact on the VM or serialization
>>> protocols. Adding back a reference for the helper, that saves 9
>>> references. Notionally this is 36 bytes on 32-bit but due to 8-byte
>>> alignment it only saves 32 bytes. That gives a size of 72 bytes - a
>>> reduction of 30%. This initial modification has been prototyped for
>>> initial performance measurements.
>>>
>>> Note that if reflection is used then the amount of memory used by the
>>> Class will increase by 8-bytes - that being the additional object header
>>> of the ReflectionHelper instance. So the net gain depends on the ratio
>>> of reflection using classes to non-reflection-using classes in an
>>> application.
>>>
>>> Please note that I've put this out just before I disappear on vacation
>>> for 10 days, so if you don't see any responses from me that is why. :)
>>>
>>> Thanks,
>>> David Holmes
>>>
>>
>
> --
> Oracle 
>
> Hinkmond Wong | Consulting Member of Technical Staff
> Phone: _+1 408.276.7618_ | Fax: _+1 408.276.7674_
> Oracle Java Embedded
> 4210 Network Ci., M/S USCA22-rm2364 | Santa Clara, CA 95054
> Green Oracle 
> >
> Oracle is committed to developing practices and products that help protect
> the environment
>
>

Re: Request for Review: Warnings cleanup in java.lang.*, java.util.**

[Martijn Verburg]

FYI - The London JUG did have java.util.regex listed, but we didn't
have time to produce a patch for that area, so no clash there -
Cheers, M

On 2 December 2011 12:18, Alan Bateman  wrote:
>
> cc'ing core-libs-dev as that is the place to discuss these changes. I see on
> the sign-up sheet [1] that omajid has signed up for java.lang, maybe you are
> working together? I'll leave it to Stuart to say whether he wants to
> refactor/other changes separated from the warnings changes.
>
> One thing I'm curious about is @SuppressWarnings("BooleanConstructorCall")
> as it suggests that some other compiler, or maybe an extension in the
> NetBeans javac?
>
> -Alan
>
> [1]
> http://wikis.sun.com/display/OpenJDK/JDK8+warning+cleanup+day+%282011-12-01%29
>
>
> On 02/12/2011 11:06, David Schlosnagle wrote:
>>
>> I didn't have a chance to sign-up or submit during the official
>> warnings cleanup day, but I'm hoping that you'll still accept patches.
>> I do not have a bug number for this change.
>>
>> The webrev [1] below should resolve 208 warnings in the java.lang.*
>> and java.util.** packages. I tried to stick to fixing warnings, but
>> OCD kicked in while editing in NetBeans, so there are a few additional
>> IDE warnings fixed as well for the modified files. For example, adding
>> @Override on the relevant methods, removals of dead stores, conversion
>> to Strings in switch, StringBuffer ->  StringBuilder where localized (I
>> realize lock elision in HotSpot and JRockit should make them
>> practically equivalent, but NetBeans still complains and I assume
>> there is still some unnecessary synchronization overhead).
>> ConditionalSpecialCasing.java also has some slight refactoring to
>> utilize the updated parameterized types.
>>
>> Additionally, there was one change to
>> java.util.regex.Pattern#subFlag() that I'd like someone to review more
>> carefully as it was previously falling through the last case, but I
>> believe the last case should have had a break; to properly handle
>> other flags.
>>
>> *** 3006,3015 
>> --- 3014,3024 
>>               case 'x':
>>                   flags&= ~COMMENTS;
>>                   break;
>>               case 'U':
>>                   flags&= ~(UNICODE_CHARACTER_CLASS | UNICODE_CASE);
>> +                 break;
>>               default:
>>                   return;
>>               }
>>
>> If you want any of the additional cleanup removed from the patch or
>> other changes, please let me know.
>>
>> [1]: http://dl.dropbox.com/u/23832908/openjdk/2011-12-01/index.html
>>
>> Files modified:
>>     java/lang/Boolean.java
>>     java/lang/Byte.java
>>     java/lang/Character.java
>>     java/lang/Class.java
>>     java/lang/ConditionalSpecialCasing.java
>>     java/lang/Double.java
>>     java/lang/Float.java
>>     java/lang/Integer.java
>>     java/lang/Long.java
>>     java/lang/Short.java
>>     java/lang/System.java
>>     java/lang/ThreadLocal.java
>>     java/lang/Void.java
>>     java/util/IllegalFormatConversionException.java
>>     java/util/Locale.java
>>     java/util/regex/Matcher.java
>>     java/util/regex/Pattern.java
>>     java/util/regex/PatternSyntaxException.java
>>     java/util/regex/UnicodeProp.java
>>
>> Thanks,
>> Dave
>
>

Re: review of 7117249: java.util warnings patches from LJC/Mike Barker

[Martijn Verburg]

Hi all,

Question on contributions, I assume that as the patch is coming from Mike,
his OCA covers the rest of us?

Cheers,
Martijn

On Wednesday, 7 December 2011, Alan Bateman  wrote:
> On 07/12/2011 08:43, Michael Barker wrote:
>>
>> :
>>>
>>>  7117249: fix warnings in java.util.jar, .logging, .prefs, .zip
>>>  Reviewed-by: alanb, dholmes, forax, sherman, smarks
>>>  Contributed-by: London Java Community and Michael Barker
>>> 
>>>
>>> Since the changeset comment is baked for all eternity, :-) I wanted to
make
>>> sure I got it right before proceeding. But basically this is the last
thing
>>> that needs to be resolved before I can push in the changes. Let me know.
>>
>> All looks good to me.
>
> Michael - the Contributed-by line is usually the individual's name (+
mail address) or a list of names (and their mail addresses). I think Stuart
is suggesting that this would be better than "London Java Community".
>
> -Alan.
>