I forgot the codez...

Traditional AOP has aspects, i.e. the classes doing the work, and pointcuts: the places where an aspect squeezes itself into. JEE has some AOP as well, but this is only annotation-bound . So I can define an aspect TimeStuff and an annotation @Timed then all methods or classes need to have an the @Timed annotation added to trigger TimeStuff . This is a bit sad, because it means having to modify code which we might not control, nor want to modify since it's nice and clean. With Spring (or full) AOP, we can define a pointcut which cuts to all the methods/classes which we want (either in configuration, or in the aspect itself with an annotation), and the original code is none the wiser. Lovely! Nothing to see here, nothing to forget here. I want that in JEE. It's not quite so simple, but it's doable. See: https://github.com/softwaremill/softwaremill-common/blob/master/softwaremill-debug/src/main/java/com/softwaremill/common/debug/timing/TimingExtension.java Roughl...

Javascript fatigue (or: why it sucks to learn) Organizing code - by strategy, by component, etc. Configuration building in spring Complete java based config in spring Ungit...?

Oh my. Reflection on generics. That's not always nice. So, here goes. As can be easily found, it is possible to determine the actual type of a generic class at runtime. And in the code we get a number of lists<>... and we want to sort them by class hierarchy (so, String extends Object, and thus List<String> should go after List<Object>) Our compare method then needs to look like this: compare( List left, List right) { Type type = left.getClass().getGenericSuperclass() if(type instanceof ParameterizedType) {// it is a generic   ParameterizedType pType = (ParameterizedType) type;   Type[] actualTypes = pType.getActualTypeArguments();   // and then we have an array, which in this case should be String.class and Object.class, which we can then compare   } ... } This is nice, but spring kinda has the problem that those objects *might* be more then they are... they might be AOP'd! In that case, we do not get the actual objects, but proxie...

So far I have a number of things which I don't like. Abstract classes are evil.It indicates base classes, but inheritance should never be used for code reuse. Use interfaces, factories, strategies for such stuff. Moreover, they give code that cannot be tested (easily) final should not be used, except to designate constant statics. Nothing more, as it is superfluous take-space-on-my-screen crap Builders which cannot be extended. Ideally, a builder should be separate from the value object, and the value object should be extensible. Hence, private constructors are a no-go for the value-object. The disadvantage of using builders is that it is hard to extend them properly, as they are usually not templated and thus do not use a proper signature. E.g. class OldBuilder {     int a;     OldBuilder withInt(int a )   {         this.a=a;         return this;     }     Value...

For testing, I wanted the option to have the applicaitoncontext be modifyable. Normally, I'd use the Spring4UnitRunner for testcases in combination with a @ConfigurationContext(...) However, in this case,  I wanted to modify the applicationcontext, or more precisely, I wanted to override a property, with a different value for each test. (overriding the properties for the entire test with a property-file should be easy, using @TestPropertySource) Injecting the applicationcontext didn't work, as we receive a GenericApplicationContext, which cannot be refreshed. So, we create our own applicationcontext, update the properties, and refresh the context:     private ApplicationContext createApplicationContextWithProperties(String applicationContextXmlLocation, Map<String, Object> propertiesMap) {         ClassPathXmlApplicationContext overridenApplicationContext = new ClassPathXmlApplicationContext(applicationContextXmlLoca...

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...

So, we needed to do some UTF-8 code matchings. And someone grabbed the proper UTF-8 document and was talking code points. And then you notice that java 7 has no nice way to determine code points... *really*, it's only been 7 versions and it's still not well. At least, a snippet to show the proper code point:     public static String printCharacters(final String s) {         for (final int codepoint : codePoints(s)) {             // we need Character.toChars and new String since we cannot call back to the specific character from the string from the iterator.              System.out.println(new String(Character.toChars(codepoint)) + "is of type: "+ typeToString(Character.getType(codepoint));         }     }     /** java 7 doesn't have a nice support for determining code points. Java 8 does... */     publ...