关于反射时经常使用的 AccessibleObject.isAccessible()
方法,我一直以为是被 public
修饰就返回 true
,其他的就返回 false
,今天调试代码时发现对 ArrayList
的无参构造函数调用 isAccessible()
返回的竟然是 false
,于是查阅了相关代码,在 java.lang.reflect.AccessibleObject
类中有以下代码:
1 | /** |
关于反射时经常使用的 AccessibleObject.isAccessible()
方法,我一直以为是被 public
修饰就返回 true
,其他的就返回 false
,今天调试代码时发现对 ArrayList
的无参构造函数调用 isAccessible()
返回的竟然是 false
,于是查阅了相关代码,在 java.lang.reflect.AccessibleObject
类中有以下代码:
1 | /** |
As of update 6 within Java 7’s lifetime, the behaviour of substring changed to create a copy - so every String refers to a char[] which is not shared with any other object, as far as I’m aware. So at that point, substring() became an O(n) operation where n is the numbers in the substring.
由于有时需要验证 Tomcat 的问题或者调试其内部代码,所以需要在本地 IDEA 搭建 Tomcat 的开发环境,在此简单记录。
整个过程根据官方的构建文档调整而来,参考:Apache Tomcat 8 (8.5.70) - Building Tomcat。
首先确认机器安装了 Java SE Development Kit 8 及 Apache Ant,我本地使用的版本是 JDK 1.8.0_291 及 Ant 1.10.8_1。
关于 HTTP 请求中的 header 键的名称,如果打开 chrome 的调试控制台,可以观察到大部分 HTTP header 的键的名称都使用 -
进行分隔,其规范在 RFC 2616 4.2 Message Headers 中指向的 RFC 822 3.1.2 STRUCTURE OF HEADER FIELDS 中进行了说明:
The field-name must be composed of printable ASCII characters (i.e., characters that have values between 33. and 126., decimal, except colon).
文档表示 ASCII 值在 33 至 126 的字符(除了冒号)都是合法的,但是在之前的一次问题排查中,花了不少时间来定位 header 丢失的问题,最终定位是中间的 NGINX 代理服务器将含有下划线的 header 丢掉了,其中 NGINX 的配置为 Module ngx_http_core_module,默认会丢掉含有下划线的 HTTP header,关于该问题的描述如下:
Missing (disappearing) HTTP Headers
If you do not explicitly set underscores_in_headers on;, NGINX will silently drop HTTP headers with underscores (which are perfectly valid according to the HTTP standard). This is done in order to prevent ambiguities when mapping headers to CGI variables as both dashes and underscores are mapped to underscores during that process.
记录该问题是因为今天同事又遇到了,说接收不到三方平台推送的 header,我排查后发现又是中间的 NGINX 代理服务器使用的默认配置导致含有下划线的 HTTP header 键被丢弃了。
Why do HTTP servers forbid underscores in HTTP header names - Stack Overflow
The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class’s exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.
There are several constant interfaces in the java platform libraries, such as java.io.ObjectStreamConstants. These interfaces should be regarded as anomalies and should not be emulated.