Kenneth Gustafsson

Here is the way I recommend:

Java for Dummies, 2nd edition

Object oriented design in Java

Database programming in Java

Create applications!

Choose some project of moderate complexity on Sourceforge, study its source code until you understand how it's constructed. Help out correcting bugs and implementing new features

Repeat the step above over and over

Read Effective Java and try to correct mistakes you've made in your own applications which are pointed out in the book

Read a book about developing JSP applications

Create web applications, study existing ones from Sourceforge, participate in the development of existing ones.

Read up on Wicket and create some small application (like a photo storage application) using it. Convert the application to other frameworks, like Spring MVC, JSF and Tapestry.

Now you know which framework you like, use it! Add some bling-bling to your basic application using JavaScript. Do it manually first and try it in different web browsers. Then try it using JavaScript librarires like echo, prototype and jquery.

If you've done all the above picking up some kind of report tool if you need it will be a breeze. That's why I haven't included Crystal Reports. If you just want some diagrams and stuff there are easy libraries available.

It will take 18 months as a bare minimum. And you won't be rightfully calling yourself an expert for the next 15 years (but you will get by). :-)

If you find something especially hard, take a course on it. The first two items should be doable using only books. It takes time to learn this stuff, lots and lots of time, not many people have the necessary interest.
[ July 24, 2008: Message edited by: Kent Larsson ]

Thanks for answering me even though it was a loaded question! :-) Personally I lean mostly towards Wicket.

On a general basis, and as a follow up question, why would you use a framework instead of a plain Servlet+JSP architecture for anything but the simplest applications?

Thank you! I'll be sure to read it. Just a quick question for you or someone else who is knowledgeable.

If there were lots custom ways needed to handle forms and other things and you wanted to reuse code to minimize bugs and development effort. Would you go for a JSP solution then, or would you use JSF, or maybe Wicket?
[ July 24, 2008: Message edited by: Kent Larsson ]

Ah, thanks for informing me! I was more thinking about using only the XML structure or the normal JSP structure.

Still the issue is code reuse and I'm wondering how hard it is for me to write my own tags/components. It's great that there are third party libraries with lots of tags, but I want to create some of my own.

For example, if I want to create a special kind of input text field which has some validation information as well:

<myinputtextfield id="textfield" param="name" desc="Input name:" " longdesc="Write your first name followed by your last name" mustmatchpattern="([a-z]{2,10}+\s){2}" onvalidationfailure="You must input your first name followed by your last name"/>

It will output a text field together with some JavaScript for validation as well as visual bling-bling. I might base it on jQuery, echo or something else.

Would that be possible? Would it be easy?

Also,the saloon is great! :-) But, it's not the best place for game development discussions at the moment. As a complement to the Saloon i urge you to join http://www.javagaming.org/ which has much more information on game development in general and with Java.
[ August 04, 2008: Message edited by: Kenneth Gustafsson ]

Yes. Well I think that you handle it mostly the same way as you do for recursion in math. By dividing it into the possible ways it may branch and trying out each of those cases. By proving that the parts are doing what they are supposed to you prove that the whole algorithm is sound. I think that's the strategy. :-)

Hi,

I'm in the beginning of a project, no code has yet to be written. I want to reuse as much code as possible so I thought I'd write custom components which I then just use.

The components I'm thinking about are for various things. It could be a component which shows a static message if the user hasn't got JavaScript enabled, and a dynamically updated one if it's available. Other components could help with easy form creation and validation. Yet other components could handle nice tabular lists which you're able to update and re-sort using JavaScript.

Is it easy and flexible to do this using JSP or JSTL? And if it's easy and flexible using both ways, do you have any recommendation regarding if I should choose JSP or JSTL?

As a last note. I need to create custom components myself. :-) I can't imagine that all the custom things we'll use are available in any library. However I will use the help of jQuery to create the dynamic things.

I would ask in a d-link support forum, or check my routers manual. You need to forward all the ports your application is listening to. Also make sure that it isn't your windows(or other software) firewall which is blocking the ports.
[ August 04, 2008: Message edited by: Kenneth Gustafsson ]

There are lots of situations where you can't really get to grips with and have an overview of the entire state space when debugging. I would even say that it's true for most situations.If you're creating a text editor you can't simulate all possible input variants. And if you're creating a web browser you can't simulate all web page structures, and so on.

Debugging states of an min-max algorithm is no different from any other problem. You might be baffled by the fact that you're creating huge trees?

If your algorithm is recursive (which min-max usually is, but it may be implemented differently too) you might run out of stack space. Let it tackle a problem which you think is representative for what you want to do, if it fails due to stack space memory problems you need to deal with it. If you can't optimize it any further then you might want to change algorithm. Personally I think no one should use min-max, they should use alpha beta pruning.

Apart from that you need to do what you normally do. Write up a case analysis of the most important different structures/situations your code may face. Simulate and test each case separately, does it perform as expected?

Also throw at it lots of examples where you know the correct answer. As min-max is guaranteed to produce the best result as long as you have enough memory throw some semi-finished tic-tac-toe games at it. Let it have one, two, three and maybe four moves until it wins (or until you win, depending on what you want to test). That will keep the number of states in the tree low, you will have a complete overview of the state tree and you will know the expected output.

[ July 15, 2008: Message edited by: Kent Larsson ]
[ August 04, 2008: Message edited by: Kenneth Gustafsson ]

I'm in a similar situation. First on my own TODO list is to try out Wicket, as I wrote in this thread. It might be worth checking out for you as well.

Hi,

I'm attracted to Wicket for Java web development as it looks simple while supposedly letting me as a developer create anything I like. Why the italics? I just haven't had time to try it out myself yet, I'll hopefully get some free time to play with it the coming weekend.

It would be great if this could spawn into an discussion about the strong and weak points of Wicket. Of course your opinion is of most interest if you've actually tried Wicket, but even if you haven't I'd still like to hear what you think.

Some questions to get us started:

Have you used Wicket? Which version? On a commercial project, or for recreation programming? Will you continue to use Wicket?

Which other technologies (JSP,JSF,Spring MVC,Tapestry etc) have you used?

How does Wicket compare to other technologies you've used?

What do you think about Wicket? What do you base your thoughts on?

Let me start:
I have only really used JSP+Servlets in an MVC model. Currently I'm learning some JSF as I need to know enough to do some changes to a project. I'm not very positive about JSF and find it quite complicated. Wicket looks much easier and I like the separation where you write valid XHTML which you later "plug in" your components using wicket:id="blah". I can't wait to try it out at home.

Some more Wicket information:

http://wicket.apache.org/introduction.html

http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/

http://www.manning.com/dashorst/meap_wicketch1.pdf

[ July 15, 2008: Message edited by: Kent Larsson ]

I really liked "EJB in Action". After that you have the specs and Internet, I doubt you need more than one book.

Avoid Mastering EJB. I recommend EJB3 in Action. Good luck.

Where I work we have decided to follow a certain way of designing. It would be interesting to discuss it with other people. And it might help someone facing the challenge themselfs some help.

What we think is nice about it:

It makes the business code used by the session beans easily testable outside container using for example JUnit.

We're able to change our integration layer into something other than JPA by just writing a new class and changing one line.

Enteties which have FetchType.LAZY for certain variables may still be fetched outside our persistence context (like for example servlets) by using the get method of our SLSB manager. Using entityInstance.someGetterForALazyAttribute() would render an exception from a servlet.

Less nice things:

Lots of places to write the same thing.

More or less procedural way of working with enteties (no logic in the enteties and getters/setters are never used directly except from our business logic implementation POJO class).

----------------------------------- SLSB Interface // The business interface of the cheese handling class. public interface CheeseManager { public void addCheese(Cheese cheeseToAdd); public List<Cheese> getAllCheese(); public String getName(Cheese cheese); } ----------------------------------- SLSB Implementation // The EJB which implements the business interface, only contains logic specific to // EJB like timer service stuff and EJB life cycle methods. @Stateless public class CheeseManagerEJB implements CheeseManager { @PersistenceContext(unitName = "CheesePu") private EntityManager em; private CheeseManagerIntegration integration; private CheeseManager businessLogic; @PostConstruct public void init() { // Later on we might use a factory here instead so it's // easy for us to change integration layer implementation // from JPA into something else. Like straight JDBC, web // services or file base persistence. integration = new CheeseManagerIntegrationJPA(em); // We have our business logic in a POJO instead of directly // here in the EJB. This makes for easy testing using the // normal JUnit and JMock frameworks. businessLogic = new CheeseManagerSRV(integration); } public void addCheese(Cheese cheeseToAdd) { businessLogic.addCheese(cheeseToAdd); } public List<Cheese> getAllCheese() { return businessLogic.getAllCheese(); } public String getName(Cheese cheese) { return businessLogic.getName(cheese); } } ----------------------------------- Business logic POJO implementation // A POJO class containing our business logic. It is used by our EJB class and if we // some day wanted to stop using EJB it could be created directly. The current one // contains no non-forwarded business logic, but we might want to add a neural // network (ie business logic which preferably should not be forwarded to the // integration layer) here to train it so it can pick out good cheese. public class CheeseManagerSRV implements CheeseManager { private CheeseManagerIntegration integration; CheeseManager(CheeseManagerIntegration integration) { this.integration = integration; } public void addCheese(Cheese cheeseToAdd) { integration.addCheese(cheeseToAdd); } public List<Cheese> getAllCheese() { return integration.getAllCheese(); } public String getName(Cheese cheese) { // Retrieved by JPA as we're inside a persistence // session and using FetchType.LAZY return cheese.getName(); } } ----------------------------------- Integration layer interface // Similar to the business interface but seldom the same public interface CheeseManagerIntegration { public void addCheese(Cheese cheeseToAdd); public List<Cheese> getAllCheese(); } ----------------------------------- Integration layer implementation // This is the concrete implementation of the necessary // persistence methods using JPA in our case. public interface CheeseManagerIntegrationJPA implements CheeseManagerIntegration { EntityManager em; CheeseManagerIntegrationJPA(EntityManager em) { this.em = em; } public void addCheese(Cheese cheeseToAdd) { em.persist(cheeseToAdd); } public List<Cheese> getAllCheese() { Query query = em.createQuery("SELECT c FROM Cheese AS c"); List<Cheese> allCheese = query.getResultList(); return allCheese; } } ----------------------------------- Cheese @Entity @Table(name = "Cheese") public class Cheese implements Serializable { protected static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "id") protected int id; protected String name; public Cheese(String name) { this.name = name; } @Column(name="name") @Basic(fetch = FetchType.LAZY) public String getName() { return name; } public String setName(String name) { this.name = name; } }

All constructive critisism is welcome!
[ June 04, 2008: Message edited by: Kent Larsson ]

Thanks for your answer Mike and Rodrigo! That's the second time today both of you help me.

At the moment we try to work around the problem and stay with Hibernate. But we're trying to stick to pure JPA so that we can escape from Hibernate if we decide on it later on.

Worth mentioning is that they don't plan to correct this bug in Hibernate and say that they pass the Sun tests. They were not even friendly in their response to the user reporting the problem. (See the bug report on Hibernates bug tracking system.)

We're using SLSB's for our transactions and wanted to use the getters on the entities for presentation of information. As this presentation is done outside of a persistence session we're not allowed to get the LAZY data inside our POJO entity getter method.

If we wanted to use the getter method of our entity POJO we see two options.

The first is that it would have to call an SLSB and return the result through it. It means tying our POJO enteties to SLSB's by injecting the relevant SLSB in the POJO.

Our second option is to open a persistent context and do our database information retrieval from there. It means having database related code inside our entity POJO's.

What we do now is having no logic at all in our enteties. And doing all operations through SLSB's on them. Which means that instead of doing
userGroups = ourNiceEntity.getUserGroups()
we do
userGroups = ourNiceEntetiesManagerSLSB.getUserGroups(ourNiceEntity)
and the SLSB in turn does
return ourNiceEntity.getUserGroups()
and we get the result.