I forgot the codez...

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...

Sometimes we want to use both spring-ws and spring-mvc in one application. However, these are two different stacks. To use them combined is a bit of a hassle, and... lest I forget, this post. The following needs to be set in the applicationcontext: <!-- To nicely support webservices from httprequests, we use the WebServiceMessageReceiverHandlerAdapter (which needs a messagefactory) --> <!-- Because we declare this, the dispatcherservlet automatically uses it... instead of the normal mvc adapter! --> <!-- To ensure that the normal mvc adapter is also loaded, we need to define it (the SimpleControllerHandlerAdapter) as well. --> <!-- Requires a message factory so we declare one --> <bean class="org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter">   <property name="messageFactory" ref="messageFactory" /> </bean> <bean id="messageFactory" class="org.springframework.ws....