Netty 4.0.51 and 4.1.15. final versions released

New updates for a NIO client server framework available now
29 August 2017   2324

New bugfix releases for Netty 4.0.x and 4.1.x series available now. 

What is Netty? 

Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server.

'Quick and easy' doesn't mean that a resulting application will suffer from a maintainability or a performance issue. Netty has been designed carefully with the experiences earned from the implementation of a lot of protocols such as FTP, SMTP, HTTP, and various binary and text-based legacy protocols. As a result, Netty has succeeded to find a way to achieve ease of development, performance, stability, and flexibility without a compromise.

Netty architecture
Netty architecture

Main features:

  • Design
    • Unified API for various transport types - blocking and non-blocking socket
    • Based on a flexible and extensible event model which allows clear separation of concerns
    • Highly customizable thread model - single thread, one or more thread pools such as SEDA
    • True connectionless datagram socket support (since 3.1)
  • Ease of use
    • Well-documented Javadoc, user guide and examples
    • No additional dependencies, JDK 5 (Netty 3.x) or 6 (Netty 4.x) is enough
  • Performance
    • Better throughput, lower latency
    • Less resource consumption
    • Minimized unnecessary memory copy
  • Security
    • Complete SSL/TLS and StartTLS support

What's new in updates?

These releases contains bug-fixes, performance enhancements and features.

The most important changes for 4.0.51.Final and 4.1.15.Final are:

  • Support JDK9-native ALPN 
  • More bullet-proof way of detecting if ipv6 is supported or not when using the native transport 
  • DelegatingSslContext should also be able to configure the SslHandler 
  • Netty 4.1.14.Final fails to load on android
  • Include JNIEXPORT on exported symbols 
  • Unify KQueue and Epoll wait timeout approach 
  • Make NativeLibraryLoader check java.library.path first 
  • Use the ByteBufAllocator when copy a ReadOnlyByteBufferBuf and so also be able to release it without the GC when the Cleaner is present 
  • Ensure netty builds with java9 (build 9+181) 
  • Make configurable the initial and max size of InternalThreadLocal.stringBuilder 
  • Fix endless loop in ByteBufUtil#writeAscii 
  • Correctly support SO_TIMEOUT for OioDatagramChannel 
  • Ensure we null out the previous set InetAddress on 
  • Correctly handle connect/disconnect in EpollDatagramChannel
  • Shutting down the outbound side of the channel should not accept future writes

The most important changes for 4.1.15.Final only are:

  • Decouple DnsCache and DnsCacheEntry 
  • KQueue detect peer close without EVFILT_READ
  • Support the little endian floats and doubles by ByteBuf 
  • We should prefer heap buffers when using the OIO transport to reduce memory copies 
  • First call channelReadComplete(...) before flush(...) for better performance 
  • HTTP/2 Child Channel and FrameCodec Feature Parity  

 Learn more at official website.

Most Popular Java Snippet At StackOverflow is Flawed

The code in question was posted in 2010 and has accumulated over a thousand recommendations, and can be found in 7k GitHub repos
05 December 2019   120

The most popular example of Java code published on StackOverflow turned out to be an error leading to the conclusion, under certain conditions, of an incorrect result. The code in question was posted in 2010 and has accumulated over a thousand recommendations, and has also been copied to many projects and is found in repositories on GitHub about 7 thousand times. It is noteworthy that the mistake was not found by the users copying this code into their projects, but by the original author of the council.

The considered code converted byte size into readable form, for example 110592 converted to "110.6 kB" or "108.0 KiB". The code was proposed as a logarithm-optimized version of the previously proposed tip, in which the value was determined by dividing the initial value in a cycle by 1018, 1015, 1012, 1019, 106, 103, and 100, until the divisor is larger than the original value in bytes . Due to inaccurate calculations in the optimized version (overflow of the long value), the result of processing very large numbers (exabytes) did not correspond to reality.

The author of the council also tried to draw attention to the problem of copying examples without reference to the source and without specifying a license. According to a previous study, 46% of developers copied the code from Stack Overflow without specifying the author, 75% did not know that the code is licensed under CC BY-SA, and 67% did not know that this implies the need for attribution.