Peter Verhas

After DZone published it, I cannot change the title.

I do not see why your suggested title would be better than the original title.

Your comment sounds like a correction to the article, but I do not see what you want to correct. On the contrary: there is a sentence that says exactly just like what you have said. Could you be more specific about what you want to correct?

"may fire employe using it"

It is a little harsh. I hope this is more an exaggeration and you are not serious. I rather approach any employee who is using a construct with questions about the why and then perhaps mentoring. Perhaps some of them may tell you that they know something that you do not and that may change your opinion.

You are absolutely correct that this is more boilerplate code. Boilerplate code must not be written by the developers, but sometimes we cannot avoid it. That is when the code generators come in place. Java::Geci (https://github.com/verhas/javageci) is framework to write code generators in a very simple way that can in many cases replace the manual maintenance of boilerplate code with code generation. As a matter of fact the framework has a sample code generator, fluent, which does generate the boilerplate code for fluent builders from a simple syntax description string. (See my comment about it above.) You may like this solution.

There is a close to ideal solution. The fluent API that can be created can be modeled using FSA. An FSA can be described by a regular expression. In this case, not a conventional regex, where the alphabet contains the characters, but rather a regular expression over the set of methods as an alphabet.

The code generator "fluent" being part of the core code generators of the code generation framework Java::Geci (https://github.com/verhas/javageci) automatically converts the regular expression, which is a syntax description of the fluent API to the interfaces and inserts these interfaces into your class. If you modify the syntax it runs again and updates the generated part of your code.

This eliminates most of the burden of the maintenance of the fluent API. What you have to pay is that you have to include a new test dependency (Java::Geci generators run as unit tests and fail if they modified the code), fire up a new unit test configuring the generator and put a @Fluent(...) annotation on the class with the syntax in the place of the ...

Many times composition is better than inheritance. In principle they are equivalent. As a matter of fact, Go implements inheritance through composition... kind of.

I would be more than delighted if you could look at the example issue and help me how to use composition instead of inheritance there. The simplified A, F, C example may be oversimplified for the sake of the example.

"why another generator"

Not really. Java::Geci is not a source code generator. It is a source code generator framework, or source code generator support library, whichever you like more naming it. Creating setter and getter only would not be a big deal. It is only an example demonstrating how easy it is to code such a generator using Java::Geci.

"What is the support in Intellij idea"

The generated code goes into segments that are delimited by editor folds, which can be collapsed in the editor. It is supported by all IDEs not only IntelliJ.

"Isn't better to use let's say .. Kotlin?"
This is a far-reaching question and not really related to code generation. As Kotlin is a more modern and more progressive language there are many cases when you do not feel the urge to generate code, while the same problem shouts out for code generation in Java. This does not, however, mean that all problem can be solved easily and the best ways in Kotlin without code generation. All languages have their limitations. If the language is very rich and feature full then the limitation is that developers will not learn all the features and it will be hard to maintain the code of the others' who use a feature that I have not learned or just forgot already. That is why languages have limitations in their expressiveness and features. When a problem reaches that limit you will code repetitive code or you will use code generators. The latter, in my opinion, is the simplest using Java::Geci.

This article is one of a series that details how to create code generators and not how to use them. The example is a simple one but in the project, there are much more complex samples. I do not know any other code generator, for example, that automatically creates all the interfaces for a fluent API based on the FSA, regular expression like syntax definition. Not even Kotlin does that.

I would recommend not to get to such conclusion so fast.

I absolutely agree with you that it depends on the programmer. There are programmers whose code is a pain to read no matter what language the code is written.

Item 18, anonymous classes: like with the tuples mentioned in the comments, the methods that are new and not overriding the abstract method can also be invoked. The type when inferred is not the type of the abstract class, which is extended, but the generated name of the anonymous class.

I see no reason to exploit this possibility, but it is to know.

Very comprehensive and simple article. I mean simple as a good thing. Articles should be simple so that I can understand them.

If you need to change the value of that field then do not declare it to be final. Full stop. If you need to change a final field then it is a code smell. Even if you want to do that to perform tests only.

At the source publication I updated the article (that I cannot do here):

UPDATE:
https://twitter.com/snazy pointed out that the part of the code

for (int pos = 0; pos < size; pos++) {
if (m1.get(pos) != m2.get(pos)) {
System.out.println("Files differ at position " + pos);
return;
}
}
can be replaced using the built-in ByteBuffer::mismatch method. The code is simpler, it does exactly what the example code is aiming and it is probably faster.

You can create a release offline and push to github to publish you OSS projects. Simpler than nexus service.

"In addition, if the service is not in the application module"

What does it mean that the service is not in the application module? There are two separate things: the interface that defines the behavior of the service and the implementation. You have to 'requires' the interface if it is defined in a different module and it has to be exported by that module.

If the service is the "interface" then the statement is correct. If it means the implementation then it is not. The fact that the documentation was misleading me, who has a lot of experience with Java indicates that either the verbiage of the statement above is not the best choice or I start to be senile.

Summing up: what you say is absolutely correct.

Your article is detailed and describes the difference between the *usual* session store and *usual* caching. However when you hear the sentence "Our app runs fast because we cache all the session data" you can not be sure what cache they are talking about. (Btw: was it web session or javax.mail.Session? Possible, though not likely.)

As a summary: the article is good and outstanding compared to other DZONE articles. On the other hand, you could emphasize more that you are talking about one specific and most frequently used session store and cache implementation.

Yes, those are all valid concerns that somebody who want to use the functionality for professional purpose has to face.

Yes, you are absolutely right. I missed the point that the bytes in the file may represent unicode characters. Important point if someone would like to implement something similar for professional purposes. Thanks for finding the issue and that you wrote it here.

You probably cannot do that. A `CharSequence` has to implement the method `length()` and you do not know the length of the file, which is dynamically written, as it continually grows. On the other hand the length of a character sequence is supposed to be constant.

The specification of `CharSequence` does not explicitly states that as a requirement, but as I was experimenting with `splitAsStream` the length is queried many times and the outcome is not what you would expect if the length grows.

The article does not provide any example execution. If the developer can not create samples themselves then it is better that there is no execution sample.

javax0.wordpress.com

Yep. Thanks for the note. I will fix that on the original article. DZONE does not provide fix/update facility and they do not seem to care.

I can see articles these days use method references like in Java 8:

`Mammal::speak`

That is why I said "unfortunate".

I feel I offended you, let me try to amend that. You seem to be a talented young professional and I appreciate that. I offer you the following deal:

I suggest that you write an article about equals and hashCode and before publishing it send me. I will review and send you my comments same scrutiny as I do when I review a document on professional purposes. Free of charge, no need to reference that I reviewed, whatsoever. My contact parameters are on the internet.

Thanks. It does not change the my opinion that this notation in this article targeting novice programmers is unfortunate.

Your personal comments are left unattended.

"So, for the compiler, this call is Mammal.speak()."

So, for the compiler, this call is invoking the speak() method defined in the Mammal class.

It is not a notation. Just write it down. I'd appreciate if you could give a specific example to the Java API where the static method call like notation is used to denote non-static method call. I have no time to search for it myself. Thank you.

You should never implement equals and hashCode unless it is a must. Their contract says that if you override one, then you should override the other as well. Even though it is permissable to override one and not the other in some exceptional cases when a developer knows the details of how the different JDK classes relying on these methods work, but I will not get into details here, because evidently it is too complex for most of the audience including the author.

Do not advocate wrong ideas.

P.S.: I assume you meant "real time" -> "real life" as for the projects.

In your text you use the notation "Mammal.speak()" to denote the method 'speak()' of the class Mammal. This is an unfortunate notatiion, because juniors, who are actually the main target of your article may confuse it with static method call, which it is not.

"For example, we always override equals, hashCode, and toString from the Object class."

No, we do not. For example your Mammal, Cat and Human classes do not.

InputStream in = null; <- input, variable name is not consistent

The example in Step-3 is totally confusing. The variable names are not consistent. The list should be separated by comma or semicolon?

Please fix these, and then delete my comment as not relevant.

Perhaps ask him? ;-)

He is a nice person.

You should have a look at the article

https://blog.jooq.org/2012/01/05/the-java-fluent-api-designer-crash-course/

from Eder Lukas. It is also to mention

https://www.martinfowler.com/bliki/FluentInterface.html

about fluent interfaces. It may also be worth looking at the Annotation Processing Tool

https://github.com/verhas/fluflu

If you do not use setters and getters and you introduce them then the change in the declared API will cause an error during compile time. If you use setters and getters and do not change the calling sequence (a.k.a. the names of the method and the arguments remain the same) then the error manifests during run-time.

So... what is the advantage?

There is another disadvantage: you can change the behavior of the setter and the getter without imposing change on the code that uses them. The example usually is when we handle the null as a value in a special way. The default setter and getter does not handle the null in any way special, it is just a value as any other.

The documentation may say that null value should not be passed, but the real contract is, how the code works. Average developers do not read the documentation and tend to abuse available callable methods in any way they work rather than only in the limited way the API is defined (remember Sun's unsafe package).

Let's approach this question pragmatic, like Robinson Cruspe did: what are the advantages and what are the disadvangateges.

The disadvantages are evident. More code written automatically by the IDE means more code to read and understand during maintenance. It takes expensive seconds to recognize that there is nothing else there in the code, but the generated default setter and getter.

Be aware that java and jit are free to assume that ANSWER is 42 and generate code that does not use the field to access the value. In that case, the ANSWER field is 41 and the test fails.

Why do you say it is hidden, when this requirement is documented in the documentation of java.lang.Comparable ?

No! It is against SRP. What is isAccountUnderflow responsible for? Checking and throwing exception, or may be not. These are two different concerns to be implemented in separate methods.

It is nice of DZONE that it provides facilities for unior styling katas.

C'mon! The method

assertAccountIsNotUnderflow

will call

isAccountUnderflow

and throw exception if needed! Basic unior stuff!

Using soft, weak or phantom references to create a cache is a poor solution. The cache should retain elements that will be needed in the near future and this weakly correlates with the fact that there is or there is no strong reference to the cached object. As an example the object cached may be cloned by the cache using code and thus no reference to any cached object is retained, still the same value may be soon needed again. When you need to use some caching solution in your application do not implement it yourself. There are ready made opens source and commercial solutions.

Yes, we can predict when they will be collected. When JVM GC algorithm thinks it has to collect them to avoid out of memory situation.

Since those objects are not reacahble the GC can collect them any time it deems and thus they CAN NOT cause out of memory.

Your comment confirms that you are not only writing sloppy but you have no idea about what you write. Better don't!

Example 1: Autoboxing

There are syntax errors in it. One may be of copy paste when creating the article (publiclong without space), but I can not be lenient enough to believe that forgetting the loop variable initialization is also copy paste error.

Let's fix this error and modify the code the following way:

public class Adder { Long sum=0L; public long addIncremental(long l) { sum =sum+l; return sum; } public static void main(String[] args) { Adder adder = new Adder(); long freeMemory = Runtime.getRuntime().freeMemory(); for(long i=0 ;i<100000000;i++) { adder.addIncremental(i); long fm = Runtime.getRuntime().freeMemory(); if( fm < freeMemory ){ freeMemory = fm; System.out.println(""+i+". "+fm); } } }

You will see that after a while the free memory does not decrease. That is because GC starts and reclatims the autoboxed objects that were created. This is a wrong example even if we consider the your definition of memory leak.

Also note that I moved the declaration of the variable sum out of the method 'addIncremental' otherwise the code just does nothing. JIT realizes after a few execution that the return value is ignored and that the method has no side effects at all and converts the method invocation to nooperation.

Please consider the review of the other examples and thrive for quality.

Memory leak is the repetitive allocation of memory without consequential release of it when no longer used, leading to the consumption of ever increasing memory limited by external measures not controlled by the program possibly rendering the execution to a degraded state.

None of the examples in this article meet this definition. The article lists the typical mistakes that *may* lead to memory leak but then fails to present good examples. Some of the examples do not even run.

I recommend the use of JUnit as a source of documentation. Unit test is a living code and if you change the code in a way that requires change in the use of the code your unit tests will get updated or fail. Unit tests are more important than JavaDoc.

I dare say that the most understandable interfaces use names and identifiers that do not need JavaDoc at all.

Java 9

Not any more.

There is also a Flat Earth Society. So what?

Okay. Next time I read the docs and try to be dumb. I will follow you by example. Not reference.

Why can not DZONE fight these nasty virus spreading spams?

This is really a great article. I love it!

I could not find the declaration of channel receivers being maintained in a FIFO. I understand that the go runtime as it is at the moment in the one and only implementation is done that way (after all you referenced the source code of the runtime implentation of channel, and it is easy to follow) but I could not find any mention of that or any guarantee in the language specification.

I just wondering if anyone creates a code that depends on this behaviour could get into trouble later.

I compared two languages of which I know well only one. I don't dare to compare two programming languages I know none of. You can find other authors on DZone who will happily do that.

Not to mention that reflection by default does not allow you to change a final field. To do that you need a reflective object to the Field object to set it 'not-final' and make it usable to "alter" the final field. Brrrr....

"Now is a good time to mention that your objects can, in theory, be modified anyhow, for example using Java Reflection. However, this is considered "cheating" ..."

It is not only cheating. It is something that is totally unreliable. In case of compile time calculated finals the Java compiler may just use the compile time calculated constants. In case of multi-thread code the compiler may opt not to ever copy a processor cache changed value to the main memory or to any other processor cache so the change may not ever be seen by other processors.

Thank you for the kind words. I am afraid you mix C# and Java. It is not a surprise to me assuming you devoted as much attention to read the article as you did using grammar.

It may be worth reading the comments of the same article at the original source at javax0.wordpress.com

ORACLE documentation and also the cited stackoverflow pages clearly describe that the variables hold references. This actually is an implementation detail. When you call a method you pass the reference.

It may be only verbiage, but the difference and the fact that there is a real difference between the two different parameter passing approach will be very important when (if ever) Java will introduce value types.

In case of value types the variable may hold the value itself or a reference to a value type record. This is an implementation detail. However when they are passed to a method the value will be copied (maybe a special new reference with copy on modify flag, which is an implemenation detail again) and not the reference. This is the case now with the primitives. They are simple built-in value types.

If Integer was not immutable you could easily swap too numbers. It would, of course, cause a lot of consequences in Java when 'int' values get autoboxed. This is one reason why the classes autoboxing primitive values are immutable.

The question you should answer first:

the variable

Integer i;

is a number or is a reference to an object that holds a number list? (Any object type could be used, Integer is only an example.)

My answer is that the variable holds a number. This way you actually _can_ implement swap(a,b) so long as long the objects contained in 'a' and in 'b' have the same type and are mutable.

I had the idea for long time that argument captors are good candidate for lambda, and I hope we soon will have a version of Mockito where we have these features built in.

On the other hand using argument captor is usually sign of bad test. When you use argument captor you are eventually reimplementing a partial functionality of the mocked class. The more test data you replace with test code in your tests the more possible bugs you may inject into the testing code.

This article just makes not sense to me. I can not put it into context.

Dear JR,

your idea is great but you should not stop at that point. Why should we have

List<T>

when it is ubiquitous that L is list.

L<T>

is clearer since L should carry no context other than some list. Or perhaps Listener. But T is certainly nothing else than type. Or perhaps throwable. Or thread?

Certainly the examples are not the best. The naming should reflect more the use than the type. The examples I tried to grab from publicly available sources, like Oracle documentation on the web. REALLY. :-)

I do not know what software you use that you name Eclipse, but certainly it has nothing to do with the one I use and named Eclipse. I develop in an enterprise environment, 20 or more projects open, configured working set, application server started from Eclipse, maven integration, ant tasks and all the bells and legacy code you can imagine. I can work continually for days or weeks without restarting it.

You certainly miss it.

I do not say anything wrong about IntelliJ. It is a great software and if it fits your skills and prior experience then you should use that. However your bold and definitive statements, which are not inline with the majority of the experts of our industry makes me suspicious regarding your professionalism and the same of the company you work for.

I would appreciate if you could elaborate how this is done by the JVM.

I would appreciate if you could elaborate how this is done by the JVM.

I would appreciate if you could elaborate how this is done by the JVM.

Thanks for the correction. I was checking a few times in the past the source code of Guava, somehow I missed the the code where it makes a copy of the original collection. Now I looked it up again and I can see the call to `toArray` in the code.

Thanks for the correction. I was checking a few times in the past the source code of Guava, somehow I missed the the code where it makes a copy of the original collection. Now I looked it up again and I can see the call to `toArray` in the code.

Thanks for the correction. I was checking a few times in the past the source code of Guava, somehow I missed the the code where it makes a copy of the original collection. Now I looked it up again and I can see the call to `toArray` in the code.

Copying data can be a performance issue and should be avoided when possible, especially if there is a simpler solution. The methods that create an immutable version of a collection do not copy the original collection. They just provide a proxy to the original collection except the mutating methods.

Copying data can be a performance issue and should be avoided when possible, especially if there is a simpler solution. The methods that create an immutable version of a collection do not copy the original collection. They just provide a proxy to the original collection except the mutating methods.

Copying data can be a performance issue and should be avoided when possible, especially if there is a simpler solution. The methods that create an immutable version of a collection do not copy the original collection. They just provide a proxy to the original collection except the mutating methods.

I did not say what you disagree with. There is some subtle difference between "does not impact application performance" and "not be a factor to seriously consider except edge cases".

Such bent citations does not deliver good for either of us. Casual and careless readers may later remember only the citation and get the false conclusion that I was not professional. Careful readers on the other hand may get to the same conclusion, perhaps related to someone else.

As for the cited article, my personal opinion is that your statements there are biased by your presumed admire towards the commercial product you advocate in your article. Not a surprise by the way, since you work for the company selling the product.

I did not say what you disagree with. There is some subtle difference between "does not impact application performance" and "not be a factor to seriously consider except edge cases".

Such bent citations does not deliver good for either of us. Casual and careless readers may later remember only the citation and get the false conclusion that I was not professional. Careful readers on the other hand may get to the same conclusion, perhaps related to someone else.

As for the cited article, my personal opinion is that your statements there are biased by your presumed admire towards the commercial product you advocate in your article. Not a surprise by the way, since you work for the company selling the product.

I did not say what you disagree with. There is some subtle difference between "does not impact application performance" and "not be a factor to seriously consider except edge cases".

Such bent citations does not deliver good for either of us. Casual and careless readers may later remember only the citation and get the false conclusion that I was not professional. Careful readers on the other hand may get to the same conclusion, perhaps related to someone else.

As for the cited article, my personal opinion is that your statements there are biased by your presumed admire towards the commercial product you advocate in your article. Not a surprise by the way, since you work for the company selling the product.

THIS IS A SPAM

If I neglected the fact that there are not private methods in an interface you would be right. Unfortunately I can not ignore facts.

One could argue that this is a shortage of Java. The fact is that this is not. Private methods have nothing to do in an interface. Private methods are private because outside world has nothing to do with them. That is exactly what the word "private" means. Full stop.

Unit test is outside world.

Interface is the contract the implementation follows when cooperating with outside world.

It is as simple as that.

If you test a private method you do not do unit testing. You are below the radar, under unit test level. Expect to hit some mountains.

If I neglected the fact that there are not private methods in an interface you would be right. Unfortunately I can not ignore facts.

One could argue that this is a shortage of Java. The fact is that this is not. Private methods have nothing to do in an interface. Private methods are private because outside world has nothing to do with them. That is exactly what the word "private" means. Full stop.

Unit test is outside world.

Interface is the contract the implementation follows when cooperating with outside world.

It is as simple as that.

If you test a private method you do not do unit testing. You are below the radar, under unit test level. Expect to hit some mountains.

I agree with the statement to move those private methods to a separate class if their function makes more sense in a separate class. The fact that they are `private` and you still feel that some testing is in place is a smell. However never ever move a method to a separate class just because you want to test it and because you do not want to test private methods. That is the symptom, but the illness.

I also believe that in case there is no need to move the method to its own class, and you still feel need to test it, your feel is not correct. If the method truly belongs to the actual class and is private by its role and nature: why to test it on unit test level? Perhaps you want to introduce a new sub-unit test level? But then again: what is the unit? A class? A package? A method? Whenever I met a need to test private methods it turned out that it was $$anonymous$$ by mistake, or we came to the conclusion that testing it separately does not add value to the test.

Finally, as for the Noun-Verber names my opinion would be totally irrelevant since I am not native English speaker. But I do read such comments with open ears and I am entertained.

Good point, agreed by the author of the article.

Good point, agreed by the author of the article.

Good point, agreed by the author of the article.

Good point, agreed by the author of the article.

Good point, agreed by the author of the article.

Good point, agreed by the author of the article.

Fortunately Java is not only limited by phisical memory, thus it is kind of easy to measure performance with different -Xm* settings for different loads on the same test HW. Cheap memory price makes it cheap to test (for a short time) on a large instance just to see if that is really needed.

I like this article, especially pointing out that larger memory may result bigger GC time gaps, which is not widely known by developers. The usual mantra is "bigger is better". At least this is not allways true for memory.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

I am still interested in your use and reason of thread context class loader in the super constructor call. The documentation of the thread context class loader on the net is sparse and contradicting at times. Your use is actually not inline with what I know about the thread context class loader. Who sets in your use the thread context class loader?

It may well be the case that my knowledge is faulty since I never dared to write a class loader in production code.

Never write a class loader. Possible exceptions may be to learn, experience and practice what class loader is and how it works in Java or if you are developing a framework. This, however, has to be the understanding of your customer, who is financing your effort.

In all other cases invent into research to find an appropriate framework, like OSGi, servlet environment or Spring, JEE.

Having said that I see no explanation or reason why you are using the thread context class loader in your code.

Never write a class loader. Possible exceptions may be to learn, experience and practice what class loader is and how it works in Java or if you are developing a framework. This, however, has to be the understanding of your customer, who is financing your effort.

In all other cases invent into research to find an appropriate framework, like OSGi, servlet environment or Spring, JEE.

Having said that I see no explanation or reason why you are using the thread context class loader in your code.

Generally test automation is worth if the

<ul><li>cost of manual execution of the manual test during the lifetime of the software plus

<li>the cost induced by the different quality resulted by the lack of automated testing for the manually tested feature</ul>

(manual testing cost) is more than the cost of test automation (automated test cost) including the development of the automated tests as well as the cost of the execution.

In my experience automated test cost was always significantly lower than manual testing cost. Even in projects where the first estimated underestimated the cost of manual testing and the automation was started only after a few iteration of manual tests.

I agree with the first two commenters. There is no added value in the extra variable. Even though the pattern can be helpful if

1. the code is more complex than just a simple if/then/else or if the conditional is very complex and not easy to understand just looking at it

2. if there is some extra information in the name you just can not distill from the code

In the example none of the above is the case which makes the example less than perfect and may even direct the oblivious junior into wrong directions.

By 2022 any programmer who have never heard about TDD will easily get job so long as long they can program in COBOL.

You think this is a joke. Actually it is, but as many jokes, you can have a look at it from the other side and take it serious. COBOL can be just any legacy knowledge.

By 2022 any programmer who have never heard about TDD will easily get job so long as long they can program in COBOL.

You think this is a joke. Actually it is, but as many jokes, you can have a look at it from the other side and take it serious. COBOL can be just any legacy knowledge.

The need for the functions I acknowledge and I agree. To have these calls standard I oppose.

I would not support allocation of memory off heap for many reasons. Instead the GC algorithms have to be fine tuned so that the allocation of huge memory does not affect adversely the performance. To embrace the high performance features that you reach now using Unsafe, new run time may provide functions on special objects that are just delivering the higher level feature.

Formulating it the other way, run-time functionality should not expose operation lower than the level of the embracing language. In this sense Java is a high level language.

I say that even though I myself was using instance allocation of Unsafe in some of my hobby projects (djcproxy).

Reading the comments many thoughts came up in my mind. Being a Java developer relatively inexperience in C++ I just learned recently that in C++ every function is "static" by default (they call no "static" method as virtual). If that was such a big problem it was not default by design. Or you can just say that this is also a proof of C++ being bad if you are a heated C++ hater. (Note that I use the word "static" in Java meaning in the above sentences, C++ uses static for different meaning.)

As for mocking: static methods can also be mocked, though this is a bit more difficult and needs mangling with the "function pointers" on a deeper level. PowerMock gives you tools for it. When you mock a method then the mock object is injected into the place of the original class and therefore you use the mocked method instead of the real one. In other words you replace the function reference along with the containing object. In case of static methods the containing object is the class itself. To mock that you need to replace the class. You can do that in the class loader mangling the JVM byte code in the class file. Tools do that for you.

Finally you come to the tricky part when you even want to mock classes that are loaded by the system class loader which you eventually (well, not eventually, but as a matter of fact) can not replace or pass by. But some trick may also help there and finally you can mock even the system class.

https://www.google.com/search?q=how+to+mock+the+system+class

Reading the comments many thoughts came up in my mind. Being a Java developer relatively inexperience in C++ I just learned recently that in C++ every function is "static" by default (they call no "static" method as virtual). If that was such a big problem it was not default by design. Or you can just say that this is also a proof of C++ being bad if you are a heated C++ hater. (Note that I use the word "static" in Java meaning in the above sentences, C++ uses static for different meaning.)

As for mocking: static methods can also be mocked, though this is a bit more difficult and needs mangling with the "function pointers" on a deeper level. PowerMock gives you tools for it. When you mock a method then the mock object is injected into the place of the original class and therefore you use the mocked method instead of the real one. In other words you replace the function reference along with the containing object. In case of static methods the containing object is the class itself. To mock that you need to replace the class. You can do that in the class loader mangling the JVM byte code in the class file. Tools do that for you.

Finally you come to the tricky part when you even want to mock classes that are loaded by the system class loader which you eventually (well, not eventually, but as a matter of fact) can not replace or pass by. But some trick may also help there and finally you can mock even the system class.

https://www.google.com/search?q=how+to+mock+the+system+class