包冲突解决之-invalid constant type: 18

背景

现象一：引入了一个包A，服务突然起不来了，后台有报错信息，Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'xxx' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
现象二：多次重启服务，有一定的概率能够启动（初步怀疑是包冲突）

启动不了的时候，报错的bean写法如下

package mypackage;@Slf4j
@MyComponent
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class MyBean{
XXX
}

上述他使用自己定义的注意，然后通过自定义的beanDefinitionRegistar扫描这类bean

public class MyComponentConfigRegister implements ImportBeanDefinitionRegistrar {public void registerBeanDefinitions(@NotNull AnnotationMetadata importingClassMetadata, @NotNull BeanDefinitionRegistry registry) {//获取到所有包含这些注解的类之后，我们添加到spring容器中去即可Set<Class<?>> annotated = new Reflections(new ConfigurationBuilder().forPackage("mypackage").setScanners(Scanners.values())).get(TypesAnnotated.with(MyComponent.class).asClass());    
}

初步追查，bean找不到问题
1. 现象很简单，spring中最常见的问题了，少了一个bean；背景也只自定义一个beanDefinitionRegsitar扫描背@MyComponent注明的类。
2. debug这个MyComponentConfigRegister 。发现了一个很奇怪的问题，
  1. 核心代码， Set<Class<?>> annotated = new Reflections(new ConfigurationBuilder().forPackage("mypackage").setScanners(Scanners.values())).get(TypesAnnotated.with(MyComponent.class).asClass());
  2. 扫描出来的annotated就是没有MyBean这个类
  3. 可以观察到他的反射包使用的是Reflections类，来自jar包reflections
3. 问题是，为啥包里面没有有这个类MyBean，通过Reflections就是扫描不到呢？？
4. debug过程中，另外发现一个问题，同一个包路径下的类，MyBean1，就是可以被扫描到，但是Mybean就是不行。
```
package mypackage;@Slf4j
@MyComponent
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class MyBean1{
XXX
}
```
继续追查，Reflections获取不到反射的问题
1. debug Reflections类，在他的scan方法里面初见端倪，
2. 处理mybean的时候，会报错误，invalid constant type: 18
3. 因为，日志级别是trace，所以服务器日志上看不到这个错误信息。
继续追查，invalid constant type: 18，是什么问题
1. stackoverflow上已经有类似的问题，Reflections - Java 8 - invalid constant type - Stack Overflow
2. 帖子的结论很简单：Reflections依赖的javassist版本太低了，不支持java8的特性。例如stream的使用
3. 至此，问题定位到。而且Mybean的写法和MYbean1的写法中区别就是，myBean使用了stream，所以Reflections在扫描的时候报错了。
问题解决：
1. 升级Reflections依赖的javassit的版本
继续：
1. 到这里问题应该解决了，发布代码问题也确实解决了。
2. 但是，，，好像还有一个遗留的疑问，最开始的时候，为啥重启多次也能解决呢。
3. 看看最初的版本依赖，，其第一个有问题的jar包路径更短。理论上是100%错误，不应该重启多次就好
4. 最终发现，2个包的坐标不一样，他们的groupid不一致导致的，2个jar包不会报冲突，在jvm启动时加载那个jar包都有一定的几率，