Too (many?) Java technologies. Where to start?

[maddox]

---

bro, you don't have to know J2EE to learn Java EE 5. naay mga documentation ang Sun nga introductory gyud.

here: http://java.sun.com/javaee/5/docs/tutorial/doc/

here are some key features sa ila differences:
Java EE 5:
- reduced use of deployment descriptors
- use of annotations instead of deployment descriptors
- Entities are separated from the EJBs
- Entity is included under the persistence layer
- Entities are POJOs (Plain Old Java Objects) w/c represents database tables
- Entities are mapped to the database simply using annotations
- User authorization and authentication are defined using annotations
- JPA (Java Persistence API)!!!!!!!!!!!!!!!!!!

Basically, ang enhancement sa Java EE 5 kay ang pag-gamit sa annotations. Na-reduce gyud pay-ayo ang paggamit ug XML para sa deployment descriptors. Sauna (J2EE) halos taga-lihok gabuhat kay ug XML. Karon mas sayun na lang.

ex. (naa kay entity nga Customer)

@Entity
@Table(name="customer")
@NamedQuery(name="Customer.findByName", query="SELECT c FROM Customer c " +
"WHERE c.firstName = :firstName AND c.lastName = :lastName")
public class Customer implements Serializable {

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Integer id;

@Column(name="first_name", nullable=false)
private String firstName;

@Column(name="last_name", nullable=false)
private String lastName;

@OneToOne(cascade={CascadeType.ALL})
@JoinColumn(name="add_id")
private Address address;

<accessors here>...

}


Ang kanang mga statements nga naay "@" mao nay mga annotations. Gikan na sa J2SE. Maoy gipagamit nila karon para mas sayon na lang. Dili na ka kinahanglan ug deployment descriptors - although you can still use one if needed or depende sa imo specs.

Ang kani nga entity nga Customer ga-represent lang gyud ni sa imo table nga CUSTOMER sa database. wala kay business logic dapat ibutang diri kung dili sa imo na Session Beans.

If you notice naay property ang Customer nga "id". Mao ni ang ID column mismo sa imo database nga naka-auto-increment (GenerationType.AUTO).

If you notice Customer has a property Address. The annotation maps it in such a way that it has a one-to-one relationship with the ADDRESS table. Automatic na sad ni.

So to use this entity:


/** very simple Session Bean - not ideal to use; for sample purpose lang */
@Stateless
public class CustomerBean implements CustomerRemote {

@PersistenceContext
private EntityManager em;

private Customer customer;
private Address address;

public void newCustomer(String firstName, String lastName, Address address) {
customer = new Customer();
customer.setFirstName(firstName);
customer.setLastName(lastName);
customer.setAddress(address);
em.persist(customer);
}

public void deleteCustomer(Customer customer) {
em.remove(customer.getId);
}

}

That's it! Executing the methods above would insert and delete a Customer object to your database.

"em.persist(customer)" - inserts a row to your CUSTOMER table with an unique ID. This also inserts a row in your ADDRESS table in the database with a unique ID mapped to its corresponding Customer.
"em.remove(customer)" - deletes a row in the CUSTOMER table that has the ID = customer.getId


These are just one of the very basic features available in Java EE 5. Sauna, with J2EE doing this will take much longer because wala pay gamit nga annotations and you have to make deployment descriptors in XML.

Hope this helps.

[tokidoki]

thanks again bai. I read about annotations baya. Very useful. Samok gyud na bai oi ang mga xml sa mga servlets. Halos kada lihok naai ibutang sa xml otherwise di modagan. ahak nalang ni.

[tokidoki]

karon ra nako gibasa tarong ang last part sa imo post bai. As I was reading it, I was able to relate it with modern PHP MVC frameworls. It's all familiar to me na diay. This really takes a load off the development in earlier j2ee apps.

[psyd_1]

Ah, my first production project was done on JSF. My first exposure to java web programming. It wasn't much but at least it gave me a taste. However, the drawback in JSF is that there's no functionality that handles GET methods. POST tanan. So meaning there's no JSF function that let's you handle database queries that can be bookmarked. So old school ka by then. I think this technology is more focused on user interface security rather than data retrieval. That's why it was ideal for my project considering it was an "INPUT ONLY" webpage that records entries.

i think JSF can do GET methods..but im not sure, i havent tried JSF man pud..try using Spring..labina ang mvc niya na featur..di naka mag problema sa imu view layer since you can bind everything(kadto html controls) na nagkupot sa imu data's, sample name,address,age na mga input boxes directly into your defined pojos..nice sad ang spring since mu support sad sya ug lain an frameworks like struts,hibernate,jsf,ug uban pang mga techs..nice ni na combo spring+hibernate

[maddox]

nice sad ang spring since mu support sad sya ug lain an frameworks like struts,hibernate,jsf,ug uban pang mga techs..nice ni na combo spring+hibernate

Hibernate is not a framework. It's a persistence engine.

[tokidoki]

kindly elaborate on that bai. n00bs in the house.

ang naka-minus gyud sa java bai kai di masabtan iya API. Naanad naman gud ko sa PHP nga nindot pagka-organize iya docs. Naai intro then language basics then a complete categorical list of functions.

Functions mismo nindot pagka document. Parameters and an example how to use the function. Ang format sa Java ambot lang. Yagaw kaayo para nako.

[maddox]

It's the "engine" that the Java Persistence API (JPA) will use to maintain an object's persistence. I hope I can make this simpler by citing what can't be done w/out a persistence engine.

You can't persist an object to your database without a persistence engine like Hibernate or Toplink.

With this code:

customer.setFirstName(firstName);
customer.setLastName(lastName);

enitityManager.persist(customer);


Without a persistence engine, this code won't work. EnityManager is an interface of the JPA w/c needs a persistence engine to persist your object to your database.

Am I making sense? Sorry bro, explaining things thoroughly here will require me to write a few codes. Too bad istorya doesn't have tags for codes. Anyway, there's a link from my post above to Sun's official Java EE 5 introductory lessons. That would help a lot. Thanks.

[maddox]

kindly elaborate on that bai. n00bs in the house.

ang naka-minus gyud sa java bai kai di masabtan iya API. Naanad naman gud ko sa PHP nga nindot pagka-organize iya docs. Naai intro then language basics then a complete categorical list of functions.

Functions mismo nindot pagka document. Parameters and an example how to use the function. Ang format sa Java ambot lang. Yagaw kaayo para nako.

Bro, I guess you're just saying that coz na-anad ka sa PHP. PHP is also the language I first used in developing. Learning Java was kind of challenging. I didn't even know what an API is before and why are there so many and how do I know which one to use?

But later on I learned that the Java API is very very powerful. You can do a whole lot of things if you know what to use.

If we were to compare PHP and Java in that sense, it would be like, PHP has predefined functions right? And there's a lot. And they're very very good functions. Try to group them together by characteristic and purpose. For example sorting arrays in PHP. You have sort, rsort, ksort, krsort, asort, etc... functions right?

If you group them in one API for example - "a PHP Sort API"... then we could have an interface or an abstract class Sort that contains methods as template for the other sorting classes. So for example by design ksort will no longer be a function but a class that will have the template methods and more. Therefore it will become richer and capable of more things to do and could accept more parameters and could function well under different conditions.

But of course the ksort function is sufficient in PHP since it's a loosely typed language.

Java is designed to survive more complex requirements and the boys from Sun designed it to have a lot of libraries for different tasks so programmers won't have to "reinvent the wheel". Thus the APIs.

[tokidoki]

nice explanation bai. i can tell we have the same mindset. heheh... at least you got as far as being able to relate it to a language you started with - I haven't got that for yet. hehehe...

But mao gyapon. the documentation looks like hell to me due to the weird formatting like object parameters and such. libog pako ana.

For the comsci peeps, you may want to read around some articles and whitepapers about criticisms in languages. Java is not immune to these "logical gods" of the computer.

The latest I read about was about Generics. source here: http://weblogs.java.net/blog/arnold/..._consid_1.html

So, I don't know how to ease into this gently. So I'll just spit it out.

Generics are a mistake.

This is not a problem based on technical disagreements. It's a fundamental language design problem.

Any feature added to any system has to pass a basic test: If it adds complexity, is the benefit worth the cost? The more obscure or minor the benefit, the less complexity its worth. Sometimes this is referred to with the name "complexity budget". A design should have a complexity budget to keep its overall complexity under control.

[...]

Which brings up the problem that I always cite for C++: I call it the "Nth order exception to the exception rule." It sounds like this: "You can do x, except in case y, unless y does z, in which case you can if ..."

Humans can't track this stuff. They are always losing which exception to what other exception applies (or doesn't) in any given case.

[...]

Without [an explicit complexity] budget, it feels like the JSR process ran far ahead, without a step back to ask “Is this feature really necessary”. It seemed to just be understood that it was necessary.

It was understood wrong.

I used generics on my code on the last release I made before I resigned from my company. I make it a habit to add things I recently learned to my code to either improve it or fix it. That way, I have hands on knowledge of the language. Generics aren't bad but the guy who commented does have sense to his comment.

There are, in fact, far superior languages than java. It's just that a large number of corporations utilize Sun technologies that it's hard to NOT look in the direction of java development. Oh, well, ana gyud na basta industry leader ka.

[maddox]

True. Java has a lot of weakness. And so does the other languages. That's the thing with programming, nothing's perfect. Specially one's codes. That's why people from Sun, Microsoft, and others are working hard to spot those weaknesses and find solutions for them. And for us programmers, we need to be aware of these things to catch up.

One specialist also said that we are in a field of an 18-month life. We have to read read read and read some more. Because after 18 months, whatever we learn now will be useless.

Tough huh.