Vote For JavaMail To Be Part Of J2SE

[freesoft_2000]

Hi everyone,

I have submitted a RFE at sun to make JavaMail Part of
J2SE so please vote for it if you want it to be part of J2SE

Here is the link

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330014

Thank You

Yours Sincerely

Richard West

 

[Harry Bosch]

I ask "why"? What is the point? So a developer needs to download an
API. They only have to do this once and only once. So, by adding it
to the standard API it will need to be removed from the J2EE dev kit.
So, now you have this conflict. No thanks. Not a big deal.

 

[Andrew Thompson]

I have submitted a RFE at sun to make JavaMail Part of
J2SE so please vote for it if you want it to be part of J2SE

I'd prefer it not be included in the core API.

The number of end users that require 'mail enabled' java
applications simply does not justify the extra weight
to the API. It makes more sense to supply the JavaMail
jar only to those clients that require it.

 

[Drazen Gemic]

I ask "why"? What is the point? So a developer needs to download an
API. They only have to do this once and only once. So, by adding it
to the standard API it will need to be removed from the J2EE dev kit.
So, now you have this conflict. No thanks. Not a big deal.

I agree. They should have let us vote against as well.
JDK is too "fat" already.

DG

 

[Roedy Green]

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330014

I hope you included JAF too in the request.

 

[Roedy Green]

The number of end users that require 'mail enabled' java
applications simply does not justify the extra weight
to the API. It makes more sense to supply the JavaMail
jar only to those clients that require it.

What then needs to happen are ways for extra jars to be installed
without any fuss, as mere side effect of using the API in a program.
Even the JRE should work that way with a tiny kicker app install.

 

[Andrew Thompson]

What then needs to happen are ways for extra jars to be installed
without any fuss,

JWS ...

..as mere side effect of using the API in a program.
Even the JRE should work that way with a tiny kicker app install.

Besides the <EXTENSION> element that refers to libraries, JWS
1.5 also offers an installer element that is run only once.

Cool, huh?

 

[Roedy Green]

JWS ...
<extension name="javamail" href="http://..." />

Does that have the same effect as INSTALLING JavaMail? Does it have
the same effect as installing it only it is missing, or is JWS its own
little universe of jars?

 

[Andrew Thompson]

Does that have the same effect as INSTALLING JavaMail?

(snip)

See note [1] in..
<http://groups.google.com/group/comp.lang.java.programmer/msg/aa0d77511dfc71eb>

I think it leads to answers for most of your questions.

 

[pkriens]

I think we should actually reverse course and REMOVE much of the APIs
in the JRE. Obviously, then there is a need for a mechanism to download
the packages that are additionally needed.

The OSGi (www.osgi.org) has been working on such a package manager for
the last years and is now finding deployment in Apache
(felix.apache.org) and Eclipse, as well as in many commercial products.

Standardizing a small core + a managed package model will do a lot more
than further bloating the standard download.

Kind regards,

Peter Kriens

 

[Roedy Green]

Standardizing a small core + a managed package model will do a lot more
than further bloating the standard download.

Before any of this can happen, Sun has to sort out its problems with
having more than one JRE/JDK installed at once.

JAWS is the best bet so for a full solution to this problem.

It has many pieces in place:

1. ability to autoinstall a JVM

2. ability to install a library jar from a third party source.

3. ability to update a jar just sending changed members.

It cannot without kludging do CD installs and updates.

It still requires a fair by of geeky stuff to make it work, -- setting
up associations, downloading and installing an Initial JRE,
configuring the java console, dealing with multiple JRE problems,
fiddling with unique Java configuration tools in the browsers.

It is not self starting. You have to get Java installed first before
anything works unless you use that bizarre OBJECT/EMBED syntax.

The other problem is it is temperamental. Sometimes it simply does
not work and there appears to be no way to track down why.

 

[JScoobyCed]

Hi everyone,

I have submitted a RFE at sun to make JavaMail Part of
J2SE so please vote for it if you want it to be part of J2SE

If you request such an API in the J2SE, that means a lot of more API
would also need to be here. What if then, I need JMF, JAVACOMM, ...
We will fall in a fat(ter) J2SE where most of the J2SE developeers need
only a fragment of it.

A smarter request would be to ask for a dynamic bundle of API in the
J2SE. More explicitely: the download screen of the J2SE (or J2EE) would
propose a shopping cart like screen, with the list of available APIs (
and there different releases). At the end, when you submit the download
button, you download a customized J2SE+API package easy to install.

Now, I don't complain in any way about the J2SE download (except it is a
bit big, as other people here also mentioned).