Sun has announced the simultaneous release of preview versions of the JEE 5 SDK and NetBeans Enterprise Pack 5.5.

The JEE 5 SDK will form the basis of Sun's Application Server, version 9. The JEE 5 SDK is a frozen version of the Glassfish application server, and contains support for underlying technologies such as JSF 1.2, JAX-WS 2.0, JAXB 2.0, as well as adding architectural blueprints and code samples.

NetBeans 5.5 supports JEE5 and contains previews of the UML editor migrated from Sun's Java Studio Enterprise, as well as SOA tool capabilities. It includes the JEE 5 SDK, and features from Sun's Java Studio Creator are expected to migrate into NetBeans 5.5 in late 2006. NetBeans 5.5 will also run properly on the Java 6 beta, although it should be noted that since NetBeans, the JDK 6, and the application server are all beta, some oddities may occur.

The JEE5 SDK and NetBeans 5.5 are still beta because JEE 5 is not final, as minor changes may still occur in the various specifications. The Java EE 5 specifications are expected to become final in the second quarter of 2006.

http://java.sun.com/javaee/5/javatech.html says no Portlet in GlashFish. (but they tocuhed up JSF/JSP so they work together)

Tiles be easier to integrate then portlets, no?
like http://raibledesigns.com/page/rd?anchor=large_sites_powered_by_java

(and then you might as well not use EJB either)
So WW2+Tiles+iBatis on Resin w/ Groovy is the "standard", ex:
http://www.caucho.com/resin-3.0/thirdparty/groovy.xtp

Again, C# last year is shiping w/ MasterPages/WebParts.

If there's one thing clients ask for, it's protlets. They don't ask for JSF or EJB. shame.

Anyone from JCP care about the platform?

.V

http://java.sun.com/javaee/5/javatech.html says no Portlet in GlashFish. (but they tocuhed up JSF/JSP so they work together)Tiles be easier to integrate then portlets, no?like http://raibledesigns.com/page/rd?anchor=large_sites_powered_by_java(and then you might as well not use EJB either)So WW2+Tiles+iBatis on Resin w/ Groovy is the "standard", ex:http://www.caucho.com/resin-3.0/thirdparty/groovy.xtpAgain, C# last year is shiping w/ MasterPages/WebParts.If there's one thing clients ask for, it's protlets. They don't ask for JSF or EJB. shame.Anyone from JCP care about the platform?.V

Speak for you, I am asking for JSF and EJB. There were so many frameworks in the past and how many innovations they pushed was fantastic but I am more then happy to some standards grow out from those ideas.

I am more then happy to some standards

It be good if portlets where in!

Tiles are not JCP standard, maybe they should be. That "big client" link client looks to go Tiles. I was reading a lot about .NET, nice to have a stnadard look of site.


TG

I am more then happy to some standards

It be good if portlets where in!Tiles are not JCP standard, maybe they should be. That "big client" link client looks to go Tiles. I was reading a lot about .NET, nice to have a stnadard look of site.TG

I agree portlets is a must but my point was not at the expense of EJB and JSF.

C# last year is shiping w/ MasterPages/WebParts.If there's one thing clients ask for, it's protlets. They don't ask for JSF or EJB. shame.Anyone from JCP care about the platform?.V

When I do Sharepoint programming, I just do a regular web app then just use a generic link web part. Otherwise it is a pain. And Sharepoint is a big enough pain anyway. And that is the downside of C# + WebParts. It is only good for Sharepoint. yippee.

Though we would like for portlet APIs to be supported in this release I think it is not a core need right now. Mostly as J2EE/JEE developers and architects we are looking forward to improvements on our current APIs (EJB, JSP, etc..) and inclusion of things that are of real need right now. IMHO, portlet APIs are not a real need right now and can be added later.

.Net was released with WebParts but that does not mean JEE has have portlets right away inorder to match up to that.

T... not a core need right now.
<snip>
.Net was released with WebParts but that does not mean JEE has have portlets right away in order to match up to that.

Last year C# free SDK shiped. It's not right away. JEE 5 is not even final yet, sometime after vendors would ship, after the spec is final. So a year after .NET released would be OK to catch up. It seems that in this, in order threads on JEE 5, most people feel Portlet is important enough.

How do you do consistent look and feel of a site now?
Header/footer/ad bar, etc. A hack?
Does it integrate w/ JSF tools out of the box?

If it *can be added later*, then spec it now, so that *it could be added*. Then vendors could come up w/ a partial support as planed, and an upgrade to porlets release for clients/developers when ever they have it.

TG

http://java.sun.com/javaee/5/javatech.html says no Portlet in GlashFish. (but they tocuhed up JSF/JSP so they work together)Tiles be easier to integrate then portlets, no?like http://raibledesigns.com/page/rd?anchor=large_sites_powered_by_java(and then you might as well not use EJB either)So WW2+Tiles+iBatis on Resin w/ Groovy is the "standard", ex:http://www.caucho.com/resin-3.0/thirdparty/groovy.xtpAgain, C# last year is shiping w/ MasterPages/WebParts.If there's one thing clients ask for, it's protlets. They don't ask for JSF or EJB. shame.Anyone from JCP care about the platform?.V

Vic, you and your portlets:-) Every post you made in the last few days has the word portlet in it. What's with you and portlets?

Ilya

What's with you and portlets?Ilya

Just a bug people get now and then, I think it helps Java be better. Also vendors then get to see what we developers have to cook. Else, get a C# version of resume for me.

.V

What's with you and portlets?Ilya

Just a bug people get now and then, I think it helps Java be better. Also vendors then get to see what we developers have to cook. Else, get a C# version of resume for me..V

Vic, listen I know you're a smart guy and all, but I'm not sure if anyone ever told you...

It's not that your post are not grammatically correct, I'm usualy pretty good at deciphering those, it's just that I can't understand anything you're saying. All I see is some random word with the word portal in there. I'm sorry, no personal attack, I don't do those, just telling you the truth. I'm yet to understand any of your posts, but I'm sure you know your stuff.

Ilya

What's with you and portlets?Ilya

Just a bug people get now and then, I think it helps Java be better. Also vendors then get to see what we developers have to cook. Else, get a C# version of resume for me..V

Vic, listen I know you're a smart guy and all, but I'm not sure if anyone ever told you...It's not that your post are not grammatically correct, I'm usualy pretty good at deciphering those, it's just that I can't understand anything you're saying. All I see is some random word with the word portal in there. I'm sorry, no personal attack, I don't do those, just telling you the truth. I'm yet to understand any of your posts, but I'm sure you know your stuff.Ilya

So I am not the only one, I thought it was because my english wasn't good enough :

What's with you and portlets?Ilya

Just a bug people get now and then, I think it helps Java be better. Also vendors then get to see what we developers have to cook. Else, get a C# version of resume for me..V

Vic, listen I know you're a smart guy and all, but I'm not sure if anyone ever told you...It's not that your post are not grammatically correct, I'm usualy pretty good at deciphering those, it's just that I can't understand anything you're saying. All I see is some random word with the word portal in there. I'm sorry, no personal attack, I don't do those, just telling you the truth. I'm yet to understand any of your posts, but I'm sure you know your stuff.Ilya

So I am not the only one, I thought it was because my english wasn't good enough :

+1

We have 3 kinds of geniuses:
1) their genius is recognised during their lifes
2) their genius is recognised after they die
3) their genius is so outstanding so it is never recognised

Sun has announced the simultaneous release of preview versions of the JEE 5 SDK and NetBeans Enterprise Pack 5.5.

For what it's worth, it's "Java EE", not "JEE."

For what it's worth, it's "Java EE", not "JEE."

This page should change: http://java.sun.com, becuase that is where we get it from.

Idealy, vendors ship a "partial" release to Java EE v5, and then ship ugrades when they have it integrated w/ Portlets or some other thing, but to me a full spec should include a very popular need, such as Portlets.
This would avoid "non standard" API need, customer questions about C# master pages, and us developers not having to do bit-twidling - so we can focus on requirments. The vendors should do that for us.
No reason to hold back an API. This setups up a nice Java EE 6, at least there would still be a market.

.V

Link lead to a page that exists from some times ago.
it show that this piece of software released in 11/05 not in 02/06
when will they update this page to reflect the current status ?

Link lead to a page that exists from some times ago.it show that this piece of software released in 11/05 not in 02/06when will they update this page to reflect the current status ?

The new bits are on the way - should probably be there in the next fifteen minutes. Yesterday was a holiday here in the US so things are a bit slow getting updated.

You'll be able to get the bits directly from this page :

http://java.sun.com/javaee/downloads/

Rich Sharples
Sun Microsystems
http://blogs.sun.com/theaquarium

I tought JSF was going to be part of this preview ? Is it still going to be included in the enterprise pack ?

Bits are now live: http://java.sun.com/javaee/downloads/index.html

Below are some of the techncal highlights of the SDK.

* Based on Java EE 5 platform specification
o Enterprise JavaBeans 3.0
o Java Persistence API providing a POJO based persistence model.
o JavaServer Faces 1.2
o Web Services Metadata for the Java Platform 1.0
o Java API for XML-Based Web Services (JAX-WS) 2.0
o Java Architecture for XML Binding (JAXB) 2.0
o Streaming API for XML (StAX) 1.0

* Improved developer experience
o Simplified Java EE APIs and annotations which reducing the amount of code a developer needs to write
o Open/Modular/Extensible architecture
o Lightweight, low footprint, highly performant runtime
o Integration with NetBeans Enterprise Pack 5.5 which makes iterative application development quicker and easier.
o Enhanced Blueprints and Samples providing step by step guide to program on new Java EE 5 platform. Blueprints also includes guidelines to develop Web 2.0 based applications with AJAX and other popular technologies.
o App Server PE 9 also bundles deployment ready Derby database making it possible to develop and deploy end to end Java EE applications.

* Java SE 5 and 6 support
o Application Server PE 9 beta integrates Java 2 Standard Edition 5.0 which includes enhanced management and monitoring features and many performance and scalability improvements.
o Java SE 6 beta can also be used in conjunction with Application Server PE 9 beta.

* Sophisticated Administration
Application Server PE 9 provides remote secure management using a browser based Admin console and scriptable command line interface.
New admin console features inlude:
o Comprehensive web services management support including web services discovery, management, monitoring and provisioning.
o Enhanced application Monitoring, Visualization and Diagnosis
o JMX MBean API to provide for remote, secure, programmatic
administration and monitoring using JMX
o Built in management rules and triggers which can be expanded programmatically.

* Fast Infoset support improves webservices performance multiple folds.

* Java Web Start technology support
Standalone rich Java applications can be accessed with a single click over the network from Application Server eliminating the need of local client configurations etc.

* Improved Security
Application Server PE 9 supports OASIS Web Services Security
standards including X.509, username/password and SAML token
profiles.

* Platform and 3rd party software Support
o Application Server PE 9 beta runs on wide range of operating systems, databases, webservers and hardware platforms.
The list includes but not limited to Solaris 10 (on x86 and SPARC), Windows 2003, Windows XP, MAC OS, Java Desktop System, Red Hat Linux 4.0, Derby, Oracle 10g, MySQL 5, Sun Java System Web Server, Apache webserver, Microsoft IIS etc. For complete list, please check the release notes which comes with product documentation.
o App Server PE 9 also for the first time will support 64 bit mode on Solaris systems.

* Backend Connectivity
o Built-in JMS resource adapter makes it easy to connect to backend systems. Application Server PE 9.0 adds out of box connectivity for IBM MQ Series and Sun's MQ Server.



Pratik Parekh
Product Line Manager
Application Platform Products
Sun Microsystems Inc.

The BPEL Orchestration Designer and the integrated PXE (Process Execution Engine) are what really sets NetBeans 5.5 apart for me. These tools are not unique, but by providing them "out of the box" I think we will see much more activity in process driven design, and the creation of many more service oriented mashups.

Very nice stuff,

--JohnR

Exactly John. Can it be the case that this offering includes a gratis BPEL server and BPEL design tool?
Will those tools be commoditized in the near future?

Exactly John. Can it be the case that this offering includes a gratis BPEL server and BPEL design tool? Will those tools be commoditized in the near future?

With Intallio's donation of PXE (pronounced pixie) to Apache as part of the ODE project, it is very clear that orchestration engines are destined to be commoditized.

PXE is particularly interesting, since it is a modularized process execution engine that just happens to have a BPEL binding... If you hate BPEL, you can write your own process language and create a binding for PXE.

I tought JSF was going to be part of this preview ? Is it still going to be included in the enterprise pack ?

JSF is now part of Java EE 5 (the spec), and it *is* included.

  - eduard/o

How do we get Bill's attention before he drives of the road?

Like: http://blogs.sun.com/roller/page/theaquarium/20060220
This says to run Porlets not on GlassFish but some other Java server.
And... for GlassFish? Is this true of other vendors?
I don't want as a developer to have a JSP+JSF situation.

Just fix the web page and list the portlets Bill S.

.V

How do we get Bill's attention before he drives of the road?Like: http://blogs.sun.com/roller/page/theaquarium/20060220This says to run Porlets not on GlassFish but some other Java server. And... for GlassFish? Is this true of other vendors? I don't want as a developer to have a JSP+JSF situation.Just fix the web page and list the portlets Bill S..V

Victor, that page (which I wrote) says that the Portlets run in JBoss and Sun's portal (which runs on Sun's App Server - which is a very close relative of GlassFish). My point is that 168 portlets are pretty portable already (as you would hope).

If personally think Portlets would be a very reasonable part of the EE spec. (but I am not part of the JCP and have no influence there). If you want to influence the specs. keep doing what you are doing; be persistent; make a case - people are listening.

As for GlassFish - you can expect it to expand in many interesting ways - keep watching.

Rich Sharples
Sun Microsystems
http://blogs.sun.com/theaquarium

people are listening.

I am on it. I kind of mentioned several things that got fixed before, ex: WebStart Scarry Screen docs in the Sun Java forums, no works good.

It be great for the EG vendors to talk to their current customers, see what would make them upgrade.

Portlets!
Portlets!
Portlets!

.V

Also I have heard that Pluto runs on GlassFish; we just have not confirmed it enough to make a big deal of it, but it is our intention to try to make it run.

GlassFish is very much focused on what the community wants. As long as it does not conflict with a basic requirement like Java compatibility, we will try to keep our customers (you!) happy.

  - eduard/o

I have heard that Pluto runs on GlassFish

So just make it spec then. It does change things if I (a developer) and customers (that pay) can call for vendor support if JSF won't work w/ Portlet, and that it's accross vendors. Not like we saw last week, it runs on Tibco but not on jBoss or ... BEA Java EE v5 is diferent then Sun Application Server or Glassfish.

It be like not inculding JSP in spec, but say "verbaly" you can plug in a JSP. Support it. Compete on integration of the spec that means something.

Tiles would just fracture and make it fragile. If we do Tiles, might as well do Hibrenate, etc.

.V

For those of you looking for official Java EE jars, fair warning: the jars bundled in the download are *not even close* to the current status of the various Java EE specs. Is this just Sun trying to trick people into downloading Glassfish?

-Patrick

--
Patrick Linskey
http://bea.com

Hi Patrick,

The official Java EE 5 jars will be there when the Java EE 5 specification is *final* later this year. Nobody from the Expert Group(including JBoss or BEA) have them by definition.

This download is a "Beta", not a trick. Beta releases are very important in the lifecycle of any product.

People who want to test the latest nightly Java EE 5 jars, can use the nightly builds of the GlassFish open source project. You cannot get a 'more' up to date version of the specification elsewhere than there :http://download.java.net/javaee5/installer-nightly/

Thanks,

Ludo

The official Java EE 5 jars will be there when the Java EE 5 specification is *final* later this year.

Indeed. I didn't say that they were final. My OP just pointed out that for those people who are looking for final jars, they should take note that the jars available in the Glassfish beta are not remotely close to where the current Java EE specs are.

I then editorialized a bit. I think it's at least a bit disingenuous of Sun to use the http://java.sun.com/javaee URL to promote betaware of an unrelated product like that.

Beta releases are very important in the lifecycle of any product.

Understood, and agreed. However, putting a beta of a particular product up on the very place that people go to get the official Java EE spec jars and documentation seems like a bit of a flagrant abuse of Sun's special role in the JCP, personally. This is *not* a meaningful beta release of the Java EE jars, since it's not anything near up-to-date relative to the actual specs in the Java EE spec process. So it's just a beta of Glassfish, disguised as a Java EE jar download. I mean, you can't even download just the jars without getting Glassfish!

People who want to test the latest nightly Java EE 5 jars, can use the nightly builds of the GlassFish open source project. You cannot get a 'more' up to date version of the specification elsewhere than there :http://download.java.net/javaee5/installer-nightly/

Again, that's a link to the Glassfish installer, not to the Java EE 5 jars. In other words, I can go to that URL to get an up-to-date version of an *implementation* of the specification, not the spec itself.

-Patrick

--
Patrick Linskey
http://bea.com

Sorry, Patrick but I think you are mixing up a bunch of different topics.

re: "not remotely close to where the current Java EE specs are" - that is a stretch.

I don't track all the specs but I track quite carefully the WS and XML specs (JAX-WS 2.0, JAXB 2.0, StAX) and those are very very close [BTW, thanks to BEA for their help with StAX!]. Actually, AFAIK, the only place where there may be some diff is with EJB, which is the one that reached PFD the last, and I
believe the diffs are pretty small.

This is no different than in earlier turns of the Java EE platform. I've been the JSP spec lead where we had small disconnects between the implementation and the spec. The premise has been that developers will not give feedback until there is a concrete implementation, and the sooner we get the feedback the better.

re: API JARs -

Again, I only track closely a some, but you can get the latest of may from jcp.org, from GlassFish (under CDDL), and the Java EE licenses (be them comercial or those under the non-profit grants) can get them from their Expert Groups.

In general, the only people that are interested in an API JARs without an implementation behind are the vendors and they have them.

Hope this helps some,
  - eduard/o

Sorry, Patrick but I think you are mixing up a bunch of different topics.

Which topics are those? So far, I've pretty much mentioned that I'm surprised that a bit of prime Java EE real estate is being used to promote Glassfish, and that the jars aren't up-to-date with the specs available today.

Actually, AFAIK, the only place where there may be some diff is with EJB

Could be. I haven't looked elsewhere.

I believe the diffs are pretty small.

FWIW, they're actually pretty significant.

In general, the only people that are interested in an API JARs without an implementation behind are the vendors and they have them.

It'd be really nice for the entire community if there actually *were* an official set of Java EE 5 beta jars (hence my elation earlier this morning when I first read the headline). As it stands, all the different vendors out there with previews of different pieces of the Java EE puzzle distribute spec jars in whatever state they currently support. It'd be neat if instead, as spec revisions came out, there was an official "Java EE 5 preview 3" or somesuch that came out regularly, so that vendors could identify exactly how far along their previews were. Sure, this might not always work out as vendors do their implementations, but it'd put the community in a position where they could play around with "Java EE preview 3", and then plug in different vendor previews. As it stands, there are often incompatible code differences between different vendor preview jar implementations, and usually the only way to find out what they are is to try swapping vendors and see what breaks.

Ah well. Preview nirvana is not something we've attained yet, I guess.

-Patrick

--
Patrick Linskey
http://bea.com

Patrick, I still do not understand what is the problem.

There have been releases of other products (not by Sun) that use a non final version of some parts of Java EE 5 API and are positioned as final releases - not as beta. I did not see any complains, even though it is obvious that any applications developed for them will require some changes when the specification goes final (big or small changes, does not matter). This release of Glassfish and NetBeans is clearly marked as a beta and preview release. No preview can be 100% the product, that's why it is a preview. I would not encourage anybody to use this in production environment. It is for evaluation, playing with it, getting ready for the real thing...

BTW: Note that Glassfish is THE reference implementation of Java EE 5. This is why you get the latest spec jar files from Glassfish site.

There have been releases of other products (not by Sun) that use a non final version of some parts of Java EE 5 API and are positioned as final releases - not as beta. I did not see any complains

I've clearly not done a very good job of communicating my point. I'll try once more here, and then give up:

It's not a Glassfish beta that I was surprised by. My initial read of the posting led me to think that Sun had put out a preview of the Java EE SDK, which is phrasing that I associated with jars of the Java EE spec APIs, not impls of same. I was again surprised by the relative staleness of the jars that were available. This makes sense given the current state of Glassfish, but for someone expecting to be downloading a Java EE 5 API preview, it was disappointing.

BTW: Note that Glassfish is THE reference implementation of Java EE 5. This is why you get the latest spec jar files from Glassfish site.

Actually, that logic doesn't really follow. It is true that Glassfish is the RI. However, typically, the JCP specs have separate downloads for the spec jars, the PDF, and the RI. Further, they aren't actually the latest spec jar files; they're a relatively old snapshot.

-Patrick

--
Patrick Linskey
http://bea.com

BTW: Note that Glassfish is THE reference implementation of Java EE 5. This is why you get the latest spec jar files from Glassfish site.

Actually, that logic doesn't really follow. It is true that Glassfish is the RI. However, typically, the JCP specs have separate downloads for the spec jars, the PDF, and the RI. Further, they aren't actually the latest spec jar files; they're a relatively old snapshot. -Patrick-- Patrick Linskeyhttp://bea.com

I second Patrick on this. Why do we need to download Glassfish or the Sun App Server in order to obtain just simple API jars?

PDFs AFAI could see, we can still get them from jcp.org

I second Patrick on this. Why do we need to download Glassfish or the Sun App Server in order to obtain just simple API jars?PDFs AFAI could see, we can still get them from jcp.org

Without getting in to other details - I'm curious, why do you need them? Are you implementing an App Server? Or is there some other purpose you have in mind?

I second Patrick on this. Why do we need to download Glassfish or the Sun App Server in order to obtain just simple API jars?PDFs AFAI could see, we can still get them from jcp.org

Without getting in to other details - I'm curious, why do you need them? Are you implementing an App Server? Or is there some other purpose you have in mind?

Firstly, I need only some of them, and secondly, yes I'm implementing some APIs. Since these are APIs previews I guess the purpose of releasing this early is to gather feedback from the community, which may not necessarily be by the means of using an app server.

It also nice to have them released on their own so we can track app server previews progress.

Nothing against Glassfish. Keep up the great work guys.

Hint ;-) There might also be application frameworks wanting to support JPA from an access perspective, not implementing a JPA provider. Those do need the JPA API jar as well, and it's currently quite a pain to get a proper version of it.

Juergen

...It'd be neat if instead, as spec revisions came out, there was an official "Java EE 5 preview 3" or somesuch that came out regularly, so that vendors could identify exactly how far along their previews were.-Patrick-- Patrick Linskeyhttp://bea.com

Why doesn't BEA lead the pack then and do exactly that? I'm pretty sure BEA can wield some muscle on the JEE committee.

It'd be really nice for the entire community if there actually *were* an official set of Java EE 5 beta jars (hence my elation earlier this morning when I first read the headline).

Ah, I think I understand what you mean. Yes, something like that would have some benefits, but there would be some disadvantages. For example, there would also be an extra coordination cost across all the implementations and Expert Groups (read slowdown) hurdle that I am not sure the community would like to pay for. It is hard enough to coordinate once a release for FCS.

In practice that happens is that the specs tend to align around PFD and vendors do what makes sense to them business-wise. Some track the spec very quickly, some much less so; some times the tracking is quite uneven, be it for business or technical reasons. For example, this go around Oracle and JBoss are tracking very aggresively EJB 3.0 but, as far as I can see, they are lagging quite a bit on JAX-WS 2.0 and JAXB 2.0.

Is there any option getting a free license for organization who providing free government grants or education grants

Is there any option getting a free license for organization who providing free government grants or education grants

Patrick Linskey

Well, as developer I don't care, I have waiting for Java EE5 a long time now and I think is nice Sun make a PreView release. I also think is very nice they have made a Netbeans 5.5 together with the SDK EE 5 preview release.

But think SUN should have called the AS "Glassfish AS" and not "Sun Appserver 9", it is confusing. I have understand the bundle contains Sun Appserver 9 beta which equals Glassfish AS beta.
Next realse of the Netbeans 5.5 will SUN called it SUN....something, so stupied, I hope not!!!!!! ! ! !

I also would like BEA to have a PreView release avaible, but I haven't seen anything yet, but perhaps it is there somewhere?

:-)

I would like to highlight the difference between Glassfish and Sun Java System App Server 9. Appears quite a few have raised this question and understandably so. We are trying to simplify this as much as we can ..

The Open Source GlassFish Community is umbrella site for the app server and related Web services technologies and where you go to download the latest binaries of App Server and related technologies as they are developed. App Server we are referring here is appserver Sun has open sourced. You also go to this community if you are interested to contribute to the code, want to communicate ideas/features with engineers developing the product or want to get the latest source code of the product. Note that this is a product under development and not the final product. The GlassFish bits are in continuous development, so there is a lot of change and there is a new build nearly every night. Currently, GlassFish project is developing Java EE 5 based Application Server.

The Sun Java System App Server PE is built from the GlassFish bits and it includes some add-ons like samples, installer and other bits. At this time the add-ons are very minimum and we anticipate this to continue.
Important difference to note that though derived from open source Glassfish project, this is Sun's version which will be supported.
Think of App Server 9 as a snapshot of the GlassFish bits that is stable, very well tested and very well supported. This will be the version that will be included in Sun's distributions. Also the final release which we will call it Sun Java System Application Server 9 will be Java EE 5 compatible. A snapshot of Glassfish will also be Java EE 5 compatible but the code will move on and its practically impossible for Glassfish community to qualify each and every build for compatibility. So this is also an important difference.

Software Development Kit (SDK) includes Sun Java System App Server 9 along with everything else like blueprints, other preview technologies and more to get the developer started on the technology.

The Reference Implementation (RI), like app server PE, is developed from the GlassFish bits as well. This is the private binary which only JavaEE licensees get. Along with the bits, an important difference here is it includes compatibility test kit (TCK).

Sun also ships an enterprise edition of the product today. It has additional value added capabilities mostly service quality, additional security and availability features. This release also serves as the core Java EE runtime for Java Enterprise System and Suites. http://www.sun.com/jes

My Sun colleague Tony Ng also has blogged about this which has some additional details. http://blogs.sun.com/roller/page/tonyng#what_s_the_difference_sjsas

Hope this helps.

Thanks,
-Pratik
Product Line Manager
Sun Microsystems Inc.

Hello Pratik,

I'm considering using SUN's Java Enterprise Edition offerings for our commercial healthcare software solutions. Can you direct me to a "responsible" person to discuss my questions? It concerns some of the SeeBeyond technologies; it’s unlike SUN's character to see SeeBeyond offerings closed and proprietary.

I've had horrible experience so far trying to contact SUN's healthcare group in Rocky Hill CT!

I'm really beginning to understand why JBoss' market reach is so much more superior to SUN's ability...

George,

Sorry that you are having difficulty to connect to right folks. I have passed on the message to concerned folks at Sun. You can send me additional details at pratik [at] sun.

Thanks,
-Pratik

Hi Pratik,
Thanks for the information!
Why don't you have AS called Netbeans AS 5.5 !!
I think the AS will be popular with a name like that.
And then of course a Sun Java System App Server 9
-ove

Almost all software projects have multiple ongoing development branches. The Java EE 5 SDK is from the stable, M5, branch from GlassFish. That corresponds to b32g. The more aggressive branch is at b37 (actually b38 if you go by nightlies, but b38 should not be promoted until tomorrow, if all goes well).

No tricks here. This is the most recent stable build we can deliver. There will be others later, in the road to FCS.

This is all pretty standard practice. The only difference is that you can see all the details at GlassFish.

   - eduard/o

As I mentioned above, I'm not doubting the value of betas. I'm just surprised that http://java.sun.com/javaee is the beta page for Glassfish.

So far, the posts from Sun employees on this thread seem to have been from people on the Glassfish team, and this seems like a Glassfish beta. That's fine. It's a bummer, however, that the description talks about a Java EE 5 beta, which got my hopes up that maybe someone had actually pulled together the current state of all the Java EE 5 spec APIs in one place.

-Patrick

--
Patrick Linskey
http://bea.com

does anyone know when java studio creator 2 will be ported to netbeans 5 platform .. or if it will be provided as plugin in the enterprise pack ?

I am doing porlet development with JSC2
and aslo I am using EJB 3.0
I have read about facelets and I found it better than JSP for JSF
I am waiting for a tool which provide all those to me
since I am in Iran I can use every tool free of charge (I have also Together 2006, IBM rational architect 6,...) but I found out JSC2 is the best while you are developing.
hope some one from sun answers when will JSC2 ported to NB5.5?

Well... There are lot of technological improovements in JEE5. But I doubt whether my customers ever want me to just enjoy the technologies... They pay me to provide solutions for their problems, not to enjoy the technologies.

With Java,
Can I provide a nice looking web portal adhering to standards?
Can I provide a standard reporting solution?

Just look at .NET way... They have solved those problems for endusers and most importantly they have done it in a standard way.

Also as a developer I dont want to learn all WebLogic, WebSphere and Jboss to provide java solutions. It make my life missarable and learning BEA doesnt mean that I know Java. For me as a developer standardization is also much better in .NET.

It's the time to change the attitude of Java leaders... :)

Hasith Yaggahavita

The .net standard way is.
Buy the IDE from Microsoft, buy the portal server from Microsoft (which in itself is a huge pain)
move away from Microsofts path which costs huge %$$$ and you are screwed. Run into a showstopper along Microsofts path and you are screwed!

Gimme a break I have done enough with sharepoint to know not to like that product.

The .net standard way is.Buy the IDE from Microsoft, buy the portal server from Microsoft (which in itself is a huge pain)move away from Microsofts path which costs huge %$$$ and you are screwed. Run into a showstopper along Microsofts path and you are screwed!Gimme a break I have done enough with sharepoint to know not to like that product.

I agree 100%. A lot of what I do with .Net and Sharepoint is outside the box ( for a client). And it is a pain.

The .net standard way is.Buy the IDE from Microsoft, buy the portal server from Microsoft (which in itself is a huge pain)move away from Microsofts path which costs huge %$$$ and you are screwed. Run into a showstopper along Microsofts path and you are screwed!Gimme a break I have done enough with sharepoint to know not to like that product.

I agree 100%. A lot of what I do with .Net and Sharepoint is outside the box ( for a client). And it is a pain.

Guys, I'm not talking about the sharepoint server. I agree that I also hate the way MS way of handling their products. But I'm talking abt the features they are building in to .NET framework.

I'm curruntly engaged in developing ASP.NET 2.0 portal site and we were able to giveout the architectural release in just one weeks time. And no share point server at all. Infact we are considering going with a free, simple CMS for content management.

My point here is the .NET stratergy delivers what is requested by the users, but Java still stucked with container-or-noncontainer kind of puzzles.

The .net standard way is.Buy the IDE from Microsoft, buy the portal server from Microsoft (which in itself is a huge pain)move away from Microsofts path which costs huge %$$$ and you are screwed. Run into a showstopper along Microsofts path and you are screwed!Gimme a break I have done enough with sharepoint to know not to like that product.

I agree 100%. A lot of what I do with .Net and Sharepoint is outside the box ( for a client). And it is a pain.

Guys, I'm not talking about the sharepoint server. I agree that I also hate the way MS way of handling their products. But I'm talking abt the features they are building in to .NET framework.I'm curruntly engaged in developing ASP.NET 2.0 portal site and we were able to giveout the architectural release in just one weeks time. And no share point server at all. Infact we are considering going with a free, simple CMS for content management.My point here is the .NET stratergy delivers what is requested by the users, but Java still stucked with container-or-noncontainer kind of puzzles.

.NET strategy is centered around making bucks, so if they can implement something horribly and make 95% of companies buy it, because they can slap together a few pieces to make the crap work, they'll do it right away.

It's sort of like the RoR stuff, we can get a CRUD site up in a day, wow great, so what? Product development is a fraction of what it takes to maintain and extend the application.

Ilya

.NET strategy is centered around making bucks, so if they can implement something horribly and make 95% of companies buy it, because they can slap together a few pieces to make the crap work, they'll do it right away.

It's sort of like the RoR stuff, we can get a CRUD site up in a day, wow great, so what? Product development is a fraction of what it takes to maintain and extend the application.

There is a saying "When a person only has a hammer, everything looks like a nail". I believe that a big problem in the Java community is that we have so many tools, we can't recognize a nail when we see one!
Quartez<br>
"Sometimes, it is just nail"

... we can't recognize a nail when we see one!Quartez

But I think we can recognize Tool though. :)

By the way I have a problem running the Birt report viewer with the glasfish(glassfish-installer-b38-nightly-21_feb_2006.jar).Only title of the birt report show up inside the viewer. The resulting part of the report appears blank. I wonder if somebody tried the Birt with Glassfish?birt download:http://download.eclipse.org/birt/downloads/Thank you,Vladimir

Have you tried anything else? Tomcat? Does it exhibit the same symptoms? It might not be the the App Server. Check out the BIRT forums for more info.

Have you tried anything else? Tomcat? Does it exhibit the same symptoms? It might not be the the App Server. Check out the BIRT forums for more info.

On tomcat 5.5.15 everythings working fine.
That why I believe the problem connected to glassfish.
Anybody tried the Birt with the Glassfish?

Thank you,
Vladimir

Some more reasons why it's not just app-server vendors that might want the API jars on their own: you need them when compiling application code that uses the APIs, and if you use stubs or "mock objects" of any kind to unit-test your application code. For neither of these uses do you need or want an entire app server, just the API jars.

So I agree with the earlier post that it would be clearer and more flexible to have an obvious "Java EE API" download with the API jars, specs, licence, and Javadoc on their own, rather than only being able to get a whole app server (and with Javadoc that combines the APIs and "Sun Java System Application Server PE 9" packages).

I've been encouraging the owners of each spec to make
available API jar files for their specs, and many of
them do. Collecting them together into an overall
javaee.jar file is also a good idea. One reason we
haven't just dumped out the current one that's part
of GlassFish is that there are many real class files
in that jar file. As I'm sure you all know, any product
containing Java technology must provide a complete
implementation of that technology. The existing
javaee.jar file looks a lot like a very incomplete
implementation of Java EE. We need to make it clear
that it's not intended to be any part of a Java EE
implementation by stripping out all the executable
content, leaving only the API definitions, which is
what most people want out of such a jar file. We'll
look into doing that soon. While we believe it's a
simple operation, it's also non-trivial and we need
to find someone to work on it.

  Bill Shannon