hi,
most of the open sources jars have classes with unnamed package, like
nar-maven-plugin.
Any idea how can i solve this? Do i have to implement my own version of
ModuleFinder?
Some examples: D:\.m2\jdom\jdom\1.0\jdom-1.0.jar,
D:\.m2\net\java\dev\javacc\javacc\5.0\javacc-5.0.jar,
D:\.m2\
Charbel, have you looked into the Maven Shade Plugin? I wonder if you could
shade what's in the unnamed package so as to put it in some other named
package?
Cheers,
Paul
On Tue, Aug 2, 2016 at 2:21 AM, charbel yazbeck wrote:
> hi,
>
>
> most of the open sources jars have classes with unnamed p
On 01.08.2016 16:04, David M. Lloyd wrote:
With my proposal, if there are any
doubts about a class, you make it non-public (regardless of what package
it is in), which is a very simple criterion. In addition, you make the
public/non-public choice on a per-class basis, not a per-package basis,
On 02/08/16 08:21, charbel yazbeck wrote:
> most of the open sources jars have classes with unnamed package, like
> nar-maven-plugin.
Hmm, citation needed for that I think.
In my experience it is extremely rare for production code to place
classes in the unnamed module. It is extremely bad prac
Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8159487
OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
fix. Just adding "JAVA_VERSION" and a test change to check these
properties exist in release file.
Than
On 01.08.2016 16:04, David M. Lloyd wrote:
On 08/01/2016 05:40 AM, dalibor topic wrote:
Is it safe to assume that all such involuntarily headache inducing
Slings and Stones are also kept under lock in non-public classes?
Of course not, no more than it is safe to assume that such will be kept
+1
> On Aug 2, 2016, at 8:39 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8159487
>
> OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
> fix. Just adding
On 02/08/2016 00:21, charbel yazbeck wrote:
hi,
most of the open sources jars have classes with unnamed package, like
nar-maven-plugin.
Any idea how can i solve this? Do i have to implement my own version
of ModuleFinder?
Some examples: D:\.m2\jdom\jdom\1.0\jdom-1.0.jar,
D:\.m2\net\ja
On 02/08/2016 04:39, Sundararajan Athijegannathan wrote:
Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8159487
OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
fix. Just adding "JAVA_VERSION" and a test c
On 2 August 2016 at 12:49, dalibor topic wrote:
> Let's now consider two different scenarios, in which Sling and Stone are
> either public, or not, and denote the variants with a P or N prefix - PSling
> is a public Sling, while NStone is a non-public Stone, for example.
>
> Let's also consider tw
Changeset: 8e042568422f
Author:alanb
Date: 2016-08-02 05:56 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e042568422f
javax/smartcardio/TerminalFactorySpiTest.java failing
! test/javax/smartcardio/TerminalFactorySpiTest.java
On 02/08/16 13:01, Alan Bateman wrote:
> HelpMojo seems to be something to do with Maven Plugin Plugin. It
> doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0
HelpMojo is indeed something to do with the Maven Plugin Plugin. The
latter will generate a class called HelpMojo on demand to
Hi,
Top-package (unnamed package) classes can not be referenced from classes
in named packages anyway, so they usually represent just reflective
entry points (such as Main class with main() method). If a jar is used
as an automatic module, it would probably be safe to just ignore any
classes
Hi Lois,
Thanks for the review. Please see comments in-line.
Harold
On 8/1/2016 8:40 PM, Lois Foltan wrote:
On 7/17/2016 7:05 PM, harold seigel wrote:
Hi,
Please review these Hotspot VM only changes to process the seven
module-specific options that have been renamed to have gnu-like
nam
hi,
i would vote for that...
thank u
De : Peter Levart
Envoyé : mardi 2 août 2016 13:19
À : Andrew Dinn; Alan Bateman; charbel yazbeck; jigsaw-dev@openjdk.java.net
Objet : Re: Issue with an automatic module
Hi,
Top-package (unnamed package) classes can not b
On 02/08/2016 06:19, Peter Levart wrote:
Hi,
Top-package (unnamed package) classes can not be referenced from
classes in named packages anyway, so they usually represent just
reflective entry points (such as Main class with main() method). If a
jar is used as an automatic module, it would pr
Seems to be a reasonable idea :)
Rem
On August 2, 2016 6:19:45 AM PDT, Peter Levart wrote:
>Hi,
>
>Top-package (unnamed package) classes can not be referenced from
>classes
>in named packages anyway, so they usually represent just reflective
>entry points (such as Main class with main() metho
Hi Peter,
Thanks for bringing up the semantics issue of clearCache. You are right.
There's some semantics change in clearCache(ClassLoader). Let me look
into it.
The format field-related changes look good to me.
Thanks,
Masayoshi
On 8/1/2016 11:10 PM, Peter Levart wrote:
Hi Masayosh, Alan,
On 02.08.2016 15:19, Peter Levart wrote:
Hi,
Top-package (unnamed package) classes can not be referenced from classes
in named packages anyway, so they usually represent just reflective
entry points (such as Main class with main() method).
In Java that is you mean. The JVM does not care about
Correct me if wrong, but it seems there is no universal way to flag
something as compiler/tool generated. My take away from Alex's comments is
that ACC_SYNTHETIC is very much concerned with implicitness/explicitness...
but why? I still don't understand why it *must* be concerned anything like
that.
There's so much to tackle on this thread...
On 8/2/16 5:47 AM, Stephen Colebourne wrote:
IMO, we need to get existing OSS libraries migrated to modules ASAP to
maintain the ecosystem, which requires the migration to be really
simple. Get this wrong, and we'll all just carry on using the
classpat
21 matches
Mail list logo
