2

I have a problem w HotSwap Agent. It is not working correctly.

Setup:

  • JDK 11 from HotswapAgent.org
  • Widlfly 14
  • NetBeans 9
  • HotSwapAgent 1.3.1-SNAPSHOT

On start i

HOTSWAP AGENT: 08:17:59.098 INFO (org.hotswap.agent.HotswapAgent) - Loading Hotswap agent {1.3.1-SNAPSHOT} - unlimited runtime class redefinition.

In the middle i get a strange:

08:18:56,713 INFO [stdout] (ServerService Thread Pool -- 77) HOTSWAP AGENT: 08:18:56.713 WARNING (org.hotswap.agent.watch.nio.TreeWatcherNIO) - Unable to watch for path vfs:/C:/Java/wildfly-14.0.0.Final/bin/content/application.war/WEB-INF/classes/com/company/, not a local regular file or directory.

But it goes further ok. I change code, click apply code chages. It seemingly changes the code: 

Classes to reload:
 com.company.web.HeaderPanel$13
 com.company.web.HeaderPanel$2
 com.company.web.HeaderPanel$3
 com.company.web.HeaderPanel$4
 com.company.web.HeaderPanel
 com.company.web.HeaderPanel$5
 com.company.web.HeaderPanel$10
 com.company.web.HeaderPanel$11
 com.company.web.HeaderPanel$1
 com.company.web.HeaderPanel$12
 com.company.web.HeaderPanel$6
 com.company.web.HeaderPanel$7
 com.company.web.HeaderPanel$8
 com.company.web.HeaderPanel$9

Code updated

In runtime it then throws an incompatible class change error when i go to the changed class:

java.lang.IncompatibleClassChangeError: Type com.company.web.HeaderPanel$1 is not a nest member of com.company.web.HeaderPanel: current type is not listed as a nest member
    at deployment.application.war//com.company.web.HeaderPanel$1.onConfigure(HeaderPanel.java:110)

The relevant source code line is a overriden function in an anonymous class, the super. call:

 @Override
 protected void onConfigure() {
    super.onConfigure(); 
    setVisible(!ssoService.isEnabled());
 }

It is not the line i modified. I modified an completely different line.

Robert Niestroj
  • 15,299
  • 14
  • 76
  • 119
  • 2
    Does "HotSwap Agent" have a mailing issue or issue tracker? It may not have been updated to work with JDK 11 yet, in particular it may not have been updated to support the class file attributes used to support nest-based access control (see JEP 181). – Alan Bateman Nov 19 '18 at 09:37
  • @AlanBateman Could this be for the reason stated in the JEP-181 as ... *To preserve integrity of the nest it is proposed that, at least initially, it is prohibited to modify the nest classfile attributes using any form of class transformation or class redefinition.* ? – Naman Nov 19 '18 at 09:54
  • @AlanBateman they support JDK11 - the have created a special distribution of JDK 11 that requires no configuration of the HotSwap agent - http://hotswapagent.org/mydoc_quickstart-jdk11.html . And i'm using this distribution. – Robert Niestroj Nov 19 '18 at 10:05
  • 1
    @nullpointer the key point is, the nesting shouldn’t change for such a simple code modification. However, if it’s not the Agent failing to include the nesting attribute, perhaps, it’s the compiler. The compiler used to compile the modified code must have the same language level as used for compiling the original code. – Holger Nov 19 '18 at 12:04
  • @Holger apologies but I didn't get the part *The compiler used to compile the modified code must have the same language level as used for compiling the original code.* completely, is this related to the bytecode generation possibly being different from one compiler to another for the same code? – Naman Nov 19 '18 at 12:38
  • 2
    @nullpointer exactly. The `NestHost`/`NestMembers` attributes are only present when compiling with Java 11 (or newer) target. Before Java 11, the access to private members of inner/outer classes was established with synthetic helper methods, so even if changing the nest classfile attributes was allowed, it still failed as the removal or addition of methods is not. In other words, the language level must stay the same (at least regarding <11 or ≥11). – Holger Nov 19 '18 at 13:05
  • Please, create issue at https://github.com/HotswapProjects/openjdk-jdk11u – skybber Nov 25 '18 at 19:28

0 Answers0