JavaMail

[Digby]

Hi,

I'm sure this has been mentioned befroe, but I an't find a satisfactory
answer, but why is JavaMail separate from JSE (and JEE?), and then why
is it two separate downloads (mail.jar and activation.jar)?

I'm a massive fan of Java and have been for ages, but having played with
..NET for the last few months, where mail is an integral part of the
framework, I do wonder why Java makes things so hard sometimes. Surely
sending e-mails is a pretty fundamental function these days.

Maybe there's a good reason...?

Dig

 

[jan V]

I'm sure this has been mentioned befroe, but I an't find a satisfactory

answer, but why is JavaMail separate from JSE (and JEE?), and then why
is it two separate downloads (mail.jar and activation.jar)?
Maybe there's a good reason...?

If I were you, I'd go ask the Sun people themselves.. and then post the
answer here

[I totally agree that too often Sun make things ridiculously hard and/or
complex. Clearly the original designers of Java have had very little say on
the continuing evolution of the APIs, and recently even the language
[[generic types syntax? YUECHHH !!!]]]

 

[jan V]

I'm sure this has been mentioned befroe, but I an't find a satisfactory

answer, but why is JavaMail separate from JSE (and JEE?), and then why
is it two separate downloads (mail.jar and activation.jar)?
Maybe there's a good reason...?

If I were you, I'd go ask the Sun people themselves.. and then post the
answer here

[I totally agree that too often Sun make things ridiculously hard and/or
complex. Clearly the original designers of Java have had very little say on
the continuing evolution of the APIs, and recently even the language
[[generic types syntax? YUECHHH !!!]]]

 

[Roedy Green]

I'm sure this has been mentioned befroe, but I an't find a satisfactory
answer, but why is JavaMail separate from JSE (and JEE?), and then why
is it two separate downloads (mail.jar and activation.jar)?

I'm a massive fan of Java and have been for ages, but having played with
.NET for the last few months, where mail is an integral part of the
framework, I do wonder why Java makes things so hard sometimes. Surely
sending e-mails is a pretty fundamental function these days.

Maybe there's a good reason...?

What usually happens is things start out separate, and if they catch
on, they get made part of the main distribution. It is perhaps time to
include Javamail and JAF in the JRE.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Thomas Weidenfeller]

I'm a massive fan of Java and have been for ages, but having played with
.NET for the last few months, where mail is an integral part of the
framework, I do wonder why Java makes things so hard sometimes. Surely
sending e-mails is a pretty fundamental function these days.

Maybe there's a good reason...?

Where do you want to draw the line?

Maybe one out of ten thousand applications needs a mail API. Does that
warrant inclusion into the J2SE core? Is mail really a fundamental
feature for a language? And if yes, do you want to see each and every
other feature which is only needed by one out of ten thousand
applications as part of the Java core? Fine, because I could make use of
a simulation framework in Java as part of the core APIs. Do you want to
see that in every Java SE?

Not that I agree with every choice of library which Sun has included in
the SE (e.g. CORBA, LDAP come to mind). But if I would have to make the
decision I would go for a much smaller core, and a much better organized
set of mandatory standard extensions, where I would require that a Java
licensee has to implement each and every of them. Provision of standard
extensions should not be optional, but they should not be bundled with
the core. They should be available separately in a well defined,
standardized way, and version-managed (DLL hell anyone?).

Not that Sun will do that anytime soon. Instead some people currently
think about extending the language to directly support XML :-(

/Thomas

 

[Andrew Thompson]

..I could make use of
a simulation framework in Java as part of the core APIs.

Heck, yeah! So could I.

...Mail?

 

[Joan]

Heck, yeah! So could I.

How many people do simulations, 1 percent or less?
Waste of resources.

 

[Andrew Thompson]

How many people do simulations, 1 percent or less?
Waste of resources.

'2 put of 3' so far*.

* 85.7% of statistics are made up on the spur of the moment.

 

[Chris Smith]

Heck, yeah! So could I.

This sort of loses Thomas's point... but frankly, I'd be happy if Sun
never considered releasing a "framework" ever again. It's not that the
framework concept is bad; it's that Sun apparently has zero competence
in successfully using it. At this point, nearly every non-trivial
normal programming technique has to be "handled" by some framework
somewhere because, as we all know, programmers in the 21st century
shouldn't have to think about X any more.

If only someone in Sun understood the immense amount of complexity they
introduce with all of that, then I'd give them the green light to go
ahead and use the technique again when it's appropriate to do it.

A simulation framework happens to be something that I am convinced
crosses this line. In order to provide for the features needed by EVERY
simulation, you'd basically have to make it harder just to plug into the
framework than to develop your own limited-purpose framework from
scratch. On top of this, the framework configuration skills would be
very limited, whereas the ability to put together the code to do what
you need is far more widely useful.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Patricia Shanahan]

'2 put of 3' so far*.

* 85.7% of statistics are made up on the spur of the moment.

I've used java for performance simulation of a multi-processor system.

Patricia

 

[digby]

I take all your points, and it's just occured to me that Microsoft has
the advantage of hindsight on some of these issues and can copy the nest
bits from Java, but it also has crammed in a lot of functionality into
..NET that often appears to be ill-thought out and somewhat bloated.

I suppose one could ask that many of the Apache Commons projects could
be incorported into the core framework, but yes, you do have to draw the
line somewhere.

Digby

 

[Thomas Weidenfeller]

I take all your points, and it's just occured to me that Microsoft has
the advantage of hindsight on some of these issues and can copy the nest
bits from Java, but it also has crammed in a lot of functionality into
.NET that often appears to be ill-thought out and somewhat bloated.

MS is in a rather different position than Sun and has a much bigger
advantage: They own the (desktop) operating system on which .NET is
running. And that one already contains the stuff for mailing.

"All" MS had to do was to document their internal component interfaces,
and provide access via .NET, and voila, e-mail support in .NET.

/Thomas

 

[jan V]

Maybe there's a good reason...?

Where do you want to draw the line?

Maybe one out of ten thousand applications needs a mail API. Does that
warrant inclusion into the J2SE core?

They included a pretty substantial sound API, and I'd guess that's being
used by fewer projects than need e-mailing support...

Is mail really a fundamental feature for a language?

Apart from some very well-defined exceptions such as Object and String, APIs
are not part of the language. The boundaries of the language are the
boundaries of the Java Language Specification. The JLS doesn't talk about
99.99% of core classes.

set of mandatory standard extensions, where I would require that a Java
licensee has to implement each and every of them. Provision of standard
extensions should not be optional, but they should not be bundled with
the core. They should be available separately in a well defined,
standardized way, and version-managed (DLL hell anyone?).

If you start unbundling "mandatory standard extensions" then you're opening
the can of worms containing all "Can't do blah because I'm missing bleh"

Not that Sun will do that anytime soon. Instead some people currently
think about extending the language to directly support XML :-(

Extending the language or the API? Please don't mix these two concepts up..
it's confusing.

 

[Raymond DeCampo]

They included a pretty substantial sound API, and I'd guess that's being
used by fewer projects than need e-mailing support...

Note that it would be impossible to do sound otherwise without dropping
to native code, destroying portability. E-mail, OTOH, can be
implemented in a 100% Java manner.

Apart from some very well-defined exceptions such as Object and String, APIs
are not part of the language. The boundaries of the language are the
boundaries of the Java Language Specification. The JLS doesn't talk about
99.99% of core classes.




If you start unbundling "mandatory standard extensions" then you're opening
the can of worms containing all "Can't do blah because I'm missing bleh"




Extending the language or the API? Please don't mix these two concepts up..
it's confusing.

HTH,
Ray