Geekly Articles each Day
⬆️ ⬇️

The digest of interesting events from the world of Java, and around it # 5 (06/20/2016 - 07/03/2016)

image



In this issue



- Microprofile : another attempt to resuscitate Java EE

- Will Brexit hurt Java developers?

- We put on the shelves of Java Memory Model

- Profiling: AsyncGetCallTrace weaknesses

… and much more





1. News



1.1. Microprofile

Link 1: http://microprofile.io/

Link 2: https://developer.ibm.com/wasdev/blog/2016/06/27/microprofile-announce/

Link 3: http://middlewareblog.redhat.com/2016/06/27/microprofile-collaborating-to-bring-microservices-to-enterprise-java/

Link 4: http://www.tomitribe.com/blog/2016/06/microprofile/

')

Java EE continues to sink into microservice hyip. The guys from IBM , RedHat and several other companies decided to throw a lifeline to it, announcing the initiative MicroProfile.io . The task is to adjust the Java EE standards to current trends. Read - pull Java EE on microservices. And literally. For example, it is proposed to almost standardize the maximum size of the jarn and the start time of the application. Something like “enlarge your ...” is just the opposite.



The reaction to the initiative is ambiguous. Someone speaks maliciously:



Someone suggests not to waste time on obviously losing ideas:



My opinion - the initiative is certainly good. But the entire previous history of Java EE was about "standards for the sake of standards." Whether MicroPofile.io will manage to take into account the mistakes of the past and time will tell you to switch to the “standards for people” model.



Meanwhile, the situation around the Java EE freeze is heating up. So, there was another inflammatory-apocalyptic article , the essence of which in a nutshell "Oracle reptiles, everything is lost." This publication was clearly commented by James Gosling himself:

I’m tragically the opposite. Oracle is run by the highest IQ idiots I've ever met. They're torching Oracle, it's customers, they have ever acquired. The group has a lot more than EE.



We continue to follow the developments.



1.2. Brexit

Link: http://www.ibtimes.co.uk/brexit-will-london-lose-its-fintech-crown-1567222



UK out of the EU. The pound went to the peak, taking with it the quotes of the largest British banks. Every now and then there are injections about the beginning of reductions in the London offices of international financial corporations. Could this somehow affect Russian Java developers?



There will be some impact. Spoiler from Java market research, which we will begin to post in the fall: only in St. Petersburg there are about a dozen fintech companies operating, and about a hundred outsourcers of various sizes. The significant share of these companies has links to the West, including the UK. In conditions of high uncertainty, some projects will inevitably be frozen, cut down, canceled. Therefore, it is quite possible local personnel shuffling, which nevertheless should not greatly affect the overall situation in the market.



1.3. Analyzing GitHub

Link: https://cloudplatform.googleblog.com/2016/06/GitHub-on-BigQuery-analyze-all-the-open-source-code.html



The guys from Google poured public GitHub repositories into their BigQuery engine, and opened access to it for everyone. It remains to put some $ 300 in the account, and you can easily collect all sorts of statistics on this huge dataset. For example, find all uses of the sun.misc package :-)



image



Requests are recommended to be reasonable, because 1.5Tb of data in BigQuery very quickly turn dollars into a pumpkin.



2. Read



2.1. Java Memory Model

Link 1: http://shipilev.net/blog/2016/close-encounters-of-jmm-kind/

Link 2: https://groups.google.com/d/msg/mechanical-sympathy/T0pNhJSkZWQ/zHDubWKUBwAJ



The Java memory model is well-chewed in countless articles and reports. There are literally a few rules that reliably hide the details of the implementation of JVM and iron. But the developers are persistently trying to go beyond the boundaries of this elegant model, mistakenly believing that they are already well enough understood in the intestines of what is happening. It Itching. Itchy. From here grow the legs of many incorrect interpretations of the JMM. One does not need volatile on x86 , for TSO . Other blank synchronized- blocks happens-before . Third caches in memory "flush". It is difficult to fight this, since for a long time there were no clear examples on hand that demonstrated the erroneousness of such approaches and statements.



Alexei Shipilev did a titanic work, and brought together a huge number of illustrative examples of the misinterpretation of JMM. Yes, right there, where the "TSO rederring", and that's it. The size of the article would have been envied by Lev Nikolaevich, but its reading is very important. In the first from the point of view of faith - after reading you finally believe that you should not flirt with JMM.



Comment Gil Tene on the second link brings a thick line under the foregoing.



2.2. Profiling and AsyncGetCallTrace

Link: http://psy-lob-saw.blogspot.ru/2016/06/the-pros-and-cons-of-agct.html



Recently there has been a lot of discussion around the AsyncGetCallTrace method, which allows you to capture a stream dump without requiring a stop at a safepoint . For example, based on it built Honest Profiler . In his post, Nitsan shows some of the weaknesses of this approach. For example, the inability to profile intrinsics.



I think that in the near future the JMC + Honest Profiler bundle can become the standard of the first profiling line, since they complement each other very well.



After a fresh video from Nitsan's report on profiling:





2.3. About JIT

Link: https://www.infoq.com/articles/OpenJDK-HotSpot-What-the-JIT



Good article about the features of JIT. The issues of tiered compilation, deoptimization, intrinzik, etc. It is written light and interesting.



By the way, there is one solution in the JVM that I personally don’t understand - why is the code cache separate from metaspace ? More than once I ran into a problem when, with the active work of the class-clashers, it was necessary to tune these two parameters in parallel. Otherwise, just at some point the compilation is cut off. One metaspace can not do it? And in general, it feels like metaspace , that code cache is currently rather poorly integrated into the GC infrastructure. For example, you can easily get an overflow of code cache , although no one needs unnecessary classes in metaspace.



2.4. GC visualization

Link: http://mattwarren.org/2016/06/20/Visualising-the-dotNET-Garbage-Collector/



Matt Warren visualized the work of the GC in the process of the application. True, not in Java, but in .NET :-) But still interesting. Is there something similar for Java? And how much is it possible / convenient in Java to receive notifications about GC events?



3. Wisdom



3.1. Perfect software



3.2. Protocols against implementations





4. Humor



4.1. What to do if you raised investment in an IT startup?

Of course, hire a chef to feed the dogs!

Honestly, it looks like a viral ad.



Issues: Previous - Next

Source: https://habr.com/ru/post/304624/

More articles:



All Articles