From neugens.limasoftware at gmail.com  Fri Dec  1 12:34:02 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 01 Dec 2017 12:34:02 +0000
Subject: Free Java Devroom deadline extended!
Message-ID: <CAGUMyaSuBfN9dhdQugZHrcmU-35TbLHKFajLhYLXU-heYcPStQ@mail.gmail.com>

Hello everyone!

It?s Christmas earlier this year!  By popular demand we are excited to
extend the deadline for submission to the 10th of December (23:59 CET)!

I will shortly update the website, but the new deadline is effective
immediately!

Cheers,
Mario

From gregw at webtide.com  Fri Dec  1 14:44:07 2017
From: gregw at webtide.com (Greg Wilkins)
Date: Fri, 1 Dec 2017 15:44:07 +0100
Subject: Annotation discovery JEP
Message-ID: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>

All,

I'm not at all familiar with your processes here, but it has been suggested
to me that I should
create a JEP to try to initiate a common effort to standardise annotation
discovery.

I have created a draft JEP
<https://github.com/jetty-project/annotation-discovery/blob/master/JEP-Proposal.md>,
which is very light on detail, but I hope it at least well captures the
motivation, reproduce here:

*Motivation*

Prior to Java 9, many java technologies implemented annotation discovery by
inspection of either the URLs of the classloader and/or the class path
itself and tools such as ASM where then used to parse the byte code for
annotations without loading the classes. With the introduction of java 9,
which included Modules, Layers, Upgrade paths, Jlink and Multi Release
jars, the task of discovering class has become difficult to both specify
and implement.

Efficient annotation discovery was an identified requirement of project
Jigsaw
<http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detection>
:

*It must be possible to identify all of the class files in a module
artifact in which a *

*particular annotation is present without actually reading all of the class
files. *

*At run time it must be possible to identify all of the classes in a loaded
module *

*in which a particular annotation is present without enumerating all of the
classes *

*in the module, so long as the annotation was retained for run time. For
efficiency it *

*may be necessary to specify that only certain annotations need to be
detectable in *

*this manner.*


However as explained in the mailing list, this requirement "didn't happen
in Java SE 9
<http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-November/013363.html>".
Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring etc.)
are currently reverse engineering the algorithms implemented by the JVM for
resolving the modules available at runtime and which classes within those
modules are available for loading by the specific runtime platform. Such
duplicated effort is unlikely to be correct given the complex nature of
module resolution, nor future proof given the intention to release java 10
and 11 within the next year.


I'd appreciate any feedback on the form or substance of this proposal
before I submit it

regards

-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com

From david.lloyd at redhat.com  Fri Dec  1 14:52:23 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 1 Dec 2017 08:52:23 -0600
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
Message-ID: <CANghgrS9qWwmEO8_mtEeg29Odf1za5W=HHyuM-cCBiBLxh4aUA@mail.gmail.com>

On Fri, Dec 1, 2017 at 8:44 AM, Greg Wilkins <gregw at webtide.com> wrote:
> All,
>
> I'm not at all familiar with your processes here, but it has been suggested
> to me that I should
> create a JEP to try to initiate a common effort to standardise annotation
> discovery.
>
> I have created a draft JEP
> <https://github.com/jetty-project/annotation-discovery/blob/master/JEP-Proposal.md>,
> which is very light on detail, but I hope it at least well captures the
> motivation, reproduce here:
>
> *Motivation*
>
> Prior to Java 9, many java technologies implemented annotation discovery by
> inspection of either the URLs of the classloader and/or the class path
> itself and tools such as ASM where then used to parse the byte code for
> annotations without loading the classes. With the introduction of java 9,
> which included Modules, Layers, Upgrade paths, Jlink and Multi Release
> jars, the task of discovering class has become difficult to both specify
> and implement.
>
> Efficient annotation discovery was an identified requirement of project
> Jigsaw
> <http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detection>
> :
>
> *It must be possible to identify all of the class files in a module
> artifact in which a *
>
> *particular annotation is present without actually reading all of the class
> files. *
>
> *At run time it must be possible to identify all of the classes in a loaded
> module *
>
> *in which a particular annotation is present without enumerating all of the
> classes *
>
> *in the module, so long as the annotation was retained for run time. For
> efficiency it *
>
> *may be necessary to specify that only certain annotations need to be
> detectable in *
>
> *this manner.*
>
>
> However as explained in the mailing list, this requirement "didn't happen
> in Java SE 9
> <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-November/013363.html>".
> Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring etc.)
> are currently reverse engineering the algorithms implemented by the JVM for
> resolving the modules available at runtime and which classes within those
> modules are available for loading by the specific runtime platform. Such
> duplicated effort is unlikely to be correct given the complex nature of
> module resolution, nor future proof given the intention to release java 10
> and 11 within the next year.
>
>
> I'd appreciate any feedback on the form or substance of this proposal
> before I submit it

Hi Greg.  I just want to add that back when this was being discussed
for Jigsaw, I recall that we talked about a meta-annotation (e.g.
"@Indexed") that would need to be present on the annotation type for
it to be indexed.  If present, then the compilation stage would
probably add the relevant information to some index within the JAR,
module, etc. which would be discoverable by some runtime
reflection-ish API.

It would be nice however if it were not limited to code using JPMS modules.

I'm definitely in favor of getting this missing bit in, at any rate.

-- 
- DML

From scolebourne at joda.org  Fri Dec  1 14:57:55 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 1 Dec 2017 14:57:55 +0000
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
Message-ID: <CACzrW9BYLv_A9SVspB+uVe5cfmsjHC-VDE4NrJcfFN+r16TwTw@mail.gmail.com>

I believe this would be a very valuable addition.
Stephen


On 1 December 2017 at 14:44, Greg Wilkins <gregw at webtide.com> wrote:
> All,
>
> I'm not at all familiar with your processes here, but it has been suggested
> to me that I should
> create a JEP to try to initiate a common effort to standardise annotation
> discovery.
>
> I have created a draft JEP
> <https://github.com/jetty-project/annotation-discovery/blob/master/JEP-Proposal.md>,
> which is very light on detail, but I hope it at least well captures the
> motivation, reproduce here:
>
> *Motivation*
>
> Prior to Java 9, many java technologies implemented annotation discovery by
> inspection of either the URLs of the classloader and/or the class path
> itself and tools such as ASM where then used to parse the byte code for
> annotations without loading the classes. With the introduction of java 9,
> which included Modules, Layers, Upgrade paths, Jlink and Multi Release
> jars, the task of discovering class has become difficult to both specify
> and implement.
>
> Efficient annotation discovery was an identified requirement of project
> Jigsaw
> <http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detection>
> :
>
> *It must be possible to identify all of the class files in a module
> artifact in which a *
>
> *particular annotation is present without actually reading all of the class
> files. *
>
> *At run time it must be possible to identify all of the classes in a loaded
> module *
>
> *in which a particular annotation is present without enumerating all of the
> classes *
>
> *in the module, so long as the annotation was retained for run time. For
> efficiency it *
>
> *may be necessary to specify that only certain annotations need to be
> detectable in *
>
> *this manner.*
>
>
> However as explained in the mailing list, this requirement "didn't happen
> in Java SE 9
> <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-November/013363.html>".
> Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring etc.)
> are currently reverse engineering the algorithms implemented by the JVM for
> resolving the modules available at runtime and which classes within those
> modules are available for loading by the specific runtime platform. Such
> duplicated effort is unlikely to be correct given the complex nature of
> module resolution, nor future proof given the intention to release java 10
> and 11 within the next year.
>
>
> I'd appreciate any feedback on the form or substance of this proposal
> before I submit it
>
> regards
>
> --
> Greg Wilkins <gregw at webtide.com> CTO http://webtide.com

From arjan.tijms at gmail.com  Fri Dec  1 15:20:45 2017
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 1 Dec 2017 16:20:45 +0100
Subject: Annotation discovery JEP
In-Reply-To: <CACzrW9BYLv_A9SVspB+uVe5cfmsjHC-VDE4NrJcfFN+r16TwTw@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CACzrW9BYLv_A9SVspB+uVe5cfmsjHC-VDE4NrJcfFN+r16TwTw@mail.gmail.com>
Message-ID: <CAE=-AhCYSggY0Xpai+f4hj6-FaRY_UPrt+XMybafkACys2uUbQ@mail.gmail.com>

I'm absolutely in favour of this! This would help a lot.

On Fri, Dec 1, 2017 at 3:57 PM, Stephen Colebourne <scolebourne at joda.org>
wrote:

> I believe this would be a very valuable addition.
> Stephen
>
>
> On 1 December 2017 at 14:44, Greg Wilkins <gregw at webtide.com> wrote:
> > All,
> >
> > I'm not at all familiar with your processes here, but it has been
> suggested
> > to me that I should
> > create a JEP to try to initiate a common effort to standardise annotation
> > discovery.
> >
> > I have created a draft JEP
> > <https://github.com/jetty-project/annotation-discovery/
> blob/master/JEP-Proposal.md>,
> > which is very light on detail, but I hope it at least well captures the
> > motivation, reproduce here:
> >
> > *Motivation*
> >
> > Prior to Java 9, many java technologies implemented annotation discovery
> by
> > inspection of either the URLs of the classloader and/or the class path
> > itself and tools such as ASM where then used to parse the byte code for
> > annotations without loading the classes. With the introduction of java 9,
> > which included Modules, Layers, Upgrade paths, Jlink and Multi Release
> > jars, the task of discovering class has become difficult to both specify
> > and implement.
> >
> > Efficient annotation discovery was an identified requirement of project
> > Jigsaw
> > <http://openjdk.java.net/projects/jigsaw/spec/reqs/#
> efficient-annotation-detection>
> > :
> >
> > *It must be possible to identify all of the class files in a module
> > artifact in which a *
> >
> > *particular annotation is present without actually reading all of the
> class
> > files. *
> >
> > *At run time it must be possible to identify all of the classes in a
> loaded
> > module *
> >
> > *in which a particular annotation is present without enumerating all of
> the
> > classes *
> >
> > *in the module, so long as the annotation was retained for run time. For
> > efficiency it *
> >
> > *may be necessary to specify that only certain annotations need to be
> > detectable in *
> >
> > *this manner.*
> >
> >
> > However as explained in the mailing list, this requirement "didn't happen
> > in Java SE 9
> > <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
> November/013363.html>".
> > Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring etc.)
> > are currently reverse engineering the algorithms implemented by the JVM
> for
> > resolving the modules available at runtime and which classes within those
> > modules are available for loading by the specific runtime platform. Such
> > duplicated effort is unlikely to be correct given the complex nature of
> > module resolution, nor future proof given the intention to release java
> 10
> > and 11 within the next year.
> >
> >
> > I'd appreciate any feedback on the form or substance of this proposal
> > before I submit it
> >
> > regards
> >
> > --
> > Greg Wilkins <gregw at webtide.com> CTO http://webtide.com
>

From gregw at webtide.com  Fri Dec  1 16:14:02 2017
From: gregw at webtide.com (Greg Wilkins)
Date: Fri, 1 Dec 2017 17:14:02 +0100
Subject: Annotation discovery JEP
In-Reply-To: <CANghgrS9qWwmEO8_mtEeg29Odf1za5W=HHyuM-cCBiBLxh4aUA@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CANghgrS9qWwmEO8_mtEeg29Odf1za5W=HHyuM-cCBiBLxh4aUA@mail.gmail.com>
Message-ID: <CAAPGdfFR9r0wfCoDdV+2HtX5KpjggXKnKfxLTEYX_NhZfc4ajA@mail.gmail.com>

David,

I've seen such discussions.  Perhaps that could have been done if it was
added from day 0, but there are already
modules in the wild with annotations that need to be scanned which will not
have any index.

So I think we are going to need to support full discovery at runtime with
any metadata indexes just being optional optimisations rather that required
element.

We also need to have a bit of a review of the discoverable annotations that
exist to determine if it really is known at compile time which ones need to
be discoverable.  Are there any use-cases for discovering arbitrary
annotations? etc.

I also agree that it would be good if it could be on more than just
modules.  It is exactly the difficulty of determining which classes are
resolved when there are normal jars/classes on the classpath as well as
module paths/updates/boots that motivates this suggestions.   So 0 modules
and all classpath is just an edge case of that requirement.   I currently
think that we should either be able to ask a classloader for what annotated
classes it would load, or pass a classloader to the API to ask it what
annotated classes it could load.... but these are early thought bubbles.

cheers







On 1 December 2017 at 15:52, David Lloyd <david.lloyd at redhat.com> wrote:

> On Fri, Dec 1, 2017 at 8:44 AM, Greg Wilkins <gregw at webtide.com> wrote:
> > All,
> >
> > I'm not at all familiar with your processes here, but it has been
> suggested
> > to me that I should
> > create a JEP to try to initiate a common effort to standardise annotation
> > discovery.
> >
> > I have created a draft JEP
> > <https://github.com/jetty-project/annotation-discovery/
> blob/master/JEP-Proposal.md>,
> > which is very light on detail, but I hope it at least well captures the
> > motivation, reproduce here:
> >
> > *Motivation*
> >
> > Prior to Java 9, many java technologies implemented annotation discovery
> by
> > inspection of either the URLs of the classloader and/or the class path
> > itself and tools such as ASM where then used to parse the byte code for
> > annotations without loading the classes. With the introduction of java 9,
> > which included Modules, Layers, Upgrade paths, Jlink and Multi Release
> > jars, the task of discovering class has become difficult to both specify
> > and implement.
> >
> > Efficient annotation discovery was an identified requirement of project
> > Jigsaw
> > <http://openjdk.java.net/projects/jigsaw/spec/reqs/#
> efficient-annotation-detection>
> > :
> >
> > *It must be possible to identify all of the class files in a module
> > artifact in which a *
> >
> > *particular annotation is present without actually reading all of the
> class
> > files. *
> >
> > *At run time it must be possible to identify all of the classes in a
> loaded
> > module *
> >
> > *in which a particular annotation is present without enumerating all of
> the
> > classes *
> >
> > *in the module, so long as the annotation was retained for run time. For
> > efficiency it *
> >
> > *may be necessary to specify that only certain annotations need to be
> > detectable in *
> >
> > *this manner.*
> >
> >
> > However as explained in the mailing list, this requirement "didn't happen
> > in Java SE 9
> > <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
> November/013363.html>".
> > Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring etc.)
> > are currently reverse engineering the algorithms implemented by the JVM
> for
> > resolving the modules available at runtime and which classes within those
> > modules are available for loading by the specific runtime platform. Such
> > duplicated effort is unlikely to be correct given the complex nature of
> > module resolution, nor future proof given the intention to release java
> 10
> > and 11 within the next year.
> >
> >
> > I'd appreciate any feedback on the form or substance of this proposal
> > before I submit it
>
> Hi Greg.  I just want to add that back when this was being discussed
> for Jigsaw, I recall that we talked about a meta-annotation (e.g.
> "@Indexed") that would need to be present on the annotation type for
> it to be indexed.  If present, then the compilation stage would
> probably add the relevant information to some index within the JAR,
> module, etc. which would be discoverable by some runtime
> reflection-ish API.
>
> It would be nice however if it were not limited to code using JPMS modules.
>
> I'm definitely in favor of getting this missing bit in, at any rate.
>
> --
> - DML
>



-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com

From gunnar at hibernate.org  Fri Dec  1 16:38:10 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 1 Dec 2017 17:38:10 +0100
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfFR9r0wfCoDdV+2HtX5KpjggXKnKfxLTEYX_NhZfc4ajA@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CANghgrS9qWwmEO8_mtEeg29Odf1za5W=HHyuM-cCBiBLxh4aUA@mail.gmail.com>
 <CAAPGdfFR9r0wfCoDdV+2HtX5KpjggXKnKfxLTEYX_NhZfc4ajA@mail.gmail.com>
Message-ID: <CADGJaX_0r43HU4e=+hMLXngm1NLRRg7rXsJp6A2nmNaBs3Uiow@mail.gmail.com>

Big +1 for having such functionality in a standardised form. It'll be very
useful for implementors of annotation centric APIs such as JPA, Bean
Validation or CDI.

>  Are there any use-cases for discovering arbitrary annotations? etc.

Yes, e.g. Bean Validation allows users to define their own constraints,
which are custom annotations (in general recognisable from being
meta-annotated with @Constraint). CDI has custom custom qualifier
annotations. For such use cases it'd be very useful to be able to search
for annotated elements by giving such meta-annotation.

2017-12-01 17:14 GMT+01:00 Greg Wilkins <gregw at webtide.com>:

> David,
>
> I've seen such discussions.  Perhaps that could have been done if it was
> added from day 0, but there are already
> modules in the wild with annotations that need to be scanned which will not
> have any index.
>
> So I think we are going to need to support full discovery at runtime with
> any metadata indexes just being optional optimisations rather that required
> element.
>
> We also need to have a bit of a review of the discoverable annotations that
> exist to determine if it really is known at compile time which ones need to
> be discoverable.  Are there any use-cases for discovering arbitrary
> annotations? etc.
>
> I also agree that it would be good if it could be on more than just
> modules.  It is exactly the difficulty of determining which classes are
> resolved when there are normal jars/classes on the classpath as well as
> module paths/updates/boots that motivates this suggestions.   So 0 modules
> and all classpath is just an edge case of that requirement.   I currently
> think that we should either be able to ask a classloader for what annotated
> classes it would load, or pass a classloader to the API to ask it what
> annotated classes it could load.... but these are early thought bubbles.
>
> cheers
>
>
>
>
>
>
>
> On 1 December 2017 at 15:52, David Lloyd <david.lloyd at redhat.com> wrote:
>
> > On Fri, Dec 1, 2017 at 8:44 AM, Greg Wilkins <gregw at webtide.com> wrote:
> > > All,
> > >
> > > I'm not at all familiar with your processes here, but it has been
> > suggested
> > > to me that I should
> > > create a JEP to try to initiate a common effort to standardise
> annotation
> > > discovery.
> > >
> > > I have created a draft JEP
> > > <https://github.com/jetty-project/annotation-discovery/
> > blob/master/JEP-Proposal.md>,
> > > which is very light on detail, but I hope it at least well captures the
> > > motivation, reproduce here:
> > >
> > > *Motivation*
> > >
> > > Prior to Java 9, many java technologies implemented annotation
> discovery
> > by
> > > inspection of either the URLs of the classloader and/or the class path
> > > itself and tools such as ASM where then used to parse the byte code for
> > > annotations without loading the classes. With the introduction of java
> 9,
> > > which included Modules, Layers, Upgrade paths, Jlink and Multi Release
> > > jars, the task of discovering class has become difficult to both
> specify
> > > and implement.
> > >
> > > Efficient annotation discovery was an identified requirement of project
> > > Jigsaw
> > > <http://openjdk.java.net/projects/jigsaw/spec/reqs/#
> > efficient-annotation-detection>
> > > :
> > >
> > > *It must be possible to identify all of the class files in a module
> > > artifact in which a *
> > >
> > > *particular annotation is present without actually reading all of the
> > class
> > > files. *
> > >
> > > *At run time it must be possible to identify all of the classes in a
> > loaded
> > > module *
> > >
> > > *in which a particular annotation is present without enumerating all of
> > the
> > > classes *
> > >
> > > *in the module, so long as the annotation was retained for run time.
> For
> > > efficiency it *
> > >
> > > *may be necessary to specify that only certain annotations need to be
> > > detectable in *
> > >
> > > *this manner.*
> > >
> > >
> > > However as explained in the mailing list, this requirement "didn't
> happen
> > > in Java SE 9
> > > <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
> > November/013363.html>".
> > > Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring
> etc.)
> > > are currently reverse engineering the algorithms implemented by the JVM
> > for
> > > resolving the modules available at runtime and which classes within
> those
> > > modules are available for loading by the specific runtime platform.
> Such
> > > duplicated effort is unlikely to be correct given the complex nature of
> > > module resolution, nor future proof given the intention to release java
> > 10
> > > and 11 within the next year.
> > >
> > >
> > > I'd appreciate any feedback on the form or substance of this proposal
> > > before I submit it
> >
> > Hi Greg.  I just want to add that back when this was being discussed
> > for Jigsaw, I recall that we talked about a meta-annotation (e.g.
> > "@Indexed") that would need to be present on the annotation type for
> > it to be indexed.  If present, then the compilation stage would
> > probably add the relevant information to some index within the JAR,
> > module, etc. which would be discoverable by some runtime
> > reflection-ish API.
> >
> > It would be nice however if it were not limited to code using JPMS
> modules.
> >
> > I'm definitely in favor of getting this missing bit in, at any rate.
> >
> > --
> > - DML
> >
>
>
>
> --
> Greg Wilkins <gregw at webtide.com> CTO http://webtide.com
>

From david.lloyd at redhat.com  Fri Dec  1 17:01:06 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 1 Dec 2017 11:01:06 -0600
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfFR9r0wfCoDdV+2HtX5KpjggXKnKfxLTEYX_NhZfc4ajA@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CANghgrS9qWwmEO8_mtEeg29Odf1za5W=HHyuM-cCBiBLxh4aUA@mail.gmail.com>
 <CAAPGdfFR9r0wfCoDdV+2HtX5KpjggXKnKfxLTEYX_NhZfc4ajA@mail.gmail.com>
Message-ID: <CANghgrT56QWdXe8o3z0O+VK-yYsCQCmmcwa8Qzd2Mrq0eFCX+g@mail.gmail.com>

On Fri, Dec 1, 2017 at 10:14 AM, Greg Wilkins <gregw at webtide.com> wrote:
>
> David,
>
> I've seen such discussions.  Perhaps that could have been done if it was
> added from day 0, but there are already
> modules in the wild with annotations that need to be scanned which will not
> have any index.
>
> So I think we are going to need to support full discovery at runtime with
> any metadata indexes just being optional optimisations rather that required
> element.

I'm in favor by principle, but I think as a practical matter, this
just won't work.  We tried this with Jandex and the result was
impractical: people have @Deprecated and @FunctionalInterface and so
forth all over the place.  The resulting indexes are huge and we go to
great pains to keep them compact.  I don't think there's any practical
platform-level solution that doesn't involve some form of opt-in.

That said, I think your fears could be mitigated by the fact that any
software which would use the new API to find annotations would also
usually be in a position to update their published annotations with
@Indexed; and also, there could be a command-line solution as well
(for example, an option could be added to javac to explicitly add
indexes for certain unannotated annotations) for the last case.

> We also need to have a bit of a review of the discoverable annotations that
> exist to determine if it really is known at compile time which ones need to
> be discoverable.  Are there any use-cases for discovering arbitrary
> annotations? etc.

That I do not know.

-- 
- DML

From gregw at webtide.com  Fri Dec  1 17:46:43 2017
From: gregw at webtide.com (Greg Wilkins)
Date: Fri, 1 Dec 2017 18:46:43 +0100
Subject: Annotation discovery JEP
In-Reply-To: <CANghgrT56QWdXe8o3z0O+VK-yYsCQCmmcwa8Qzd2Mrq0eFCX+g@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CANghgrS9qWwmEO8_mtEeg29Odf1za5W=HHyuM-cCBiBLxh4aUA@mail.gmail.com>
 <CAAPGdfFR9r0wfCoDdV+2HtX5KpjggXKnKfxLTEYX_NhZfc4ajA@mail.gmail.com>
 <CANghgrT56QWdXe8o3z0O+VK-yYsCQCmmcwa8Qzd2Mrq0eFCX+g@mail.gmail.com>
Message-ID: <CAAPGdfG15im8Qk8ATgVm5FnZowV2sRvV57Ep2B0GDT1+rnQgaw@mail.gmail.com>

David,

I hear you that the indexes may be large.   But currently many containers
have to generate these large indexes on the fly so they can find and
satisfy annotations that register interest in other annotations (eg
@HandleTypes).   The alternative to large dynamic indexes is doing multiple
scans, which can take a long long time (it's amazing how many jars can be
put into one war!).

I think the primary goal of this API should be correctness - ie to produce
exactly the right list of classes, even if it takes a long time using lots
of memory and/or time.
Regardless of implementation, I think this effort would be useful if all it
produced was a specification document that clearly stated what classes
should be discovered and scanned, because currently it is entirely not
clear what classes are resolved when you consider class paths, modules
paths, upgrade paths, multi release jars, etc.

It is a secondary goal to come up with mechanism like meta-inf indexes that
will make it work both correctly AND efficiently.

cheers






On 1 December 2017 at 18:01, David Lloyd <david.lloyd at redhat.com> wrote:

> On Fri, Dec 1, 2017 at 10:14 AM, Greg Wilkins <gregw at webtide.com> wrote:
> >
> > David,
> >
> > I've seen such discussions.  Perhaps that could have been done if it was
> > added from day 0, but there are already
> > modules in the wild with annotations that need to be scanned which will
> not
> > have any index.
> >
> > So I think we are going to need to support full discovery at runtime with
> > any metadata indexes just being optional optimisations rather that
> required
> > element.
>
> I'm in favor by principle, but I think as a practical matter, this
> just won't work.  We tried this with Jandex and the result was
> impractical: people have @Deprecated and @FunctionalInterface and so
> forth all over the place.  The resulting indexes are huge and we go to
> great pains to keep them compact.  I don't think there's any practical
> platform-level solution that doesn't involve some form of opt-in.
>
> That said, I think your fears could be mitigated by the fact that any
> software which would use the new API to find annotations would also
> usually be in a position to update their published annotations with
> @Indexed; and also, there could be a command-line solution as well
> (for example, an option could be added to javac to explicitly add
> indexes for certain unannotated annotations) for the last case.
>
> > We also need to have a bit of a review of the discoverable annotations
> that
> > exist to determine if it really is known at compile time which ones need
> to
> > be discoverable.  Are there any use-cases for discovering arbitrary
> > annotations? etc.
>
> That I do not know.
>
> --
> - DML
>



-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com

From brian.goetz at oracle.com  Fri Dec  1 18:33:36 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 1 Dec 2017 13:33:36 -0500
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfG15im8Qk8ATgVm5FnZowV2sRvV57Ep2B0GDT1+rnQgaw@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CANghgrS9qWwmEO8_mtEeg29Odf1za5W=HHyuM-cCBiBLxh4aUA@mail.gmail.com>
 <CAAPGdfFR9r0wfCoDdV+2HtX5KpjggXKnKfxLTEYX_NhZfc4ajA@mail.gmail.com>
 <CANghgrT56QWdXe8o3z0O+VK-yYsCQCmmcwa8Qzd2Mrq0eFCX+g@mail.gmail.com>
 <CAAPGdfG15im8Qk8ATgVm5FnZowV2sRvV57Ep2B0GDT1+rnQgaw@mail.gmail.com>
Message-ID: <936e32b5-6e5a-6bd6-1a5c-3ca2658547ba@oracle.com>

I like that you've limited this JEP to how to ask the right question, 
and be assured of getting the right answer, rather than diving into the 
details of what is indexed, by whom, when, and in what format.? Such 
details are of course important for the implementation, but must remain 
implementation details that merely aid in optimization.

On 12/1/2017 12:46 PM, Greg Wilkins wrote:
> I think the primary goal of this API should be correctness - ie to produce
> exactly the right list of classes, even if it takes a long time using lots
> of memory and/or time.


From Ryan.LaMothe at pnnl.gov  Mon Dec  4 23:56:07 2017
From: Ryan.LaMothe at pnnl.gov (LaMothe, Ryan R)
Date: Mon, 4 Dec 2017 23:56:07 +0000
Subject: Thoughts on Name Space Layout Randomization (NSLR)?
Message-ID: <2C1BFAA1-0B0F-483F-921C-7336356A2815@pnnl.gov>

I just ran across an article about JVM Name Space Layout Randomization (NSLR) and wanted to pass on the information.

To quote the article: ?Name Space Layout Randomization (NSLR) is based on the same principle as ASLR, but applied for the first time as an application security feature for the Java runtime. NSLR hardens the Java virtual machine (JVM) by randomizing the JRE namespace (Java packages). Using NSLR inside the JVM, the ownership of bytecode loading is standardized and unvalidated bytecode fails to be executed. In effect, this makes bytecode tampering and a range of code injection exploits so difficult to execute that they become unfeasible, protecting against known and unknown vulnerabilities, including zero-day exploits.?

https://www.waratek.com/owasp-appsec-usa-2017/
https://www.waratek.com/nslr/


Sounds intriguing. Thoughts?


-Ryan

From gregw at webtide.com  Mon Dec 11 12:53:40 2017
From: gregw at webtide.com (Greg Wilkins)
Date: Mon, 11 Dec 2017 13:53:40 +0100
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
Message-ID: <CAAPGdfGYtEmCL2FAexY94JuFmN3vXYnB9_OoTAXpN0LkQdT9=A@mail.gmail.com>

Thanks all for the feedback on this.  I've sent the draft to jep-submit,
however I think the process has changed and I may need a openjdk committer
to progress the JEP? If so, anybody interested?

cheers


On 1 December 2017 at 15:44, Greg Wilkins <gregw at webtide.com> wrote:

>
> All,
>
> I'm not at all familiar with your processes here, but it has been
> suggested to me that I should
> create a JEP to try to initiate a common effort to standardise annotation
> discovery.
>
> I have created a draft JEP
> <https://github.com/jetty-project/annotation-discovery/blob/master/JEP-Proposal.md>,
> which is very light on detail, but I hope it at least well captures the
> motivation, reproduce here:
>
> *Motivation*
>
> Prior to Java 9, many java technologies implemented annotation discovery
> by inspection of either the URLs of the classloader and/or the class path
> itself and tools such as ASM where then used to parse the byte code for
> annotations without loading the classes. With the introduction of java 9,
> which included Modules, Layers, Upgrade paths, Jlink and Multi Release
> jars, the task of discovering class has become difficult to both specify
> and implement.
>
> Efficient annotation discovery was an identified requirement of project
> Jigsaw
> <http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detection>
> :
>
> *It must be possible to identify all of the class files in a module
> artifact in which a *
>
> *particular annotation is present without actually reading all of the
> class files. *
>
> *At run time it must be possible to identify all of the classes in a
> loaded module *
>
> *in which a particular annotation is present without enumerating all of
> the classes *
>
> *in the module, so long as the annotation was retained for run time. For
> efficiency it *
>
> *may be necessary to specify that only certain annotations need to be
> detectable in *
>
> *this manner.*
>
>
> However as explained in the mailing list, this requirement "didn't happen
> in Java SE 9
> <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-November/013363.html>".
> Thus currently multiple frameworks (servlets, EJB, JPA, CDI, Spring etc.)
> are currently reverse engineering the algorithms implemented by the JVM for
> resolving the modules available at runtime and which classes within those
> modules are available for loading by the specific runtime platform. Such
> duplicated effort is unlikely to be correct given the complex nature of
> module resolution, nor future proof given the intention to release java 10
> and 11 within the next year.
>
>
> I'd appreciate any feedback on the form or substance of this proposal
> before I submit it
>
> regards
>
> --
> Greg Wilkins <gregw at webtide.com> CTO http://webtide.com
>



-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com

From jai.forums2013 at gmail.com  Mon Dec 11 14:06:37 2017
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 11 Dec 2017 19:36:37 +0530
Subject: Odd result with canonical paths with intermixed usage of java.io.File
 and java.nio.file.Files APIs
Message-ID: <0cef83a0-174f-d7bc-9a19-fb2d895777ae@gmail.com>

I have been debugging an issue with canonical file path and it seems 
that I either have run into a bug or am incorrectly intermixing the use 
of java.io.File and java.nio.file.Files APIs. I'm on MacOS and this 
issue is reproducible with both Java 8 and Java 9:

Java 8:

java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

Java 9:

java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)



The code that reproduces this issue is as simple as this:

public static void main(final String[] args) throws Exception {
 ??? final Path symlinkPath = Paths.get("/tmp/foosymlink");

 ??? final Path targetPath = Paths.get("/tmp/existing-text-file.txt");
 ??? // create a symbolic link
 ??? java.nio.file.Files.createSymbolicLink(symlinkPath, targetPath);


 ??? System.out.println("Canonical path on first symlink creation " + 
symlinkPath.toFile().getCanonicalPath());


 ??? // delete the link (but not the target)
 ??? Files.delete(symlinkPath);


 ??? // recreate the link to point to some other target file
 ??? final Path someOtherTargetPath = 
Paths.get("/tmp/other-existing-text-file.txt");
 ??? java.nio.file.Files.createSymbolicLink(symlinkPath, 
someOtherTargetPath);


 ??? System.out.println("Canonical path on symlink recreation " + 
symlinkPath.toFile().getCanonicalPath());
}

So what that code does is:

 ??? 1. Create a symlink with the link pointing to some existing file
 ??? 2. Invoke getCanonicalPath() on the symlink File object. This is 
important to reproduce the issue (for reasons explained later)
 ??? 3. Delete the symlink (not the target of the symlink) using 
java.nio.file.Files.delete(Path) API.
 ??? 4. Recreate the symlink (at the same path) but pointing it to a 
different (existent) target file
 ??? 5. Invoke the getCanonicalPath() on the symlink File object and 
evaluate the returned value.

Step#5 incorrectly returns the canonical path which points to the 
outdated target path (the link to which was broken in step#3). However, 
if step#5 is invoked after a delay of around 30 seconds from step#3, 
then it returns the correct canonical path which points to the target 
file of the link which was recreated in step#4.

Looking into the implementation of getCanonicalPath and the underlying 
java.io.FileSystem, on my setup the java.io.UnixFileSystem gets picked 
up which internally maintains a canonical path cache (which expires its 
entries with a 30 second duration). So it's pretty clear why this 
behaves the way it does. There's a system property which controls 
disabling this cache, so this in itself isn't an issue.

However, if I switch the call (in step#3 above) from:

 ??? Files.delete(symlinkPath)

to
 ??? symlinkPath.toFile().delete()

then the step#5 (immediately) returns the right canonical path which 
points to the target file of the recreated link. Looking at the 
implementation of java.io.File.delete() it triggers the 
java.io.UnixFileSystem.delete() which clears off the canonical path 
cache[1] and thus doesn't end up returning stale path values on calls to 
getCanonicalPath().

So a few related questions that I have are:

 ??? 1. Is this inconsistency an expected behaviour or is this a bug?
 ??? 2. If this is an expected behaviour, then would it be a better idea 
(as an application developer) to use Path.toRealPath[2] instead of using 
the File.getCanonicalPath()? Are these 2 APIs semantically equivalent? 
The File.getCanonicalPath() talks about the canonical path being 
"unique" paths but the Path.toRealPath has no such mentions.


[1] 
http://hg.openjdk.java.net/jdk/jdk/file/31febb3f66f7/src/java.base/unix/classes/java/io/UnixFileSystem.java#l256
[2] 
https://docs.oracle.com/javase/9/docs/api/java/nio/file/Path.html#toRealPath-java.nio.file.LinkOption...-

-Jaikiran




From Alan.Bateman at oracle.com  Mon Dec 11 14:25:36 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 11 Dec 2017 14:25:36 +0000
Subject: Odd result with canonical paths with intermixed usage of
 java.io.File and java.nio.file.Files APIs
In-Reply-To: <0cef83a0-174f-d7bc-9a19-fb2d895777ae@gmail.com>
References: <0cef83a0-174f-d7bc-9a19-fb2d895777ae@gmail.com>
Message-ID: <47fb187d-ef34-d707-f55a-c06872326795@oracle.com>

On 11/12/2017 14:06, Jaikiran Pai wrote:
> :
>
> So a few related questions that I have are:
>
> ??? 1. Is this inconsistency an expected behaviour or is this a bug?
> ??? 2. If this is an expected behaviour, then would it be a better 
> idea (as an application developer) to use Path.toRealPath[2] instead 
> of using the File.getCanonicalPath()? Are these 2 APIs semantically 
> equivalent? The File.getCanonicalPath() talks about the canonical path 
> being "unique" paths but the Path.toRealPath has no such mentions.
>
The correctness issues with the canonicalization cache is a long 
standing issue [1]. You can workaround it by running with 
-Dsun.io.useCanonCaches=false as I think you have found. The goal is to 
eventually disable and remove it. The first steps to get there happened 
in JDK 9 when FilePermission was changed to not canonicalize by default 
(FilePermission was the original motivation for this cache).

If you have follow-up questions then please bring the thread to 
core-libs-dev.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-7066948

From Alan.Bateman at oracle.com  Mon Dec 11 15:58:16 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 11 Dec 2017 15:58:16 +0000
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfGYtEmCL2FAexY94JuFmN3vXYnB9_OoTAXpN0LkQdT9=A@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CAAPGdfGYtEmCL2FAexY94JuFmN3vXYnB9_OoTAXpN0LkQdT9=A@mail.gmail.com>
Message-ID: <ca27a1e8-97f3-04a3-488e-ff1e8f8f6d67@oracle.com>

On 11/12/2017 12:53, Greg Wilkins wrote:
> Thanks all for the feedback on this.  I've sent the draft to jep-submit,
> however I think the process has changed and I may need a openjdk committer
> to progress the JEP? If so, anybody interested?
>
It might be useful to get an initial prototyping working to get a feel 
for the areas of the platform that might be impacted. It may be that it 
can be done completely in a standalone library or maybe it will need 
some APIs or support exposed.

-Alan

From gregw at webtide.com  Mon Dec 11 16:02:34 2017
From: gregw at webtide.com (Greg Wilkins)
Date: Mon, 11 Dec 2017 17:02:34 +0100
Subject: Annotation discovery JEP
In-Reply-To: <ca27a1e8-97f3-04a3-488e-ff1e8f8f6d67@oracle.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CAAPGdfGYtEmCL2FAexY94JuFmN3vXYnB9_OoTAXpN0LkQdT9=A@mail.gmail.com>
 <ca27a1e8-97f3-04a3-488e-ff1e8f8f6d67@oracle.com>
Message-ID: <CAAPGdfF9x_uc9f1b7LSiSEM5JjhT10uyHdQKE-PPZidUin_++w@mail.gmail.com>

Alan,

Before boldly going ahead to design an API and implementation, I was kind
of hoping to gather a merry band of potential contributors first to make
sure we have the right range of experience, potential users and internals
knowledge.  I'm not a huge fan of design by committee, but it would be good
to at least get some wider input on requirements before trying anything out.

cheers

On 11 December 2017 at 16:58, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 11/12/2017 12:53, Greg Wilkins wrote:
>
>> Thanks all for the feedback on this.  I've sent the draft to jep-submit,
>> however I think the process has changed and I may need a openjdk committer
>> to progress the JEP? If so, anybody interested?
>>
>> It might be useful to get an initial prototyping working to get a feel
> for the areas of the platform that might be impacted. It may be that it can
> be done completely in a standalone library or maybe it will need some APIs
> or support exposed.
>
> -Alan
>



-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com

From aph at redhat.com  Mon Dec 11 16:25:10 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Dec 2017 16:25:10 +0000
Subject: Annotation discovery JEP
In-Reply-To: <CAAPGdfF9x_uc9f1b7LSiSEM5JjhT10uyHdQKE-PPZidUin_++w@mail.gmail.com>
References: <CAAPGdfGBhzsVXj6YA-2=T2NHSaKfoL4thwZvfSJZ6TwPy5-7fA@mail.gmail.com>
 <CAAPGdfGYtEmCL2FAexY94JuFmN3vXYnB9_OoTAXpN0LkQdT9=A@mail.gmail.com>
 <ca27a1e8-97f3-04a3-488e-ff1e8f8f6d67@oracle.com>
 <CAAPGdfF9x_uc9f1b7LSiSEM5JjhT10uyHdQKE-PPZidUin_++w@mail.gmail.com>
Message-ID: <e5ac7eb2-4bd7-50c4-2037-a49dc8b5699d@redhat.com>

On 11/12/17 16:02, Greg Wilkins wrote:
> Before boldly going ahead to design an API and implementation, I was kind
> of hoping to gather a merry band of potential contributors first to make
> sure we have the right range of experience, potential users and internals
> knowledge.  I'm not a huge fan of design by committee, but it would be good
> to at least get some wider input on requirements before trying anything out.

IMO iteration makes more sense, then people at least have some tyres
to kick.  Sure, you end up throwing away your first implementation,
but that's how it's supposed to work.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From cristian.lorenzetto at gmail.com  Sun Dec 24 14:41:22 2017
From: cristian.lorenzetto at gmail.com (Cristian Lorenzetto)
Date: Sun, 24 Dec 2017 15:41:22 +0100
Subject: important discovery about a probable refactoring in jvm or OS
Message-ID: <CAEsommS4=KdJDX0LA413pfDdwOTbGVwUz+mBmYjGpuJhiTU8nA@mail.gmail.com>

As i descrived in this place https://github.com/boostorg/fiber/issues/161

It is impossible to use JNI interface when c++ code is executing  native
fibers/courotines (calling a java callback). Pratically in future all new
software will use fibers instead threads so java will get a prison.
It is necessary to re design JVM with many changes

c++ native fibers might be the java threads so JNI continue to works

In addition i suggest
- to add new data type for unsigned number
- multyhierarchy (
parent classes can't have a common ancestor(except trially Object class).
This permits to evoid data inconsistency as explained also in Kotlin) This
is the just limitation for evoiding inconsitency.
- inline functions
- redesign lambdas compiler engine to trasforming lambda classes in inline
code (see stackoverflow ho many developers proved the bad bytecode
generated by actual javac)

Pay attention ! Java could die if it doesnt follow the modern software
needs! you can see already now many jdk new languages trying to skip the
java language , but if you talk with the languages teams you can see all
tells JDK doesnt permits do do many things others VM permits(in primis
class multi hierarchy). Java must change before developers change language!

From peter.lawrey at gmail.com  Sun Dec 24 16:38:43 2017
From: peter.lawrey at gmail.com (Peter Lawrey)
Date: Sun, 24 Dec 2017 16:38:43 +0000
Subject: important discovery about a probable refactoring in jvm or OS
In-Reply-To: <CAEsommS4=KdJDX0LA413pfDdwOTbGVwUz+mBmYjGpuJhiTU8nA@mail.gmail.com>
References: <CAEsommS4=KdJDX0LA413pfDdwOTbGVwUz+mBmYjGpuJhiTU8nA@mail.gmail.com>
Message-ID: <CAOgwmThDJKztLZJ8zg9dhHCrqD2Nt8z5nTGDxFzi3-jXfb_VgQ@mail.gmail.com>

Hello Christian,
   Some quick thoughts.
- while fibres are an important feature I have never found a use for them
in my space due to them being too expensive. I assume there are some very
good use cases for them but the growing number of cpus in a server might
make this less important.
- i agree on unsigned esp 128 bit. Unsigned char is not enough and why byte
is unsigned i van only assume is historical. Unsigned operations are
supported using the wrapper classes.
Personally, i feel BigDecimal should have language support ala C#.
- i think java will evolve to allowing multiple inheritance of classes but
its not needed most of the time. Esp with enhancements to interfaces.
- the JVM already inlines methods and there is an @ForceInline however it's
not for public use afaik.
- the byte code at compile time isn't as important as the code it compiles
to at runtime. Lambdas do take a hit before they warm up and making
capturing lambdas not create garbage is a pain.

I would point out that of the top languages, Java is one of the newest.
What it really needs is features older languages take for granted and are
widely used and understood eg structs.

https://www.tiobe.com/tiobe-index/

Regards Peter.


On 24 Dec. 2017 2:41 pm, "Cristian Lorenzetto" <
cristian.lorenzetto at gmail.com> wrote:

As i descrived in this place https://github.com/boostorg/fiber/issues/161

It is impossible to use JNI interface when c++ code is executing  native
fibers/courotines (calling a java callback). Pratically in future all new
software will use fibers instead threads so java will get a prison.
It is necessary to re design JVM with many changes

c++ native fibers might be the java threads so JNI continue to works

In addition i suggest
- to add new data type for unsigned number
- multyhierarchy (
parent classes can't have a common ancestor(except trially Object class).
This permits to evoid data inconsistency as explained also in Kotlin) This
is the just limitation for evoiding inconsitency.
- inline functions
- redesign lambdas compiler engine to trasforming lambda classes in inline
code (see stackoverflow ho many developers proved the bad bytecode
generated by actual javac)

Pay attention ! Java could die if it doesnt follow the modern software
needs! you can see already now many jdk new languages trying to skip the
java language , but if you talk with the languages teams you can see all
tells JDK doesnt permits do do many things others VM permits(in primis
class multi hierarchy). Java must change before developers change language!

From cristian.lorenzetto at gmail.com  Sun Dec 24 17:13:07 2017
From: cristian.lorenzetto at gmail.com (Cristian Lorenzetto)
Date: Sun, 24 Dec 2017 18:13:07 +0100
Subject: important discovery about a probable refactoring in jvm or OS
In-Reply-To: <CAOgwmThDJKztLZJ8zg9dhHCrqD2Nt8z5nTGDxFzi3-jXfb_VgQ@mail.gmail.com>
References: <CAEsommS4=KdJDX0LA413pfDdwOTbGVwUz+mBmYjGpuJhiTU8nA@mail.gmail.com>
 <CAOgwmThDJKztLZJ8zg9dhHCrqD2Nt8z5nTGDxFzi3-jXfb_VgQ@mail.gmail.com>
Message-ID: <CAEsommQ8H8SQC2Y-WrBo1DfMrDDu1iMCYwi0xPYHPtH-0f7sGA@mail.gmail.com>

- while fibres are an important feature I have never found a use for them
in my space due to them being too expensive. I assume there are some very
good use cases for them but the growing number of cpus in a server might
make this less important.
this is completely false , it is the opposite , fibers solve a actual
problems . Big data acceletated to introduce it. About expensive... it is
opposite . I think you have a bit to go deeply in this context.
XML as exchange protocol is terrible  and now is completely replaced by
more performant and binary solution . To have a complete list about data
type it is important. Java is not inly used for making simple software but
also in engineering and high performance systems.
Interfaces are not multiherarchy, Interfaces are black boxes. Anyway there
are also problem with performance (to explain require time).
inline method are just when jvm decide it at runtime, but there are
contexts in which the developers and the software have to be
deterministic.In addition the inline process applied is very very trial.
Who study lambdas know that is a mathematical theory. When there is
 mathematical formula is possible to replace it with inline code. Java
lambdas are just a different rappresentation of objects usage. But the tens
of years are not spent for create a theory for rename the same things.



---------- Forwarded message ----------
From: Peter Lawrey <peter.lawrey at gmail.com>
Date: 2017-12-24 17:38 GMT+01:00
Subject: Re: important discovery about a probable refactoring in jvm or OS
To: Cristian Lorenzetto <cristian.lorenzetto at gmail.com>
Cc: discuss <discuss at openjdk.java.net>


Hello Christian,
   Some quick thoughts.
- while fibres are an important feature I have never found a use for them
in my space due to them being too expensive. I assume there are some very
good use cases for them but the growing number of cpus in a server might
make this less important.
- i agree on unsigned esp 128 bit. Unsigned char is not enough and why byte
is unsigned i van only assume is historical. Unsigned operations are
supported using the wrapper classes.
Personally, i feel BigDecimal should have language support ala C#.
- i think java will evolve to allowing multiple inheritance of classes but
its not needed most of the time. Esp with enhancements to interfaces.
- the JVM already inlines methods and there is an @ForceInline however it's
not for public use afaik.
- the byte code at compile time isn't as important as the code it compiles
to at runtime. Lambdas do take a hit before they warm up and making
capturing lambdas not create garbage is a pain.

I would point out that of the top languages, Java is one of the newest.
What it really needs is features older languages take for granted and are
widely used and understood eg structs.

https://www.tiobe.com/tiobe-index/

Regards Peter.


On 24 Dec. 2017 2:41 pm, "Cristian Lorenzetto" <
cristian.lorenzetto at gmail.com> wrote:

As i descrived in this place https://github.com/boostorg/fiber/issues/161

It is impossible to use JNI interface when c++ code is executing  native
fibers/courotines (calling a java callback). Pratically in future all new
software will use fibers instead threads so java will get a prison.
It is necessary to re design JVM with many changes

c++ native fibers might be the java threads so JNI continue to works

In addition i suggest
- to add new data type for unsigned number
- multyhierarchy (
parent classes can't have a common ancestor(except trially Object class).
This permits to evoid data inconsistency as explained also in Kotlin) This
is the just limitation for evoiding inconsitency.
- inline functions
- redesign lambdas compiler engine to trasforming lambda classes in inline
code (see stackoverflow ho many developers proved the bad bytecode
generated by actual javac)

Pay attention ! Java could die if it doesnt follow the modern software
needs! you can see already now many jdk new languages trying to skip the
java language , but if you talk with the languages teams you can see all
tells JDK doesnt permits do do many things others VM permits(in primis
class multi hierarchy). Java must change before developers change language!

From martijnverburg at gmail.com  Sun Dec 24 21:02:37 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 24 Dec 2017 21:02:37 +0000
Subject: important discovery about a probable refactoring in jvm or OS
In-Reply-To: <CAEsommQ8H8SQC2Y-WrBo1DfMrDDu1iMCYwi0xPYHPtH-0f7sGA@mail.gmail.com>
References: <CAEsommS4=KdJDX0LA413pfDdwOTbGVwUz+mBmYjGpuJhiTU8nA@mail.gmail.com>
 <CAOgwmThDJKztLZJ8zg9dhHCrqD2Nt8z5nTGDxFzi3-jXfb_VgQ@mail.gmail.com>
 <CAEsommQ8H8SQC2Y-WrBo1DfMrDDu1iMCYwi0xPYHPtH-0f7sGA@mail.gmail.com>
Message-ID: <CAP7YuAS=utcywypnJCWefb0dUjX9=1JWeGeMD=2_0mEXB1sJmA@mail.gmail.com>

Hi Cristian,

See
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004390.html
which discusses Project Loom.  Project Loom is where you'll
want to be discussing this type of feature in OpenJDK.

Cheers,
Martijn

On 24 December 2017 at 17:13, Cristian Lorenzetto <
cristian.lorenzetto at gmail.com> wrote:

> - while fibres are an important feature I have never found a use for them
> in my space due to them being too expensive. I assume there are some very
> good use cases for them but the growing number of cpus in a server might
> make this less important.
> this is completely false , it is the opposite , fibers solve a actual
> problems . Big data acceletated to introduce it. About expensive... it is
> opposite . I think you have a bit to go deeply in this context.
> XML as exchange protocol is terrible  and now is completely replaced by
> more performant and binary solution . To have a complete list about data
> type it is important. Java is not inly used for making simple software but
> also in engineering and high performance systems.
> Interfaces are not multiherarchy, Interfaces are black boxes. Anyway there
> are also problem with performance (to explain require time).
> inline method are just when jvm decide it at runtime, but there are
> contexts in which the developers and the software have to be
> deterministic.In addition the inline process applied is very very trial.
> Who study lambdas know that is a mathematical theory. When there is
>  mathematical formula is possible to replace it with inline code. Java
> lambdas are just a different rappresentation of objects usage. But the tens
> of years are not spent for create a theory for rename the same things.
>
>
>
> ---------- Forwarded message ----------
> From: Peter Lawrey <peter.lawrey at gmail.com>
> Date: 2017-12-24 17:38 GMT+01:00
> Subject: Re: important discovery about a probable refactoring in jvm or OS
> To: Cristian Lorenzetto <cristian.lorenzetto at gmail.com>
> Cc: discuss <discuss at openjdk.java.net>
>
>
> Hello Christian,
>    Some quick thoughts.
> - while fibres are an important feature I have never found a use for them
> in my space due to them being too expensive. I assume there are some very
> good use cases for them but the growing number of cpus in a server might
> make this less important.
> - i agree on unsigned esp 128 bit. Unsigned char is not enough and why byte
> is unsigned i van only assume is historical. Unsigned operations are
> supported using the wrapper classes.
> Personally, i feel BigDecimal should have language support ala C#.
> - i think java will evolve to allowing multiple inheritance of classes but
> its not needed most of the time. Esp with enhancements to interfaces.
> - the JVM already inlines methods and there is an @ForceInline however it's
> not for public use afaik.
> - the byte code at compile time isn't as important as the code it compiles
> to at runtime. Lambdas do take a hit before they warm up and making
> capturing lambdas not create garbage is a pain.
>
> I would point out that of the top languages, Java is one of the newest.
> What it really needs is features older languages take for granted and are
> widely used and understood eg structs.
>
> https://www.tiobe.com/tiobe-index/
>
> Regards Peter.
>
>
> On 24 Dec. 2017 2:41 pm, "Cristian Lorenzetto" <
> cristian.lorenzetto at gmail.com> wrote:
>
> As i descrived in this place https://github.com/boostorg/fiber/issues/161
>
> It is impossible to use JNI interface when c++ code is executing  native
> fibers/courotines (calling a java callback). Pratically in future all new
> software will use fibers instead threads so java will get a prison.
> It is necessary to re design JVM with many changes
>
> c++ native fibers might be the java threads so JNI continue to works
>
> In addition i suggest
> - to add new data type for unsigned number
> - multyhierarchy (
> parent classes can't have a common ancestor(except trially Object class).
> This permits to evoid data inconsistency as explained also in Kotlin) This
> is the just limitation for evoiding inconsitency.
> - inline functions
> - redesign lambdas compiler engine to trasforming lambda classes in inline
> code (see stackoverflow ho many developers proved the bad bytecode
> generated by actual javac)
>
> Pay attention ! Java could die if it doesnt follow the modern software
> needs! you can see already now many jdk new languages trying to skip the
> java language , but if you talk with the languages teams you can see all
> tells JDK doesnt permits do do many things others VM permits(in primis
> class multi hierarchy). Java must change before developers change language!
>

From cristian.lorenzetto at gmail.com  Sun Dec 24 22:13:30 2017
From: cristian.lorenzetto at gmail.com (Cristian Lorenzetto)
Date: Sun, 24 Dec 2017 23:13:30 +0100
Subject: important discovery about a probable refactoring in jvm or OS
In-Reply-To: <CAP7YuAS=utcywypnJCWefb0dUjX9=1JWeGeMD=2_0mEXB1sJmA@mail.gmail.com>
References: <CAEsommS4=KdJDX0LA413pfDdwOTbGVwUz+mBmYjGpuJhiTU8nA@mail.gmail.com>
 <CAOgwmThDJKztLZJ8zg9dhHCrqD2Nt8z5nTGDxFzi3-jXfb_VgQ@mail.gmail.com>
 <CAEsommQ8H8SQC2Y-WrBo1DfMrDDu1iMCYwi0xPYHPtH-0f7sGA@mail.gmail.com>
 <CAP7YuAS=utcywypnJCWefb0dUjX9=1JWeGeMD=2_0mEXB1sJmA@mail.gmail.com>
Message-ID: <CAEsommTswhwk-bj=3cOnb-peXTVdX6kTvj8EOvQpMQm6rSj4gA@mail.gmail.com>

thanks for the info , i hope they will implement it ASAP. Many java
developers are moving to other languages (golang in primis). It is
necessary to act now.

Happy Christmas

2017-12-24 22:02 GMT+01:00 Martijn Verburg <martijnverburg at gmail.com>:

> Hi Cristian,
>
> See http://mail.openjdk.java.net/pipermail/discuss/2017-
> September/004390.html which discusses Project Loom.  Project Loom is
> where you'll
> want to be discussing this type of feature in OpenJDK.
>
> Cheers,
> Martijn
>
> On 24 December 2017 at 17:13, Cristian Lorenzetto <
> cristian.lorenzetto at gmail.com> wrote:
>
>> - while fibres are an important feature I have never found a use for them
>> in my space due to them being too expensive. I assume there are some very
>> good use cases for them but the growing number of cpus in a server might
>> make this less important.
>> this is completely false , it is the opposite , fibers solve a actual
>> problems . Big data acceletated to introduce it. About expensive... it is
>> opposite . I think you have a bit to go deeply in this context.
>> XML as exchange protocol is terrible  and now is completely replaced by
>> more performant and binary solution . To have a complete list about data
>> type it is important. Java is not inly used for making simple software but
>> also in engineering and high performance systems.
>> Interfaces are not multiherarchy, Interfaces are black boxes. Anyway there
>> are also problem with performance (to explain require time).
>> inline method are just when jvm decide it at runtime, but there are
>> contexts in which the developers and the software have to be
>> deterministic.In addition the inline process applied is very very trial.
>> Who study lambdas know that is a mathematical theory. When there is
>>  mathematical formula is possible to replace it with inline code. Java
>> lambdas are just a different rappresentation of objects usage. But the
>> tens
>> of years are not spent for create a theory for rename the same things.
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Peter Lawrey <peter.lawrey at gmail.com>
>> Date: 2017-12-24 17:38 GMT+01:00
>> Subject: Re: important discovery about a probable refactoring in jvm or OS
>> To: Cristian Lorenzetto <cristian.lorenzetto at gmail.com>
>> Cc: discuss <discuss at openjdk.java.net>
>>
>>
>> Hello Christian,
>>    Some quick thoughts.
>> - while fibres are an important feature I have never found a use for them
>> in my space due to them being too expensive. I assume there are some very
>> good use cases for them but the growing number of cpus in a server might
>> make this less important.
>> - i agree on unsigned esp 128 bit. Unsigned char is not enough and why
>> byte
>> is unsigned i van only assume is historical. Unsigned operations are
>> supported using the wrapper classes.
>> Personally, i feel BigDecimal should have language support ala C#.
>> - i think java will evolve to allowing multiple inheritance of classes but
>> its not needed most of the time. Esp with enhancements to interfaces.
>> - the JVM already inlines methods and there is an @ForceInline however
>> it's
>> not for public use afaik.
>> - the byte code at compile time isn't as important as the code it compiles
>> to at runtime. Lambdas do take a hit before they warm up and making
>> capturing lambdas not create garbage is a pain.
>>
>> I would point out that of the top languages, Java is one of the newest.
>> What it really needs is features older languages take for granted and are
>> widely used and understood eg structs.
>>
>> https://www.tiobe.com/tiobe-index/
>>
>> Regards Peter.
>>
>>
>> On 24 Dec. 2017 2:41 pm, "Cristian Lorenzetto" <
>> cristian.lorenzetto at gmail.com> wrote:
>>
>> As i descrived in this place https://github.com/boostorg/fiber/issues/161
>>
>> It is impossible to use JNI interface when c++ code is executing  native
>> fibers/courotines (calling a java callback). Pratically in future all new
>> software will use fibers instead threads so java will get a prison.
>> It is necessary to re design JVM with many changes
>>
>> c++ native fibers might be the java threads so JNI continue to works
>>
>> In addition i suggest
>> - to add new data type for unsigned number
>> - multyhierarchy (
>> parent classes can't have a common ancestor(except trially Object class).
>> This permits to evoid data inconsistency as explained also in Kotlin) This
>> is the just limitation for evoiding inconsitency.
>> - inline functions
>> - redesign lambdas compiler engine to trasforming lambda classes in inline
>> code (see stackoverflow ho many developers proved the bad bytecode
>> generated by actual javac)
>>
>> Pay attention ! Java could die if it doesnt follow the modern software
>> needs! you can see already now many jdk new languages trying to skip the
>> java language , but if you talk with the languages teams you can see all
>> tells JDK doesnt permits do do many things others VM permits(in primis
>> class multi hierarchy). Java must change before developers change
>> language!
>>
>
>