On 03/07/2017 19:27, Jonathan Gibbons wrote:
Looks good to me.
-- Jon
Thumbs up from me too.
-Alan
Looks good to me.
-- Jon
On 7/3/17 10:52 AM, mark.reinh...@oracle.com wrote:
2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com:
Mark,
The font-family settings in the nodes were deliberate, and a
workaround for not having time to create a proper taglet for tool guides.
If you remove the
On 07/03/2017 10:52 AM, mark.reinh...@oracle.com wrote:
2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com:
Mark,
The font-family settings in the nodes were deliberate, and a
workaround for not having time to create a proper taglet for tool guides.
If you remove the style attribute, you'
2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com:
> Mark,
>
> The font-family settings in the nodes were deliberate, and a
> workaround for not having time to create a proper taglet for tool guides.
>
> If you remove the style attribute, you'll see in your sample output that
> the "Tool G
On 7/3/17 9:11 AM, Alexander Udalov wrote:
Hi Sander,
Have you tried using `--patch-module` during compilation of the Java sources
(as described in http://openjdk.java.net/jeps/261)? Not sure if it works with
class files in the patch directory as well, but it sounds like it could address
y
Hi Sander,
> Have you tried using `--patch-module` during compilation of the Java sources
> (as described in http://openjdk.java.net/jeps/261)? Not sure if it works with
> class files in the patch directory as well, but it sounds like it could
> address your usecase.
This fixes my problem comp
On 7/3/17 6:36 AM, Sander Mak wrote:
On 3 Jul 2017, at 15:23, Alexander Udalov
mailto:alexander.uda...@jetbrains.com>> wrote:
But in circumstances where the destination
directory could be different for class files compiled by Java and
non-Java, I see no way to make the Java compiler read th
On 3 Jul 2017, at 15:23, Alexander Udalov
mailto:alexander.uda...@jetbrains.com>> wrote:
But in circumstances where the destination
directory could be different for class files compiled by Java and
non-Java, I see no way to make the Java compiler read the class files
compiled by the non-Java co
> In the module, does the non-Java source code reference the Java code or is
> it the other way around? It would be useful for thread to understand the
> order that they need to be compiled. As you use the term "augment" then I'm
> guessing that the Java code is compiled first, without reference to
On 03/07/2017 12:57, Alexander Udalov wrote:
:
Thanks, a dummy class certainly workarounds the problem of javac
reporting a compilation error here. However, I hope there's a better
way because it'd be a bit strange to force users to create a dummy
Java class in every exported package in pure X mo
Hi Alan,
> I don't think so, but a dummy class/interface will do (it doesn't have to be
> public). There is a lengthy discussion on this topic in JIRA from 2016 that
> would be useful to link to (but I can't find it just now because JIRA is
> down for maintenance).
Thanks, a dummy class certainly
Hi Jonathan,
> Converting the error to a warning (as was suggested in the original post
> in this thread) would not address the case where the Java source code
> needs to refer to types declared in class files generated from non-Java
> sources.
You're right. For some reason, I was thinking of pa
On 01/07/17 14:57, Stephen Felts wrote:
> IMO:
>
> 1. You should avoid `--add-modules java.se.ee' unless you need all of those
> modules. You should bring in only those modules that you need. The choices
> are java.activation, java.corba, java.transaction, java.xml.bind,
> java.xml.ws,
> jav
On 01/07/17 10:53, Alan Bateman wrote:
> On 01/07/2017 10:18, Mark Thomas wrote:
>> Hi,
>>
>> Apache Tomcat needs to add the following options when running on Java 9:
>>
>> --add-modules=java.se.ee
>> --add-opens=java.base/java.lang=ALL-UNNAMED
>> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
14 matches
Mail list logo
