From Dietmar.Lippold at zi-mannheim.de Fri Aug 4 07:14:31 2017 From: Dietmar.Lippold at zi-mannheim.de (Lippold, Dietmar) Date: Fri, 4 Aug 2017 07:14:31 +0000 Subject: Suggestion of an annotation for GPU computing Message-ID: <294400582438D2469F02F7BA3E5BE4F0A706059C@ZIMAIL2.Zi.local> Hi, I have a suggestion for using Java on GPUs. Because project Sumatra is currently inactive [1] and the suggestion is not related to technical details I send it to this list. I think there are (at least) two important distinctions for ways of using the GPU, the used data structures and the defined program elements. The data structures can be: * Single elements which are processed individually (e.g. in Streams) * Combinations of elements which are processed as a whole (e.g. Vectors) The first is more flexible but the second is easier to use. In project Sumatra the streams were of primary importance [2] but vectors are currently defined in project Panama [3]. The defined program elements for the GPU can be: * Methods (e.g. used in Streams [2]) * Classes (e.g. kernels in Aparapi [4]) An important distinction is that classes can contain data. This is important in cases when the time for transferring the data from the CPU to the GPU is significant for the runtime and the data can be reused in repeated calls of methods. When combining the usage of vectors with classes the usage of GPUs can be very easy I think. One only has to add an annotation like "@OnGpu" to the class which shall "live" on the GPU (i.e. its data are stored on the GPU and its methods are executed on the GPU). Data are transferred between CPU and GPU exactly when a method from a CPU class calls a method (or constructor) from a GPU class. That is obvious to the developer and he/she can optimize that (minimize the transferred data). So my suggestion is: Define such an annotation. Regards, Dietmar [1] http://mail.openjdk.java.net/pipermail/sumatra-dev/2016-July/000327.html [2] https://bugs.openjdk.java.net/browse/JDK-8047074 [3] http://mail.openjdk.java.net/pipermail/panama-dev/2017-July/000622.html [4] https://github.com/aparapi/aparapi/blob/master/doc/UsersGuide.md From rajibando at gmail.com Sun Aug 6 04:47:01 2017 From: rajibando at gmail.com (Rajib Bando) Date: Sun, 6 Aug 2017 10:17:01 +0530 Subject: How to combine different APIs in meaningful ways? Does Javadoc help? Message-ID: Hello! Please refer to this query I had posted in Eclipse Forum, here: https://www.eclipse.org/forums/index.php/m/1768516/#msg_1768516 I would not like to repeat the entire content again to save space. A click to the link suffices. Can Javadoc help me bridge the difficulty in weaving together methods / APIs in meaningful ways and use them for coding, bypassing the difficulty posed by the steep learning curve of synthesis of Oracle API index information for coding? Regards, Rajibando ------------------------------------------------------------------------------------------------------- Four days back [... I posted this new message via email to javadoc-dev `at`openjdk.java.net When I looked at the mailing list at nabble I found that there are only few visitors in this sub-forum havadoc-dev and my message was not yet displayed. So I am again posting the thread, this time via nabble...] Then, I was informed by javadoc-dev-owner `at` openjdk.java.net , without explanation, that this post was deemed inappropriate. So today I deleted that topic and am posting this de-novo here, to OpenJDK General discussion From david.holmes at oracle.com Sun Aug 6 12:13:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 Aug 2017 22:13:53 +1000 Subject: How to combine different APIs in meaningful ways? Does Javadoc help? In-Reply-To: References: Message-ID: Hi Rajib, On 6/08/2017 2:47 PM, Rajib Bando wrote: > Hello! > Please refer to this query I had posted in Eclipse Forum, here: > https://www.eclipse.org/forums/index.php/m/1768516/#msg_1768516 You are basically asking "how do I learn to use libraries when programming" - and that is not a suitable topic for this mailing list either. It isn't actually suitable for any Openjdk mailing list as these lists are about development of the OpenJDK, not about programming in Java. There are various resources on the web for learning to program in Java, which will cover using the libraries. And of course there are many excellent books on the subject. The javadoc describes individual API's and where necessary how they interact with other APIs, but it won't tell you in general how to combine various entities as you give in your example. Regards, David ----- > I would not like to repeat the entire content again to save space. A > click to the link suffices. > Can Javadoc help me bridge the difficulty in weaving together methods > / APIs in meaningful ways and use them for coding, bypassing the > difficulty posed by the steep learning curve of synthesis of Oracle > API index information for coding? > Regards, > Rajibando > ------------------------------------------------------------------------------------------------------- > Four days back > [... I posted this new message via email to javadoc-dev `at`openjdk.java.net > When I looked at the mailing list at nabble I found that there are > only few visitors in this sub-forum havadoc-dev and my message was not > yet displayed. > So I am again posting the thread, this time via nabble...] > Then, I was informed by javadoc-dev-owner `at` openjdk.java.net , > without explanation, that this post was deemed inappropriate. > So today I deleted that topic and am posting this de-novo here, to > OpenJDK General discussion > From lars.francke at gmail.com Mon Aug 7 11:59:28 2017 From: lars.francke at gmail.com (Lars Francke) Date: Mon, 7 Aug 2017 13:59:28 +0200 Subject: State of the Java Style Guidelines document In-Reply-To: References: <5978EDC4.1000803@oracle.com> <0a71044e-907c-493e-33f7-7b1d5194e5e6@oracle.com> <84f69d94-c967-f549-ece4-22025f584b6e@oracle.com> Message-ID: Hi all, just another bump. Any idea on what the process is from here on? Who can I contact to get this going? Cheers, Lars On Mon, Jul 31, 2017 at 9:37 AM, Lars Francke wrote: > That's good to hear, thanks for the clarification. > > For now that leaves the question what's blocking this from being published > or maybe what can be done to move this forward. Any idea who can publish > this and/or what procedures to follow? > > On Thu, Jul 27, 2017 at 10:39 PM, Jim Graham > wrote: > >> I've already said that I think it should be published. I have an >> objection that I've noted just to keep it on the record (via broken record >> loop), but that wasn't a blocking objection... >> >> ...jim >> >> On 7/27/17 1:44 AM, Lars Francke wrote: >> >>> Thanks for the feedback everyone! >>> >>> I understand that people have different personal preferences various >>> topics and we'll never be able to find one style that accommodates all of >>> them. >>> >>> Just to explain what my personal motivation for this push is: >>> Lots of open-source projects (I'm mostly working with the Big Data >>> Apache projects) list the old Sun Code Conventions[1] as the code style to >>> follow. Unfortunately those haven't been updated in 20 years and they leave >>> out lots of minor details that have been clarified in the new version. So >>> for me a revised version of this old document (with no/little changes in >>> the actual code style) would already be a huge benefit. >>> >>> I'm not lobbying for these style guidelines to be adopted by every >>> OpenJDK project (or any project in fact). I'd love for those guidelines to >>> be published as-is as "guidelines" that projects (outside of the OpenJDK as >>> well) can adopt. Nothing's stopping you (as is done in Apache projects >>> frequently) to have your own guidelines "inherit" from these and overwrite >>> certain rules. >>> >>> >I'm sorry, I can't bring myself to reduce the readability of my code >>> because the one person in charge had something against a single additional >>> line in the source base that would provide clarity... >>> >>> People obviously have different opinions on readability and I'm not sure >>> if it's a good idea to list alternative versions for all contentious issues >>> because it would make the whole document more or less meaningless. I think >>> Jonathan has a good point in that the guidelines already cater for >>> differing styles and you could publish your own version for the FX project >>> that lists the points where you deviate from these guidelines. >>> >>> A more procedural question though: Assuming we can find a document >>> version that we all agree on. What would be needed to publish it and who'd >>> be the right person to do so? >>> >>> Thank you, >>> Lars >>> >>> [1] >>> >>> On Wed, Jul 26, 2017 at 9:46 PM, Jim Graham >> > wrote: >>> >>> Agreed, but this version is already in use in the code and was >>> adopted by an entire group, though not the group that >>> the effort towards updating this document was based in. >>> >>> I had suggested it to the author. It seemed to go nowhere and I >>> don't believe it was presented in a poll that was >>> sent out asking for feedback on style variations so it never got the >>> visibility I think it deserved. There were >>> clear biases to ignore the input at the time and I thought it >>> short-sighted. >>> >>> There are many areas where I disagree with the variant chosen, but >>> will go with the flow, but this is one area where >>> I really don't get why the suggestion was ignored as I see it as >>> superior in terms of maintainability on every >>> single front to what was documented - to the extent where I will >>> always be non-compliant with the suggested form - >>> I'm sorry, I can't bring myself to reduce the readability of my code >>> because the one person in charge had something >>> against a single additional line in the source base that would >>> provide clarity... >>> >>> ...jim >>> >>> >>> On 7/26/17 12:30 PM, Jonathan Gibbons wrote: >>> >>> Religious wars are waged over lesser issues. >>> >>> I think it is presumptious to recommend a style for all Java >>> code, but I do think it is reasonable to establish >>> coding guidelines for a specific code base, such as OpenJDK. >>> Even so, opinions will still differ, and there was >>> an attempt in Andreas' work to accommodate reasonable >>> alternatives, with a general proviso of, "when editing >>> existing code that has a consistent style, try to conform to >>> that style, and not slavishly conform to some >>> different standard." >>> >>> -- Jon >>> >>> >>> On 07/26/2017 12:21 PM, Jim Graham wrote: >>> >>> Sorry to sound like a broken record here - I think it should >>> be published too, but... ;) >>> >>> If only it would adopt the convention used in much of 2D and >>> FX of putting a brace on its own line after a >>> line-wrapped conditional/method declaration (preferably as >>> the primary form, but even as an acceptable >>> alternative): >>> >>> public void longMethodNameUsedOnlyForIllustration(SomeLongClassName >>> paramA, >>> >>> LongClassName paramB, >>> int >>> someOtherParam) >>> throws OtherFormsAreUglySmileyFaceException >>> { >>> ... >>> } >>> >>> provides the cleanest and clearest sight line to see where >>> the body of the method/class/conditional starts... >>> >>> >>> >>> ...jim >>> >>> On 7/26/17 3:21 AM, Remi Forax wrote: >>> >>> I agree with Lars, >>> this should be published ASAP. >>> >>> regards, >>> Remi >>> >>> >>> >>> >>> On July 26, 2017 8:41:29 AM GMT+02:00, Lars Francke < >>> lars.francke at gmail.com >>> > wrote: >>> >>> Hi everyone, >>> >>> I've been following the work Andreas Lundblad has >>> done on the new Java >>> Style Guidelines[1]. I know that he's not with >>> Oracle anymore but the >>> draft >>> looks good (and has done so for at least a year), I >>> think all comments >>> have >>> been worked into it. Why has it not been published? >>> Is anyone working >>> on >>> this, if yes, who? >>> >>> I'd be happy to do any work needed to bring it to a >>> final and published >>> form if needed. But to me it looks ready to be >>> published today (apart >>> from >>> a few minor issues I've reported to Andreas already). >>> >>> The old code conventions from 1997 can really use an >>> updated version. >>> >>> Cheers, >>> Lars >>> >>> >>> [1] >> lundblad/styleguide/index-v6.html >>> >> lundblad/styleguide/index-v6.html>> >>> >>> >>> >>> >>> > From mark.reinhold at oracle.com Thu Aug 24 15:49:38 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 Aug 2017 08:49:38 -0700 (PDT) Subject: Group Proposal, for discussion: Vulnerability Group Message-ID: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> (This is not a call for votes; it is just a call for discussion.) The Governing Board has been discussing the creation of a Vulnerability Group for a while now. This new Group is intended to be a secure, private forum in which trusted members of the OpenJDK Community can receive reports of vulnerabilities in OpenJDK code bases, review them, collaborate on fixing them, and coordinate the release of such fixes. This Group will be unusual in several respects, due to the sensitive nature of its work: Membership will be more selective, there will be a strict communication policy, and members (or their employers) will need to sign a non-disclosure and license agreement. These requirements do, strictly speaking, violate the OpenJDK Bylaws. The Governing Board has discussed this, however, and I expect that the Board will approve the creation of this Group with these exceptional requirements. I've posted a detailed proposal for the Vulnerability Group here: http://cr.openjdk.java.net/~mr/ojvg/ That document contains a link to a draft of the non-disclosure and license agreement. The initial Lead of the Vulnerability Group will be Andrew Gross, who leads Oracle's internal Java Vulnerability Team. Comments? - Mark From martijnverburg at gmail.com Thu Aug 24 17:33:41 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 24 Aug 2017 18:33:41 +0100 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> Message-ID: Hi Mark, Totally applaud this idea! I have some suggested wording changes that might be easiest to suggest as a diff or some sort of track changes on the original text. Do you have a preferred mechanism for that type of feedback? Cheers, Martijn On 24 August 2017 at 16:49, wrote: > (This is not a call for votes; it is just a call for discussion.) > > The Governing Board has been discussing the creation of a Vulnerability > Group for a while now. This new Group is intended to be a secure, > private forum in which trusted members of the OpenJDK Community can > receive reports of vulnerabilities in OpenJDK code bases, review them, > collaborate on fixing them, and coordinate the release of such fixes. > > This Group will be unusual in several respects, due to the sensitive > nature of its work: Membership will be more selective, there will be a > strict communication policy, and members (or their employers) will need > to sign a non-disclosure and license agreement. These requirements do, > strictly speaking, violate the OpenJDK Bylaws. The Governing Board has > discussed this, however, and I expect that the Board will approve the > creation of this Group with these exceptional requirements. > > I've posted a detailed proposal for the Vulnerability Group here: > > http://cr.openjdk.java.net/~mr/ojvg/ > > That document contains a link to a draft of the non-disclosure and > license agreement. > > The initial Lead of the Vulnerability Group will be Andrew Gross, who > leads Oracle's internal Java Vulnerability Team. > > Comments? > > - Mark > From neugens.limasoftware at gmail.com Thu Aug 24 17:53:02 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 24 Aug 2017 19:53:02 +0200 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> Message-ID: Hi Mark! This is a fantastic news, thanks for moving this forward! My only complain is that now I have one argument less for FOSDEM ;) Cheers, Mario 2017-08-24 17:49 GMT+02:00 : > (This is not a call for votes; it is just a call for discussion.) > > The Governing Board has been discussing the creation of a Vulnerability > Group for a while now. This new Group is intended to be a secure, > private forum in which trusted members of the OpenJDK Community can > receive reports of vulnerabilities in OpenJDK code bases, review them, > collaborate on fixing them, and coordinate the release of such fixes. > > This Group will be unusual in several respects, due to the sensitive > nature of its work: Membership will be more selective, there will be a > strict communication policy, and members (or their employers) will need > to sign a non-disclosure and license agreement. These requirements do, > strictly speaking, violate the OpenJDK Bylaws. The Governing Board has > discussed this, however, and I expect that the Board will approve the > creation of this Group with these exceptional requirements. > > I've posted a detailed proposal for the Vulnerability Group here: > > http://cr.openjdk.java.net/~mr/ojvg/ > > That document contains a link to a draft of the non-disclosure and > license agreement. > > The initial Lead of the Vulnerability Group will be Andrew Gross, who > leads Oracle's internal Java Vulnerability Team. > > Comments? > > - Mark -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From mark.reinhold at oracle.com Thu Aug 24 21:16:17 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 Aug 2017 14:16:17 -0700 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> Message-ID: <20170824141617.454386468@eggemoggin.niobe.net> 2017/8/24 10:33:41 -0700, martijnverburg at gmail.com: > Totally applaud this idea! I have some suggested wording changes that > might be easiest to suggest as a diff or some sort of track changes on the > original text. Do you have a preferred mechanism for that type of feedback? If you'd like to propose a patch, I've posted the Markdown source here: http://cr.openjdk.java.net/~mr/ojvg/ojvg.md - Mark From weijun.wang at oracle.com Fri Aug 25 02:08:56 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 25 Aug 2017 10:08:56 +0800 Subject: Group Proposal, for discussion: Vulnerability Group In-Reply-To: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> References: <20170824154938.BBC17A8EDB@eggemoggin.niobe.net> Message-ID: <10388A27-82AF-401F-ADB9-BAFA7776DBA3@oracle.com> Suppose I am a "recognized" export in Area A, and Bob is one in Area B. We both have been handling security issues before. Does this mean we would be both included in the group and I can read all discussions in Area B? Also, what is the proper way to temporarily include someone when working on a specific bug? For example, a test engineer, a 3rd-party expert (Ex: a bug only on Windows and we work with someone in Microsoft) or a customer. Since vuln-dev at openjdk.java.net is not opened to them I assume I cannot CC one while writing to this list. Do I just talk to him/her one-to-one? Thanks Max > On Aug 24, 2017, at 11:49 PM, mark.reinhold at oracle.com wrote: > > (This is not a call for votes; it is just a call for discussion.) > > The Governing Board has been discussing the creation of a Vulnerability > Group for a while now. This new Group is intended to be a secure, > private forum in which trusted members of the OpenJDK Community can > receive reports of vulnerabilities in OpenJDK code bases, review them, > collaborate on fixing them, and coordinate the release of such fixes. > > This Group will be unusual in several respects, due to the sensitive > nature of its work: Membership will be more selective, there will be a > strict communication policy, and members (or their employers) will need > to sign a non-disclosure and license agreement. These requirements do, > strictly speaking, violate the OpenJDK Bylaws. The Governing Board has > discussed this, however, and I expect that the Board will approve the > creation of this Group with these exceptional requirements. > > I've posted a detailed proposal for the Vulnerability Group here: > > http://cr.openjdk.java.net/~mr/ojvg/ > > That document contains a link to a draft of the non-disclosure and > license agreement. > > The initial Lead of the Vulnerability Group will be Andrew Gross, who > leads Oracle's internal Java Vulnerability Team. > > Comments? > > - Mark From openjdk at duigou.org Wed Aug 30 19:37:51 2017 From: openjdk at duigou.org (Mike Duigou) Date: Wed, 30 Aug 2017 12:37:51 -0700 Subject: State of the Java Style Guidelines document Message-ID: I would be very disappointed if the Guidelines were finalized and published in their current form. While a noble and necessary effort I believe the proposal still tries to formalize too much and admits too much personal preference. Draft V6 is big improvement over V5 in that it provides more flexibility by removing many of the V5 recommendations. It's disappointing that the entire V5 comments were not disclosed only summarized in http://cr.openjdk.java.net/~alundblad/styleguide/feedback.html I am including my draft comments below on V5 as many of them still apply to V6 Responses to the V5 feedback would also have been appreciated as I note, for example, that despite all the comments rejecting ASCII-only source files the V6 draft was not changed to UTF8. Mike ---- V5 Feedback ---- OpenJDK Style Guide General comments: - Thank you for taking on this task. It is long overdue and important. It is also likely to be contentious and will probably leave everyone a little bit unsatisfied with some aspects. This is, though, how progress is made. - I find that there is too much evidence of personal preference in the guide. Mostly in areas where there is not necessarily need to mention anything. If multiple equilavent choices are available and the only question is which one to pick for standardization it's important to be sure that anything need be said at all. Otherwise, yes, it is one to the benefits of taking on this task to be able to select your preference in matters where there are no technical or consistency reasons to suggest a particular option. As pass through the document with an eye to "do we really need to specify this" would remove most of these cases. Specific comments: Name: Perhaps call it "OpenJDK Style Guide" or if you must "OpenJDK Java Source Code Style Guidelines". This document does not claim to replace the old "Java Style Conventions". The title and scope is better stated by the first sentence of the introduction. Motivation: Contrary to what I said in general comments, the statement about subjectivity is too strong. A stronger motivation for having these guidelines are to describe existing practice. Additionally the choices are not always subjective. Some are arbitrary though they are just as important to providing consistency. Guiding principles: Needs a stronger statement of "don't make unnecessary changes to existing source only for better compliance with these guidelines." Having a reason to change source beyond guideline compliance is critical. Java Source Files: 7-bit ASCII. Nope. UTF-8. There is considerable use of \u escapes including occasionally in silly places like the copyright character. The character confusion issues are a non-compelling reason for disfavouring UTF-8. Selecting 7-bit ASCII in 2015 is quaint by 2025 it will seem archaic. Line endings: This is generally handled automatically by the version control client. Whatever Mercurial does for normalizing line endings in producing file/changes hashes should be what we are using (we don't actually have a choice do we?) and reference that rather than state it as a choice made by the project. Special characters: The motivation should include that using only a single form will make searching easier. Also, \u000d and \u000a are not entirely usable in source files as they are translated before tokenization. The following doesn't work : String foo = "\u000d\u000a"; Wildcard imports: Under motivation. Wildcard imports were a convenience feature before autocompletion and IDE automatic management of imports were common. The necessity is much reduced with the modern IDE support. Modifiers section could be moved earlier as it applies to class/enum/interface Fields : It is worth making special mention of static fields. "Fields, especially static fields, should be declared final..." Short forms: The final "Don'ts" for example seems perfectly normal to me. The getResult() case seems borderline. A motivation section is needed. No tabs: Also implied by earlier no non-space whitespace rule. switch dont's : I can think of a lot more examples of variance that might be prohibited including putting a statement on the same line as the label, Wrapping lines: Rather than giving a limit on the total number of characters perhaps suggest that no more than 60-80 characters non-whitespace per line. The real problem with long lines is not the whitespace but the non-whitespace length. Wrapping class declarations: too many permitted forms and the deep indenting puts the start near the line limit. The Collector example would be better splitting implements through { on to a single line. It would generally be preferable to keep the whole declaration for Collector on one line if it can be done sensibly. Hexidecimal literals: lowercase literals probably outnumber uppercase literals at this point and the java library functions output lower case. Javadoc: What's wrong in the second don't? The third don't will break due to '' being interpreted as an html tag which is unclear. Perhaps suggest {@literal } for < and & Names: Handling of acronyms deserves mention. URLHandler vs UrlHandler Type variables : Use repeated letters for related type variables. (my train ride was over at this point--additional feedback will be provided on future drafts) From fcassia at gmail.com Wed Aug 30 19:58:40 2017 From: fcassia at gmail.com (Fernando Cassia) Date: Wed, 30 Aug 2017 16:58:40 -0300 Subject: State of the Java Style Guidelines document In-Reply-To: References: Message-ID: On 8/30/17, Mike Duigou wrote: > I would be very disappointed if the Guidelines were finalized and > published in their current form. While a noble and necessary effort I > believe the proposal still tries to formalize too much and admits too > much personal preference. Draft V6 is big improvement over V5 "Shipping is a feature: your product should have it" -Jamie Zawinski "A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it?s in your lab where you?re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it." Just my $0.02 FC