Friday June 20, 2008 First Indicators of Overengineering in Your Project
- You start to use terms like "potentially", "in future" or "scalable".
- You spend more time thinking of "encapsulation", "abstraction" and "decoupling", than the actual problem.
- You believe, that the with amount of frameworks, libraries, and languages (better polyglot projects), the qualitity of the software will improve.
- You are able to replace every single concept, class and layer - but this feature actually cannot be derived from the client's requirements.
- Just looking at the code - you do not understand what happens - you need addtional tools, products and consultants :-) to understand it.
- You hate monolithic structures - so everything is configurable, replacable - of course at runtime. If it becomes too complex, go to point 5.
- You start to implement a generator to tackle the complexity.
- Your configuration file is getting slightly bigger, than your code.
- Your interface is so fluent, that only domain experts understand the code :-)
The problem with patterns, best practices and idioms is the overuse of a single principle. Regardless what you are considering: overuse of DRY can lead to "fat" layers and classes, overuse of Separation Of Concerns to many fine grained units, overuse of modularization to jar, plugin or just governance hell. Common sense and the balance between concepts and idioms are the solution- but it's hard to find in real world :-).
Gesendet von admin [Java / JEE / Architecture] ( June 20, 2008 10:57 AM ) Permalink | Kommentare [5]
Sunday May 18, 2008 Generic EJB 3 CRUD, DTOs and Lost Updates with Optimistic Locks and JPA
I got some feedback with concerns about a generic CRUD interface which I described in this post, as well as checked in into p4j5. The basic idea was the direct exposure of persistent JPA-entities to a remote client - without the use of DTOs. This approach works really well for simple use cases like e.g. master data management. However it isn't a silver bullet for more complex use cases. In general, the @Version in an JPA-entity is going to change in case the persistent state (the attributes) is changed. However the relations do not belong to this set. So, even in case you are using JPA with optimistic concurrency, changes to relations do not cause the @Version attribute to be increased / changed. In case the client changes a relation (e.g. deletes a link between the master 1----n> client), the @Version of the master entity will not be increased - concurrent access could cause lost updates in this case.
Beyond this "logical" problem - before you would like to start using detached entities over network boundaries, you should think about the following challenges:
- Lazy loading - you have to preload the object graph, which is needed at the client. You could use e.g. "FETCH JOINS" for this purpose, or just invoking the methods
- Lazy loading and AOP - some providers weave proprietary extension into the persistent entities. In this case it could be necessary to deploy additional libraries to the client as well.
- The client will need at least the JPA-annotations in the classpath
- In case you are sending a subset of the object graph to the client - automatic merge will be not always possible (what happens, in case the client deletes some childs?)
I will discuss this issue in more detail during the upcoming talk at JUG HH (19.05.2008) as well.
Gesendet von admin [Java / JEE / Architecture] ( May 18, 2008 11:54 AM ) Permalink | Kommentare [1]
Sunday April 06, 2008 Running Netbeans 6.1 on jdk 1.6.0_u10 beta (Consumer "JDK")
I just had some trouble with JAXB and had to upgrade the JDK (JAXB 2.1 comes with > JDK 1.6u4). I went a little bit further and installed the JDK 1.6.0_u10 beta, also known as the "consumer JRE / JDK". I just launched Netbeans 6.1 on it and:
- Netbeans 6.1 launches in 5 seconds (with several Java EE 5 projects). It feels faster, than on jdk 1.6u4
- It seems like the font rendering was improved - it looks clearer.
- ...and JAXB 2.1 just works :-).
Monday February 18, 2008 Superb compilation of JVM parameters - from 1.3.1 to 1.6
From JDK 1.3.1 to 1.6. All major (about one hundred) JVM settings with explanation can be found here. Thanks to Michael Bien for the hint. Gesendet von admin [Java / JEE / Architecture] ( February 18, 2008 05:13 PM ) Permalink | Kommentare [0]
Thursday February 14, 2008 The Mystery of the Maximal -Xmx Settings, Ergonomics and Tuning
From time to time, especially developers working with windows, run into problems with JVMs maximum heap. Although in theory the maximum heap on 32bit OS should be 4 GB, it is actually on windows less than a half of the theoretical setting. The actual number is around 1.4GB, it is hard to reach 1.5GB. I found several resources, which point to the causes of this behavior. This older entry, explains the reasons (windows systems reserve some memory for "private use", which is no more available for applications). It contains some links to MSDN as well. This bug report, explains the behavior, as a problem in the JDK's dll. It mentions also, that other JVMs (like JRockit) are able to handle slightly more maximum heap. However on my Vista 32bit machine (3GB RAM), the highest heap I was able to set up was 1626m (it isn't able to start with 1628m...sometimes with 1629m it varies,) with Sun's JVM. I tested it with the SwingSet, the Swing demo application: java -Xmx1620m -jar SwingSet2.jar
If you are interested in GC/JVM tuning, this whitepaper is a good resource. It explains the default settings, tuning ideas and ergonomics in great detail.
Saturday February 09, 2008 JSF Matrix - most popular JSF/AJAX frameworks condensed
This matrix is really useful. It compares many (18) different JSF frameworks. Most of them come with a link to demos, documentation and license information. [Thanks to aquarium for this hint]Gesendet von admin [Java / JEE / Architecture] ( February 09, 2008 09:26 PM ) Permalink | Kommentare [1]
Monday February 04, 2008 Hacking Java EE 5 is good for the environment!
GreenFire.dev.java.net is an opensource project which goal is to manage heating systems in convenient and efficient way. It is acually a bunch of ejb-jars (created with Netbeans 5.5, 5.5.1, and 6.0) which are
deployed as an EAR to Glassfish v2. GreenFire abstracts early from the proprietary vendor extensions - the whole management is heating system independent. GreenFire consists of the following building blocks:
Diagram created with Netbeans UML plugin.
GreenFire wakes up every 5 minutes (the archiver, actually the heartbeat - implemented by a timer bean) completes the following tasks:
- It gathers the data (heating + configuration, weather forecast) and passes it to the „brain“
- The brain is asked what to do (heating on/off, etc.)
- The decision is passed to the integration layer and executed
- All the data is stored in the Derby DB and can be used in reports.
The „brain“ dowloads a script from an URL (Glassfish as well). It has access to all the data (JPA entities) and can decide what to do.
The data in the JavaDB is used for reports and monitoring independently (it stores every 5 minutes all the data since about 2 years – and performs still very well -> no problems).
The Reporting-UI is accessing JavaDB to read the decisions and interesting data like external temperature, weather etc. – not directly the heating system (decoupling – the serial port seems not to be thread safe).
However the current data is broadcasted every five minutes using JMS internally (inside the application server) the shoal.dev.java.net / fishfarm.dev.java.net framework as well and can be accessed with every device (currently multi-media system, PCs, working on Java ME) over W-LAN. Even the following widget is updated by the JMS/Shoal heartbeat:
The rules for the heating should be changed without redeploying and especially recompiling the application.
For the implementation the Fluid Kernel, Persistent Anemic Objects, Lookup Utility etc.. pattern were used (see: http://p4j5.dev.java.net).
At the creation time Groovy was chosen (JDK 1.5 time, no JSR-223) for the implementation of the rules. In the next release JavaScript is going to be used (is already shipped with Java 6, faster and totally sufficient for greenfire‘s purposes). GreenFire is running since 2 years in my house - the energy saving is considerable (over 30%).
Friday January 25, 2008 I posted already about Fluent Interfaces, EJB 3 and JPA. With Java EE 5 it is absolutely possible to build applications, which look DSL-like with JPA 1 and EJB 3:
training.login("adam","bien").
running().
today().
averagePulse(135).
comment("ok").
duration(0,65,1).
maxPulse(165).
distance(12).
wasRace().
sunnyWeather().
add();
You can use "known" patterns and approaches for this purpose like Builders and static inner classes. In the sample above a Stateful Session Bean with Extended PersistenceContext and a bunch of JPA-Entities is used. However I was often asked about the integration of "such" code into a real world applications - so I build a complete sample and integrated the JPA entites using Model View Presenter (actually Passive View and Supervising Controller) to a JSF application. I would like to build a Swing/JavaFX frontend as well.
It is an application which manages your training data (in case you are a runner or biker). The main Use Cases are the computation of the average pulse, speed and the corelation between both etc. (and everything else which is interesting for a Java developer). This application was built with Netbeans 6.0 out-of the-box and it runs on Glassfish V2, Apache Web Server, Java DB and 64bit Linux. The URL is http://www.adam-bien.com/tdb/. The whole source code is available in http://p4j5.dev.java.net (already 35 registered observers and 2 committers)- the project name (EAR-project) is RunAndBikeApplication. I will disect this application in the upcoming editions of JavaSpektrum in greater detail as well.
I'm the first registered user - and use it already. If you like use it and improve it. I would like to provide some top-score ranking system as well. However, I would like to remain under the first three places, and will fine tune the results :-).
I introduced the application at yesterdays NUG/JUG meeting in Munich (really great event) and got already some requests for enhancements (like covering swimming for triathlon). One particant ran marathon and 2:58 (it is comparable with lightening speed :-)) and will use it as well (he will get a VIP status). A committer "dynamic" contributed already some code ...and ran the marathon in 3:17 (unreachable too).
The NUG meeting was great. I hacked and deployed a small application with Stateless Session Bean, Web Services, interceptors, JPA entity with inheritance, relations etc. There were many questions and many t-shirts. Because of lack of time (it was really open-ended - I went home at 12PM :-)) - there will be a second part: I will talk about the Presentation Tier, Java FX, GWT, JSF, or other cool stuff in summer. The munich's NUG/JUG community is really great, I enjoyed the private talks afterwards. Special thanks to Anton Epple (the NUG/JUG) leader for the great organization, and Sun Microsystems - for the T-Shirts, Java Spektrum for the free magazines...
Btw. I will cover this example during the Developer Days (Entwickler Tage) in Frankfurt (27.02 - 29.02.2008) as well.
Wednesday January 23, 2008 I even introduced "officially" the GreenFire Heating Control, which is based on Java EE 5, Glassfish v2, JavaDB, Groovy, Java FX and ...the SunSPOTS. The slides (with architecture explained, use cases, and functionality ) are available from http://greenfire.dev.java.net for download. The source is partially available already. I have to clean up the remaining modules and will opensource them during next weeks. The session was very well attended (room too small), I never got so many questions, during/after my talk :-)... A part of GreenFire functionality (the small widget) is already installed on this blog (it should be on the right, bottom corner, it depends on the resolution).
Attendees ask me about the free Java EE 5, Java User Group / Netbeans User Group event in Munich (tomorrow), you will find more information here.
Sunday January 13, 2008 Fixing JConsole For Vista, or Vista for JConsole [Local Processes Are Not Listed]
Out-of-the-box it is not possible to connect to a local Java process from the JConsole using Windows Vista. The local process box just remains empty... The cause is Vista's security model. In default case every Java process creates a file in the folder: C:\Users\[LOGIN_NAME]\AppData\Local\Temp\hsperfdata_[LOGIN_NAME], in my case e.g.: C:\Users\adam\AppData\Local\Temp\hsperfdata_adam. The name of the file is the PID. For some strange reasons this directory is write-protected - it is not possible to create neither files nor folders in the hsperfdata_[LOGIN_NAME] directory. It is even not possible to change the write access, even not as an administrator (you can understand now, how secure Vista really is :-)). However if you delete this directory, and create a new one with the same name - then it works perfectly....Gesendet von admin [Java / JEE / Architecture] ( January 13, 2008 03:14 PM ) Permalink | Kommentare [0]
