> chances of meeting a module-info.class with funky module names is low
When I raised the initial question, I had no idea that the Java verifier
had been changed (with Java 6?) to allow "funky" package, class, field and
method names. Somehow that change passed right under the radar. Yes - a
possibl
Lois, Mandy,
On 2017-01-05 22:19, Lois Foltan wrote:
>
> On 1/5/2017 11:47 AM, Claes Redestad wrote:
>> Hi,
>>
>> after a round of review comments I've now reworked this to do the
>> transformations in the JNI layer rather than inside the VM, with
>> similar - if not better - results.
>>
>> Webre
Hi Jonathan,
thanks for checking things out. :)
so long ... Nicolai
On 05.01.2017 22:48, Jonathan Gibbons wrote:
> Nicolai,
>
> We've identified the cause of the issue you reported. Although
> javac accepts --class-path as an alias for -cp and -classpath, what
> is notable about your examp
On 1/5/2017 1:16 PM, Rony G. Flatscher wrote:
The rule for using the Java bridge for the Rexx programmers has always been
very simple: you are
only allowed to use public Java classes, public Java fields and public Java
methods as these are
guaranteed to be available to everyone at all times.
T
On 05.01.2017 21:07, Phil Race wrote:
Sort of .. it depends whether you could use getDeclaredMethod instead.
One question I have is, how would you update the code if you
were given the instance "foo", and need to programmatically
work out what is the correct super-type of Foo that exports
the in
Nicolai,
We've identified the cause of the issue you reported. Although javac
accepts --class-path as an alias for -cp and -classpath, what is notable
about your example is that it is using "classpath wildcards" (i.e. the
"*" in -cp "mods/*"), which is implemented within the native javac
lau
Just realized that the emails get divided now to jdk9-dev and jigsaw-dev (where
most replies
occurred). Hence added a reply-to to jigsaw-dev.
---
On 05.01.2017 20:31, Remi Forax wrote:
> In your script,
> when you execute a.b().c(),
> you should not call getClass() on the result of a.b() but usin
> On Jan 5, 2017, at 8:47 AM, Claes Redestad wrote:
>
> Hi,
>
> after a round of review comments I've now reworked this to do the
> transformations in the JNI layer rather than inside the VM, with
> similar - if not better - results.
>
> Webrevs:
> http://cr.openjdk.java.net/~redestad/8171855/
On 1/5/2017 11:47 AM, Claes Redestad wrote:
Hi,
after a round of review comments I've now reworked this to do the
transformations in the JNI layer rather than inside the VM, with
similar - if not better - results.
Webrevs:
http://cr.openjdk.java.net/~redestad/8171855/hotspot.03/
http://cr.open
On 05.01.2017 21:07, Phil Race wrote:
> Sort of .. it depends whether you could use getDeclaredMethod instead.
>
> One question I have is, how would you update the code if you
> were given the instance "foo", and need to programmatically
> work out what is the correct super-type of Foo that exports
Thanks Ess and Remi for noticing the missing zero for *_index items (and
for the stray ModuleVersion reference).
On 12/27/2016 11:55 PM, Remi Forax wrote:
Hi,
- Mail original -
De: "Ess Kay"
À: jigsaw-dev@openjdk.java.net
Envoyé: Mardi 27 Décembre 2016 23:54:06
Objet: Issues in "JPMS
Sort of .. it depends whether you could use getDeclaredMethod instead.
One question I have is, how would you update the code if you
were given the instance "foo", and need to programmatically
work out what is the correct super-type of Foo that exports
the interface method "bar" ?
i.e you don't h
Sort of .. it depends whether you could use getDeclaredMethod instead.
One question I have is, how would you update the code if you
were given the instance "foo", and need to programmatically
work out what is the correct super-type of Foo that exports
the interface method "bar" ?
i.e you don't h
Phil,
This is not a new problem per se, you already had this "bug" if the returned
class at runtime was a class not declared public,
it's just more visible in the modular world of Java 9 because to be accessible
a class has to be declared public *and* the package has to be exported.
cheers,
Rémi
> On Jan 5, 2017, at 5:14 AM, Chris Hegarty wrote:
>
>
>> I wonder if it would be more helpful if it fails when a non-repeating option
>> is specified more than once for a packaging tool. Otherwise, the only way
>> to find out if the command-line is correct is to list the content after the
Just for clarification .. I was also testing what happened with
getDeclaredMethod (which is not delcared on that X11 sub-class) .. and that
caused the NoSuchMethodException I pasted in my previous email.
With "getMethod" I see what Rony reports.
~/jdk9b142/bin/java TK8
class sun.awt.X11.XToolkit
ah yes .. I can see how one might code that way.
I don't know how common a problem this is, but
such code will need to be updated.
import java.awt.Toolkit;
public class TK8 {
public static void main(String args[]) throws Exception {
Toolkit tk = Toolkit.getDefaultToolkit();
Rony mentioned "the returned Toolkit is of type sun.awt.X11.XToolkit"
which suggests that he is calling getClass() on the result of
getDefaultToolkit(), and then reflecting further on that Class object
and its Methods. As has been discussed previously on jigsaw-dev, this
won't work for implemen
This should be discussed on jigsaw-dev.
But can you share your code ? - since the following works for me :
import java.awt.Toolkit;
public class TK {
public static void main(String args[]) throws Exception {
Toolkit tk = Toolkit.getDefaultToolkit();
Class tkc = Class.forName(
Hi,
after a round of review comments I've now reworked this to do the
transformations in the JNI layer rather than inside the VM, with
similar - if not better - results.
Webrevs:
http://cr.openjdk.java.net/~redestad/8171855/hotspot.03/
http://cr.openjdk.java.net/~redestad/8171855/jdk.03/
Testin
Thank you for the report. It is obviously intended that these options
should simply be aliases for each other, but I will see if there is
something else going on to explain what you are seeing.
-- Jon
On 1/5/17 3:23 AM, Nicolai Parlog wrote:
Hi,
during experimentation I encountered compil
Alan Bateman wrote on 01/05/2017 06:23:46 AM:
> I'm curious what the typical use-case is for this. Most of time that
> I've seen discussions on fragments then it was about adding i18n
> resources but there are other ways to do that sort of thing (i18n
> bundles can be deployed as service provide
> On 4 Jan 2017, at 21:03, Mandy Chung wrote:
>
>
>> On Dec 22, 2016, at 9:11 AM, Chris Hegarty wrote:
>>
>> Most options for the jmod tool should be last one wins, to be consistent
>> with the JDK tool convention, 8168149 [1]. Excludes is the only
>> repeatable option.
>>
>> Given the exist
On 5 January 2017 at 10:22, Ess Kay wrote:
> There are utilities out there now that
> manipulate bytecode that are driven by script files that specify Java
> identifiers using a Java-style syntax. I raised the initial question
> because I have the job of updating such a utility to support Java 9
On 04/01/2017 15:15, Thomas Watson wrote:
:
In theory fragments can be dynamically attached to an already resolved
host (module) which implies that we need to be able to dynamically add
packages to the existing host module. With that in mind, if we wanted
to support dynamic attachment of fr
On 05/01/2017 08:22, Ess Kay wrote:
No, that's not how it works at all ... Only container code will be
creating or referencing such modules
This may be true for JBoss & JEE modules.
I see "Java EE modules" have been mentioned a few times in this thread.
Aside from the word "module" then I'm no
Hi,
during experimentation I encountered compiler behavior that I found
rather strange: It looks like the -classpath and --class-path options do
not behave the same way.
In my experiment I create a bunch of modules in 'mods' and then create
the last one by putting the modules on the class path (
> No, that's not how it works at all ... Only container code will be
creating or referencing such modules
This may be true for JBoss & JEE modules. However, the very reason I
raised the initial question was because it is NOT true for identifiers
embedded in Java bytecode. There are utilities out
28 matches
Mail list logo
