[postlink]
https://j2ee-tutorials-videos.blogspot.com/2014/03/html5-video-tutorial-how-to-learn-html5.html
[/postlink]
http://www.youtube.com/watch?v=k0f9pC8b3wMendofvid
[starttext]This is a Video Tutorial shows how to learn HTML5 Easily in 6 hours
[endtext]
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/how-to-take-advantage-of-html5-css3-and.html
[/postlink]
http://www.youtube.com/watch?v=qSbHiake3aEendofvid [starttext]This is a Video Tutorial shows How to take advantage of HTML5, CSS3, and JavaScript in your Java Web applications
In this code-focused session, you'll learn how to take advantage of HTML5, CSS3, and JavaScript in your Java Web applications. After a quick recap of the history of server-side frameworks, the session revolves around a simple Java EE--stack Web application that is enhanced with a new front end written purely in HTML5, CSS3, and JavaScript. Along the way, it introduces RESTful Web services; configures Jersey JAX-RS to produce Java objects in the right JSON format; compares client-side programming with server-side programming; and touches on issues of client-side testing, debugging, and deployment. [endtext]
In this code-focused session, you'll learn how to take advantage of HTML5, CSS3, and JavaScript in your Java Web applications. After a quick recap of the history of server-side frameworks, the session revolves around a simple Java EE--stack Web application that is enhanced with a new front end written purely in HTML5, CSS3, and JavaScript. Along the way, it introduces RESTful Web services; configures Jersey JAX-RS to produce Java objects in the right JSON format; compares client-side programming with server-side programming; and touches on issues of client-side testing, debugging, and deployment. [endtext]
How to take advantage of HTML5, CSS3, and JavaScript in your Java Web applications | compares client-side programming with server-side programming; and touches on issues of client-side testing, debugging, and deployment.
Libellés :
CSS
,
HTML5
,
JAVA
,
Javascript
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2012/10/why-should-designer-care-for-css3-css3.html
[/postlink]
http://www.youtube.com/watch?v=Z36ThaR6Ozwendofvid [starttext]This is a Video Tutorial explains Why should a designer care for CSS3 [endtext]
Why should a designer care for CSS3 ? | CSS3 Video Tutorial
Libellés :
CSS
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2012/06/web-service-video-tutorial-what-is-web.html
[/postlink]
http://www.youtube.com/watch?v=Zvgiyayv9M4endofvid [starttext]This is a Video Tutorial explains What is a web service? The W3C recommendations for a web service , How to create and consume a web service ...
[endtext]
Part 2 : The W3C recommendations for a web service.
Part 3 : Using a soap client tool to call a web service.
Part 4 : Using the Eclipse 'Web Services Explorer Tool'.
Part 5: Generate the Java classes needed to call the web service using Eclipse.
Part 6 : Call the web service and create objects from the SOAP response message.
Part 7 : Call a web service with a simple return type.
Part 8 : Create a web service using Eclipse.
Part 9 : Using the Eclipse TCP/IP tool to look at SOAP messages
Part 10 : Connect to the GlassFish web service using SSL
Part 11 : Guarantee an SSL connection by using virtual servers in GlassFish.
Part 12 : Create a JAX-WS Web Service for Glassfish using Eclipse.
Part 13 : Create the JAX-WS client using Eclipse.
Part 14 : Require a username and password to use the web service.
Part 15 : Connect using SSL and authentication.
[endtext]
[Updated] Web Service Video Tutorial | What is Web Service ? | The W3C recommendations for a web service | Using a soap client tool | How to create a Web service Client and Service ? | Connect using SSL and authentication
Libellés :
Eclipse
,
SOAP
,
Web Service
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2012/09/social-networking-in-enterprise-ways-in.html
[/postlink]
http://www.youtube.com/watch?v=fD62_ZlsgM8endofvid [starttext]Karen Gettman from Pearson Education discusses the ways in which social networks within corporations (such as NEO) can aid productivity and supplement emails.
[endtext]
[endtext]
Social Networking in the Enterprise | The ways in which social networks within corporations (such as NEO) can aid productivity and supplement emails
Libellés :
Socials Networks
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/07/how-to-integrate-hibernate-framework-in.html
[/postlink]
http://www.youtube.com/watch?v=bHJt3VmjV2cendofvid [starttext]This is a Video Tutorial shows how to integrate the Hibernate framework in our Spring application. We'll create a SessionFactory as a Spring singleton and use that in our DAO class to work with the database, and show data with jsf
Spring 3.2.2
Hibernate 4.1
JSF2
PrimeFaces 3.5 [endtext]
Spring 3.2.2
Hibernate 4.1
JSF2
PrimeFaces 3.5 [endtext]
How to integrate the Hibernate framework in our Spring application and show data using JSF & Primefaces ?
Libellés :
(Java Server Faces) JSF
,
Hibernate
,
Primefaces
,
Spring
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/07/the-differences-between-java-5-6-and-7.html
[/postlink]
http://www.youtube.com/watch?v=VwL_CV9wpg0endofvid [starttext]This is a Video Tutorial shows The differences between Java 5, 6 and 7 | What's New In Java 5, 6, & 7 ? [endtext]
The differences between Java 5, 6 and 7 | What's New In Java 5, 6, & 7 ?
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/07/java-ee-7-overview-implementation.html
[/postlink]
http://www.youtube.com/watch?v=ooumQO8b3_8endofvid [starttext]This is a Video Tutorial explains Java EE 7 Overview | The implementation status of Java EE 7 and looks ahead to Java EE 8 [endtext]
Java EE 7 Overview | The implementation status of Java EE 7 and looks ahead to Java EE 8 |
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/07/java-apis-for-dates-and-time-javas.html
[/postlink]
http://www.youtube.com/watch?v=fyYJA8FeU74endofvid [starttext]This is a Video Tutorial shows Java's facilities for working with dates and times [endtext]
Java APIs for dates and time | Java's facilities for working with dates and times
Libellés :
JAVA
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2012/02/icefaces-jsf-self-serve-video-training.html
[/postlink]
http://www.youtube.com/watch?v=lC9qg_kKBwMendofvid [starttext]This is a Video Tutorial explains
ICEfaces Self-serve Training by ICEsoft Technologies, Inc
Chapter 1: Intro to JSF 2 - Part A:
Chapter 2
Chapter 3
Chapter 4
Chapter 5
[endtext]
ICEfaces Self-serve Training by ICEsoft Technologies, Inc
Chapter 1: Intro to JSF 2 - Part A:
- Lecture: Introduction to JSF 2
- Exercise: Creating an Eclipse Project
- Lecture: Expression Language
- Lecture: Managed Beans
- Exercise: JSF Bean Scope
- Exercise: Value Binding
Chapter 2
- Lecture: JSF Lifestyle
- Lecture & Exercise: Phase Listener
- Lecture & Exercise: JSF Validators
- Exercise: Custom JSF Validator
- Lecture & Exercise: JSF Converters
- Exercise: Custom Converter
Chapter 3
- Lecture & Exercise: Internationalization
- Lecture & Exercise: JSF Selection Components
- Lecture: Input & Output Components
- Lecture: Command Components
- Exercise: Action Event
- Exercise: Action Event w/ Immediate Attribute
- Exercise: DataTable
Chapter 4
- Lecture & Exercise: Navigation
- Lecture: Facelets
- Lecture & Exercise: Facelets Templating
- Lecture & Exercise: Basic Composite Components
- Lecture & Exercise: JSF Ajax
Chapter 5
- Lecture: ICEfaces 2
- Lecture: ICEfaces Direct-to-Dom
- Lecture & Exercise: Single Submit
- Exercise: Window Scope
- Lecture & Exercise: Ajax Push (via ICEpush)
- Lecture & Exercise: ICEfaces Components
- Lecture & Exercise: Advanced Components
[endtext]
ICEfaces & JSF Self-serve Video Training [5 hours] | Introduction to JSF 2 & ICEfaces 2 | Managed Beans | ICEfaces Components | JSF Bean Scope | JSF Lifestyle
Libellés :
(Java Server Faces) JSF
,
Facelets
,
Icefaces
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/java-good-bad-and-ugly-parts-evolution.html
[/postlink]
http://www.youtube.com/watch?v=hcY8cYfAEwUendofvid [starttext]This is a Video Tutorial shows The Evolution of Java: Past, Present, and Future
In my technical presentation ("The Evolution of Java: Past, Present, and Future"), I'll be discussing all of the changes to the Java programming language since its inception. In this this keynote, I'll focus my attention on the starting point: I'll present my candidates for the best and worst features in the platform as it was originally released (JDK 1.0), and explain the reasoning behind my choices. Some of my choices may be obvious, but others will likely surprise you. A splendid time is guaranteed for all.
Josh Bloch
The Text of the video :
Josh Bloch: These days people are writing a lot of books with titles like
'Javascript: The Good Part' and 'Java: The Good Parts'.
But I owe you more.
There's always the yin and the yang.
So I'm gonna give you the "full monty" today.
I am going to tell you about the bad and the ugly parts as well.
A few preliminaries that I've gotta get out of the way.
This is a highly opinionated talk.
This is not pure technical fact.
These are my opinions.
They are not those of my employer
or Kermit the Frog or Dr. Ruth Westheimer or anyone else.
The talk contains some criticism by nature
but I'm trying to be constructive here and I still love Java.
So this afternoon,
I'm gonna be giving a much longer talk
in which I discuss and critique every one of the 18 language changes
between Java 1.0 and Java 7.
It's chock full of code examples because this is a keynote.
A, it's short and B,
I tried to have no code at all.
I slipped and there's one example.
But what I'm gonna do, this kind of meshes with the talk
because this is about where it all started.
I'm gonna restrict my attention
to Java 1.0 basically the language as it originally shipped
and I'm gonna try to tell you what the good parts were,
what the bad parts were and in my opinion,
why it succeeded.
Both talks, this morning's and this afternoon's,
are limited in scope to the language
because I just don't have time to cover the libraries.
So first the good parts.
These ones on this slide are, I think, fairly well known.
Java has, it's a safe language with a managed run time.
And that means you got no seg faults, no scribble bugs,
none of the things that C and C ++ programmers coped with for so many years
and that also facilitates program portability
when you have this managed run time
because you are writing to a virtual machine
and that virtual machine of course can be implemented on various hardware,
various operating systems.
They also tightly specified all the primitive types in Java.
How long is an nth?
I don't know.
It depends on the underlying machine.
It could be 32 bits, could be 16 bits.
And that's a problem.
So I think once bitten twice shy.
James and the James Gang got that one right.
And that was, that was critical.
It's also a natural accompaniment to the managed run time
because you define all those types in the run time
and the run time acts as a buffer
between the realities of whatever hardware you're running on and the program.
Dynamic linking was very important.
Anyone who spent a lot of time programming in C or C + + knows that
when you change a library,
you have to recompile every single client program
which meant clean builds were essential.
And if you didn't do that,
you got strange bugs and you spent a week chasing them down.
So Java, by contrast,
loads the libraries dynamically and if you change the library,
you don't have to touch the clients.
Everything just works with one small
but important exception that I'll discuss later in the talk.
And finally I think a team basic attribute responsible for the success
of the Java language,
was its superficial syntactic similarity to C and C + +.
It didn't scare the C + + programmers and the C programmers.
In fact, they could take a look at a Java programmer and say ,
a Java program, I'm sorry.
And say, 'Yeah. I know what that does.'
They didn't have to read the language manual.
They didn't have to study. They just looked at it.
So in essence it was an act of subversion.
The Java language kind of snuck the essence of languages
like LISP and SMALL TALK by the people
who are used to programming languages like C and C + +.
And I think all of those things are important
and none of them should come as a surprise to you.
Now let's look at the type system.
It's object oriented which means two things.
It means it supports encapsulation and that was absolutely critical
because you cannot prove the correctness of components in isolation
unless the components can isolate their internals.
Then there's inheritance and that was a marketing necessity.
We could argue whether you really need implementation inheritance or not
but in 1995,
if you tried to introduce a new language that wasn't object oriented,
you would have been laughed off the face of the earth.
There's multiple interface inheritance which I think was a great idea.
The Java team basically looked at C + + and said,
'It's great to be able to support multiple protocols
but multiple implementation inheritance is too gnarly.
There's just too much difficulty that comes with it.'
So they kept the multiple interface inheritance
and discarded the multiple implementation inheritance.
And then there's static typing.
I know these days it's kind of popular to diss static typing but I think it was,
it was critical for a couple reasons.
The first reason is that it,
and there actually may be three reasons , amongst our weaponry,
it enables the IDE's to generate high quality code
with very little effort on your part.
Basically the auto completion says,
'Ah yes.
The type of this variable is such and such so these are the methods you can call.'
And that's great.
It was also necessary from a performance perspective especially in 1995,
if they tried to do a dynamically typed language,
they never could have achieved the sort of performance
in the sort of time frame that they did.
And then another reason it's important is that
in order to get big business to take the language seriously,
you know, they had to sort of be able to offer the kind of safety
that you get with static typing.
If you can compile it,
it is unlikely to have a certain class of bugs at run time.
What about random features?
Well, you've got threads.
Threads are critical.
So in 1995, it was the twilight of the uniprocessor era.
There weren't a lot of MP's for sale but the writing was on the wall.
But more importantly, computing had changed from the days
when you just had a big batch computation,
you fed it into the computer,
it did what it did.
Computers were being used with microphones and speakers
and all manner of sensors
and computer programs were talking to each other on the network.
So there you have concurrency
whether or not you have real parallelism with multi-, multi-processors.
You have concurrency and you need a language that can handle that concurrency.
And many people had tried to add threading to language that didn't have them.
P-threads and so forth and they found that it was fraught with peril.
And in fact, even as early as 1995,
academics were writing papers kind of proving that it could not be done
and Hans Boehm wrote another paper a decade later.
But I think if you talk to the concurrency elite,
they will tell you it's simply impossible to add threading to a language
after the fact.
So it was very fortunate that they decided to put threading into Java from Day One.
Garbage collection eliminates all the pain, heartache and bugs
associated with manual memory management
and then exceptions, error codes had been shown to be error prone.
If you look at C programs,
people tend to ignore the error codes
and the other thing is that when you do,
you don't have seg faults.
You're way down in the execution of a program.
Something bad happens.
You have to do something, so you throw in an exception.
And those were the key features.
It turns out that what you leave out can be as important as what you put in.
James left out a bunch of things that had been assumed critical.
Exhibit A is lexical macros.
If you look at a C program, it's all about macros.
But macros have problems especially lexical macros like C's.
And that decision turned out to be a great one.
First of all, it makes all Java programs somewhat similar to one another
which means I can take my program,
give it to you and you can debug it without having to learn all of my macros.
It enables programmer portability in that way
and also it's important for two ability,
we were talking about all the IDE's and IntelliJ and Eclipse
and Net beads and so forth.
Once you have macros,
it's really hard to do auto completion.
Multiple implementation inheritance was another thing
that it was kind of ballsy to leave out
and it turned out to be a great decision in retrospect.
And finally, operator overloading.
Operator overloading isn't inherently a bad thing
but untrammeled operator overloading, as practiced in C + +, is.
I mean as soon as you start using the left shift operator to do I/O,
your program loses a lot in the way of intelligibility.
And the Oak Team just decided they didn't want to do that.
Finally, I want to discuss a potent pair of design decisions
that are often overlooked.
First of all, Java omitted support for header files.
Header files in C and C + +, are kind of a nightmare
because you have to keep them in sync with the program.
They're in separate places and then they added Javadoc.
I think Javadoc is the unsung hero in all of this.
Javadoc takes the documentation and puts it with the code.
And everyone knows that it's sort of made good documentation
a part of the Java culture from Day One.
That's very important.
But here's the other thing it did.
Once you take those two design decisions together,
you've co-located the interface declaration,
its documentation and its implementation,
they're all together in one place.
Now if you change anything,
you're almost forced to change everything else.
So things do not go out of sync.
And I think that made Java a much better,
a much more productive
and a much more bug free language to program in.
So I think those are pretty much the main things that made Java succeed.
Now we're gonna get on to the bad and the ugly parts.
And in keeping with the Western theme of today's talk,
you can see that Duke there is holding a shootin' iron
and he appears to be shootin' off his own foot.
So these are the cases where he shot off his own foot.
First of all, we have silent widening conversions
from int to float and double to long.
So basically you can have a variable of type long
and if you try to store its contents in a double,
the language will say, 'Sure. No problem.'
But it's lost information.
That should generate probably an error or at least a warning at compile time.
It should require a cast.
So these are things that are supposed to be lost less but they aren't.
And then a related one.
This is the only code in this talk
but it turns out that these
what are called compound assignment operators
have implicit narrowing casts.
If you look at this code,
it looks like the loop should iterate sixteen times, right.
We put in something with sixteen ones and while we're not zero,
we shift it to the right once.
Bang, bang, bang. Knock off all 16 bits.
You're done. Right?
No. It's an infinite loop.
Why?
'Cause actually it turns into this.
It turns out the shorts turn into ints
and you just keep putting back negative one into that variable.
So that was a mistake.
The operators double equals and unequals are reference operators.
They should be value operators.
That is, they should call equals if it is a sign.
It was a mistake to take the nice syntax
and waste it on the thing that you rarely want to do
and it's a cause of frequent bugs for beginners.
They compare strings using double equals
and then they don't know why it doesn't work.
Now here's, remember when I said there's a chink in the armor
of dynamic linking of libraries.
If you have a constant variable like 'Public Static final field library'
that field's actually copied into the client
and if you forget to recompile the client,
you don't get the new value of that.
So that was a mistake, once again.
Lots of subtle bugs.
What about constructors?
Well, default constructors are bad.
You forget all about constructors and the compiler,
in its infinite wisdom and mercy,
gives you a public constructor.
What if you didn't want a constructor?
What if it's a static utility class
or what if you didn't want anybody to construct a copy of the thing?
You wanted to keep it private.
So that was a mistake.
And invoking overridden methods from constructors should be illegal
because it's always wrong.
Here's a bunch of miscellaneous things.
Lack of unsigned int and long was a big mistake.
And worse, bytes are signed.
When do you use bytes?
Byte manipulation, packing, packets on networks,
doing graphics or whatever.
The sign extension always gets in the way.
That code is buggy.
It's error prone.
It's filled with nasty end zero XF masks.
So that was a mistake.
The switch statement is not structured.
It has fall through.
Java is the newest language not to have fixed that particular error.
There was no good reason for that.
Arrays should have overridden two strings so that when you print an array,
you don't get garbage.
That's another one that nails every CS 101 student.
Exceptions, obliterate pending exceptions.
If you have exceptions on the stack and another exception is thrown,
you lose the first one.
That's bad and it wasn't necessary.
And finally, cloneable lacks a clone method ,
that makes no sense at all
and it shouldn't even exist in the first place.
Cloneable is a waste.
If you want to be able to create a clone,
just put a method or a constructor to do so.
So in summary, the good parts are the key design decisions.
The basics of a language James and his team got right.
The bad and the ugly parts are largely confined to the details.
A market window opened up in 1995 for a new language
because people were pretty much sick of the ones
that existed at the time and Java jumped through it.
Some people have said that this was all hype and marketing.
That's not true.
Java's success was the result of the Oak Team
making all of the right design decisions.
Well, not all of the right design decisions.
Most of the right design decisions.
And if you come back at 2:20,
I'll give you a much longer talk with a lot more code
discussing how we have built on this legacy over the past decade and a half.
And where we, where we did it proud and where we dishonored it.
Thank you very much.
[applause]
Peter Chen [endtext]
In my technical presentation ("The Evolution of Java: Past, Present, and Future"), I'll be discussing all of the changes to the Java programming language since its inception. In this this keynote, I'll focus my attention on the starting point: I'll present my candidates for the best and worst features in the platform as it was originally released (JDK 1.0), and explain the reasoning behind my choices. Some of my choices may be obvious, but others will likely surprise you. A splendid time is guaranteed for all.
Josh Bloch
The Text of the video :
Josh Bloch: These days people are writing a lot of books with titles like
'Javascript: The Good Part' and 'Java: The Good Parts'.
But I owe you more.
There's always the yin and the yang.
So I'm gonna give you the "full monty" today.
I am going to tell you about the bad and the ugly parts as well.
A few preliminaries that I've gotta get out of the way.
This is a highly opinionated talk.
This is not pure technical fact.
These are my opinions.
They are not those of my employer
or Kermit the Frog or Dr. Ruth Westheimer or anyone else.
The talk contains some criticism by nature
but I'm trying to be constructive here and I still love Java.
So this afternoon,
I'm gonna be giving a much longer talk
in which I discuss and critique every one of the 18 language changes
between Java 1.0 and Java 7.
It's chock full of code examples because this is a keynote.
A, it's short and B,
I tried to have no code at all.
I slipped and there's one example.
But what I'm gonna do, this kind of meshes with the talk
because this is about where it all started.
I'm gonna restrict my attention
to Java 1.0 basically the language as it originally shipped
and I'm gonna try to tell you what the good parts were,
what the bad parts were and in my opinion,
why it succeeded.
Both talks, this morning's and this afternoon's,
are limited in scope to the language
because I just don't have time to cover the libraries.
So first the good parts.
These ones on this slide are, I think, fairly well known.
Java has, it's a safe language with a managed run time.
And that means you got no seg faults, no scribble bugs,
none of the things that C and C ++ programmers coped with for so many years
and that also facilitates program portability
when you have this managed run time
because you are writing to a virtual machine
and that virtual machine of course can be implemented on various hardware,
various operating systems.
They also tightly specified all the primitive types in Java.
How long is an nth?
I don't know.
It depends on the underlying machine.
It could be 32 bits, could be 16 bits.
And that's a problem.
So I think once bitten twice shy.
James and the James Gang got that one right.
And that was, that was critical.
It's also a natural accompaniment to the managed run time
because you define all those types in the run time
and the run time acts as a buffer
between the realities of whatever hardware you're running on and the program.
Dynamic linking was very important.
Anyone who spent a lot of time programming in C or C + + knows that
when you change a library,
you have to recompile every single client program
which meant clean builds were essential.
And if you didn't do that,
you got strange bugs and you spent a week chasing them down.
So Java, by contrast,
loads the libraries dynamically and if you change the library,
you don't have to touch the clients.
Everything just works with one small
but important exception that I'll discuss later in the talk.
And finally I think a team basic attribute responsible for the success
of the Java language,
was its superficial syntactic similarity to C and C + +.
It didn't scare the C + + programmers and the C programmers.
In fact, they could take a look at a Java programmer and say ,
a Java program, I'm sorry.
And say, 'Yeah. I know what that does.'
They didn't have to read the language manual.
They didn't have to study. They just looked at it.
So in essence it was an act of subversion.
The Java language kind of snuck the essence of languages
like LISP and SMALL TALK by the people
who are used to programming languages like C and C + +.
And I think all of those things are important
and none of them should come as a surprise to you.
Now let's look at the type system.
It's object oriented which means two things.
It means it supports encapsulation and that was absolutely critical
because you cannot prove the correctness of components in isolation
unless the components can isolate their internals.
Then there's inheritance and that was a marketing necessity.
We could argue whether you really need implementation inheritance or not
but in 1995,
if you tried to introduce a new language that wasn't object oriented,
you would have been laughed off the face of the earth.
There's multiple interface inheritance which I think was a great idea.
The Java team basically looked at C + + and said,
'It's great to be able to support multiple protocols
but multiple implementation inheritance is too gnarly.
There's just too much difficulty that comes with it.'
So they kept the multiple interface inheritance
and discarded the multiple implementation inheritance.
And then there's static typing.
I know these days it's kind of popular to diss static typing but I think it was,
it was critical for a couple reasons.
The first reason is that it,
and there actually may be three reasons , amongst our weaponry,
it enables the IDE's to generate high quality code
with very little effort on your part.
Basically the auto completion says,
'Ah yes.
The type of this variable is such and such so these are the methods you can call.'
And that's great.
It was also necessary from a performance perspective especially in 1995,
if they tried to do a dynamically typed language,
they never could have achieved the sort of performance
in the sort of time frame that they did.
And then another reason it's important is that
in order to get big business to take the language seriously,
you know, they had to sort of be able to offer the kind of safety
that you get with static typing.
If you can compile it,
it is unlikely to have a certain class of bugs at run time.
What about random features?
Well, you've got threads.
Threads are critical.
So in 1995, it was the twilight of the uniprocessor era.
There weren't a lot of MP's for sale but the writing was on the wall.
But more importantly, computing had changed from the days
when you just had a big batch computation,
you fed it into the computer,
it did what it did.
Computers were being used with microphones and speakers
and all manner of sensors
and computer programs were talking to each other on the network.
So there you have concurrency
whether or not you have real parallelism with multi-, multi-processors.
You have concurrency and you need a language that can handle that concurrency.
And many people had tried to add threading to language that didn't have them.
P-threads and so forth and they found that it was fraught with peril.
And in fact, even as early as 1995,
academics were writing papers kind of proving that it could not be done
and Hans Boehm wrote another paper a decade later.
But I think if you talk to the concurrency elite,
they will tell you it's simply impossible to add threading to a language
after the fact.
So it was very fortunate that they decided to put threading into Java from Day One.
Garbage collection eliminates all the pain, heartache and bugs
associated with manual memory management
and then exceptions, error codes had been shown to be error prone.
If you look at C programs,
people tend to ignore the error codes
and the other thing is that when you do,
you don't have seg faults.
You're way down in the execution of a program.
Something bad happens.
You have to do something, so you throw in an exception.
And those were the key features.
It turns out that what you leave out can be as important as what you put in.
James left out a bunch of things that had been assumed critical.
Exhibit A is lexical macros.
If you look at a C program, it's all about macros.
But macros have problems especially lexical macros like C's.
And that decision turned out to be a great one.
First of all, it makes all Java programs somewhat similar to one another
which means I can take my program,
give it to you and you can debug it without having to learn all of my macros.
It enables programmer portability in that way
and also it's important for two ability,
we were talking about all the IDE's and IntelliJ and Eclipse
and Net beads and so forth.
Once you have macros,
it's really hard to do auto completion.
Multiple implementation inheritance was another thing
that it was kind of ballsy to leave out
and it turned out to be a great decision in retrospect.
And finally, operator overloading.
Operator overloading isn't inherently a bad thing
but untrammeled operator overloading, as practiced in C + +, is.
I mean as soon as you start using the left shift operator to do I/O,
your program loses a lot in the way of intelligibility.
And the Oak Team just decided they didn't want to do that.
Finally, I want to discuss a potent pair of design decisions
that are often overlooked.
First of all, Java omitted support for header files.
Header files in C and C + +, are kind of a nightmare
because you have to keep them in sync with the program.
They're in separate places and then they added Javadoc.
I think Javadoc is the unsung hero in all of this.
Javadoc takes the documentation and puts it with the code.
And everyone knows that it's sort of made good documentation
a part of the Java culture from Day One.
That's very important.
But here's the other thing it did.
Once you take those two design decisions together,
you've co-located the interface declaration,
its documentation and its implementation,
they're all together in one place.
Now if you change anything,
you're almost forced to change everything else.
So things do not go out of sync.
And I think that made Java a much better,
a much more productive
and a much more bug free language to program in.
So I think those are pretty much the main things that made Java succeed.
Now we're gonna get on to the bad and the ugly parts.
And in keeping with the Western theme of today's talk,
you can see that Duke there is holding a shootin' iron
and he appears to be shootin' off his own foot.
So these are the cases where he shot off his own foot.
First of all, we have silent widening conversions
from int to float and double to long.
So basically you can have a variable of type long
and if you try to store its contents in a double,
the language will say, 'Sure. No problem.'
But it's lost information.
That should generate probably an error or at least a warning at compile time.
It should require a cast.
So these are things that are supposed to be lost less but they aren't.
And then a related one.
This is the only code in this talk
but it turns out that these
what are called compound assignment operators
have implicit narrowing casts.
If you look at this code,
it looks like the loop should iterate sixteen times, right.
We put in something with sixteen ones and while we're not zero,
we shift it to the right once.
Bang, bang, bang. Knock off all 16 bits.
You're done. Right?
No. It's an infinite loop.
Why?
'Cause actually it turns into this.
It turns out the shorts turn into ints
and you just keep putting back negative one into that variable.
So that was a mistake.
The operators double equals and unequals are reference operators.
They should be value operators.
That is, they should call equals if it is a sign.
It was a mistake to take the nice syntax
and waste it on the thing that you rarely want to do
and it's a cause of frequent bugs for beginners.
They compare strings using double equals
and then they don't know why it doesn't work.
Now here's, remember when I said there's a chink in the armor
of dynamic linking of libraries.
If you have a constant variable like 'Public Static final field library'
that field's actually copied into the client
and if you forget to recompile the client,
you don't get the new value of that.
So that was a mistake, once again.
Lots of subtle bugs.
What about constructors?
Well, default constructors are bad.
You forget all about constructors and the compiler,
in its infinite wisdom and mercy,
gives you a public constructor.
What if you didn't want a constructor?
What if it's a static utility class
or what if you didn't want anybody to construct a copy of the thing?
You wanted to keep it private.
So that was a mistake.
And invoking overridden methods from constructors should be illegal
because it's always wrong.
Here's a bunch of miscellaneous things.
Lack of unsigned int and long was a big mistake.
And worse, bytes are signed.
When do you use bytes?
Byte manipulation, packing, packets on networks,
doing graphics or whatever.
The sign extension always gets in the way.
That code is buggy.
It's error prone.
It's filled with nasty end zero XF masks.
So that was a mistake.
The switch statement is not structured.
It has fall through.
Java is the newest language not to have fixed that particular error.
There was no good reason for that.
Arrays should have overridden two strings so that when you print an array,
you don't get garbage.
That's another one that nails every CS 101 student.
Exceptions, obliterate pending exceptions.
If you have exceptions on the stack and another exception is thrown,
you lose the first one.
That's bad and it wasn't necessary.
And finally, cloneable lacks a clone method ,
that makes no sense at all
and it shouldn't even exist in the first place.
Cloneable is a waste.
If you want to be able to create a clone,
just put a method or a constructor to do so.
So in summary, the good parts are the key design decisions.
The basics of a language James and his team got right.
The bad and the ugly parts are largely confined to the details.
A market window opened up in 1995 for a new language
because people were pretty much sick of the ones
that existed at the time and Java jumped through it.
Some people have said that this was all hype and marketing.
That's not true.
Java's success was the result of the Oak Team
making all of the right design decisions.
Well, not all of the right design decisions.
Most of the right design decisions.
And if you come back at 2:20,
I'll give you a much longer talk with a lot more code
discussing how we have built on this legacy over the past decade and a half.
And where we, where we did it proud and where we dishonored it.
Thank you very much.
[applause]
Peter Chen [endtext]
Java: The Good, Bad, and Ugly Parts | The Evolution of Java: Past, Present, and Future -
Libellés :
JAVA
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/how-to-build-html5-css3-fully.html
[/postlink]
http://www.youtube.com/watch?v=eOG90Q8EfRoendofvid [starttext]This is a Video Tutorial shows How to build an HTML5 / CSS3 fully-responsive layout?
In this tutorial I will teach you how to create a responsive website using HTML5/CSS3 from scratch. So rather than talking about, let's get straight to it. I hope you will leave me feedback in as I would like to get hear some of your opinions very, very much! [endtext]
In this tutorial I will teach you how to create a responsive website using HTML5/CSS3 from scratch. So rather than talking about, let's get straight to it. I hope you will leave me feedback in as I would like to get hear some of your opinions very, very much! [endtext]
How to build an HTML5 / CSS3 fully-responsive layout ? | HTML5 & CSS3 Video Tutorial
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/how-to-create-html5-css3-website.html
[/postlink]
http://www.youtube.com/watch?v=2iCzH7UXE1Uendofvid [starttext]This is a Video Tutorial shows how to create a CSS3 and HTML5 based web template or a simple website layout.
Part2
[endtext]
Part2
[endtext]
How to Create HTML5 & CSS3 & Website template or Layout Video Tutorial -
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/what-you-need-to-know-about-html5-html5.html
[/postlink]
http://www.youtube.com/watch?v=mFmBqCzKenkendofvid [starttext]This is a Video Tutorial shows What you need to know about HTML5 ?
To coincide with the release of our multi-device planning guide, we also ran a very popular free webinar which looked at:
•The fundamental features of HTML5
•The top reasons why your organization should consider HTML5
•Progressive information on the HTML5 timeline
•Evaluating which authoring tools output to HTML5 & which browsers support HTML5
•Creative tips for converting your legacy content
•Why your organization should consider a responsive design framework
Contact us to find out more about our Adapt framework and how we can help bring multi-device learning into your organisation, and download the planning guide here from our website here: http://www.kineo.com/elearning-report... [endtext]
To coincide with the release of our multi-device planning guide, we also ran a very popular free webinar which looked at:
•The fundamental features of HTML5
•The top reasons why your organization should consider HTML5
•Progressive information on the HTML5 timeline
•Evaluating which authoring tools output to HTML5 & which browsers support HTML5
•Creative tips for converting your legacy content
•Why your organization should consider a responsive design framework
Contact us to find out more about our Adapt framework and how we can help bring multi-device learning into your organisation, and download the planning guide here from our website here: http://www.kineo.com/elearning-report... [endtext]
What you need to know about HTML5 ? | HTML5 Video Tutorial -
Libellés :
HTML5
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/url-mapping-in-j2ee-spring-mvc.html
[/postlink]
http://www.youtube.com/watch?v=Q6hZQ5SzGyMendofvid [starttext]This is a Video Tutorial shows URL Mapping in J2EE Spring MVC Framework using Netbeans Platform [endtext]
URL Mapping in J2EE Spring MVC Framework using Netbeans Platform | Spring MVC Video Tutorial -
Libellés :
Netbeans
,
Spring MVC
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/webinar-complete-introduction-to.html
[/postlink]
http://www.youtube.com/watch?v=pxsjfB7IKVsendofvid [starttext]This is a Video Tutorial shows a complete introduction to the ICEfaces framework, and discuss its features and benefits. This presentation will explain how ICEfaces extends JSF 2.0 with market leading technology concepts such as Ajax Push, Direct-to-DOM, and Automatic Ajax that will greatly reduce application development complexity and increase developer productivity. The ICEfaces JSF components will also be reviewed and demonstrated. [endtext]
Webinar | Complete introduction to the ICEfaces framework | Features and Benefits | How ICEfaces extends JSF 2.0 | Icefaces Video Tutorial
Libellés :
(Java Server Faces) JSF
,
Ajax
,
Icefaces
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/introduction-to-java-hibernate-famework.html
[/postlink]
http://www.youtube.com/watch?v=j-tEonLmyBkendofvid [starttext]This is a Video Tutorial shows
Get started with JAVA Hibernate
Hibernate simple example:-
Now to start with Hibernate and practice my video you will need to have the following
1. Any relational database I am using Oracle XE 10g(you can use the one of your choice)
2. Java IDE the one I am using is eclipse indigo
3. Hibernate 3.5.6 final version which you can download from http://en.sourceforge.jp/projects/sfn...
4. Now you also need to have few extra jars so for you to avoid going searching them I kept all the jar files that you have to use in one zip : http://www.4shared.com/zip/UZil3Sx9/h...
In my video I have given a simple example and explained it in detail which will help us to understand the hibernate framework concepts in easy understandable way .Also start with hibernate Framework.
In the Example which i will be explaining in the video I have a table Employee table in my Oracle Database as ID EName Mobile Email
And I will write a program to insert a record in this table. What we will be doing here is ,hibernate by definition is an ORM model that is object relation model , and thus we will map our table to a POJO class.Now what is a POJO class.A bean class without events is called a POJO class. You will understand this better once you see the video tutorial below.
[endtext]
Get started with JAVA Hibernate
Hibernate simple example:-
Now to start with Hibernate and practice my video you will need to have the following
1. Any relational database I am using Oracle XE 10g(you can use the one of your choice)
2. Java IDE the one I am using is eclipse indigo
3. Hibernate 3.5.6 final version which you can download from http://en.sourceforge.jp/projects/sfn...
4. Now you also need to have few extra jars so for you to avoid going searching them I kept all the jar files that you have to use in one zip : http://www.4shared.com/zip/UZil3Sx9/h...
In my video I have given a simple example and explained it in detail which will help us to understand the hibernate framework concepts in easy understandable way .Also start with hibernate Framework.
In the Example which i will be explaining in the video I have a table Employee table in my Oracle Database as ID EName Mobile Email
And I will write a program to insert a record in this table. What we will be doing here is ,hibernate by definition is an ORM model that is object relation model , and thus we will map our table to a POJO class.Now what is a POJO class.A bean class without events is called a POJO class. You will understand this better once you see the video tutorial below.
[endtext]
Introduction to Java Hibernate Famework Tutorial For Beginners | Hibernate 3.5.6 Video Tutorial
Libellés :
Hibernate
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/how-to-protect-java-ee-web-apps-with.html
[/postlink]
http://www.youtube.com/watch?v=zaY4p7SwcIwendofvid [starttext]This is a Video Tutorial shows How to protect Java EE Web Apps with Secure HTTP Headers
Frank Kim presents this JavaOne 2012 session. To address security defects, developers typically resort to fixing architectural issues and security bugs directly in the code. Finding and fixing security defects can be a slow, painstaking, and expensive process. While development teams work to incorporate security into their development processes, issues such as clickjacking, cross-site scripting (XSS), and session hijacking continue to plague many commonly used applications. In this session, Java developers and architects will see how these vulnerabilities actually work and how real companies have dealt with these issues. They will go on to learn how to use the latest secure HTTP headers to proactively prevent attacks from occurring and stop hackers from exploiting their applications. [endtext]
Frank Kim presents this JavaOne 2012 session. To address security defects, developers typically resort to fixing architectural issues and security bugs directly in the code. Finding and fixing security defects can be a slow, painstaking, and expensive process. While development teams work to incorporate security into their development processes, issues such as clickjacking, cross-site scripting (XSS), and session hijacking continue to plague many commonly used applications. In this session, Java developers and architects will see how these vulnerabilities actually work and how real companies have dealt with these issues. They will go on to learn how to use the latest secure HTTP headers to proactively prevent attacks from occurring and stop hackers from exploiting their applications. [endtext]
How to protect Java EE Web Apps with Secure HTTP Headers | Java Secuity Video Tutorial
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/java-security-ignition-java-security.html
[/postlink]
http://www.youtube.com/watch?v=mo5N4SIi-UIendofvid [starttext]This is a Video Tutorial shows Java Security & Ignition [endtext]
Java Security & Ignition | Java Security Video Tutorial
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/java-security-video-tutorial-secure.html
[/postlink]
http://www.youtube.com/watch?v=08gdSEeeiS4endofvid [starttext]This is a Video Tutorial shows Secure Coding Guidelines for the Java Programming Language
"Java comes with its own unique set of security challenges. Although the Java security architecture can protect users and systems from hostile programs downloaded over a network, it cannot defend against implementation bugs that occur in trusted code.
"Secure Coding Guidelines for the Java Programming Language" helps keep Java safe and prevent attackers from using these bugs to take over control. This presentation offers an overview of the guidelines, bundled with understandable real-life examples." [endtext]
"Java comes with its own unique set of security challenges. Although the Java security architecture can protect users and systems from hostile programs downloaded over a network, it cannot defend against implementation bugs that occur in trusted code.
"Secure Coding Guidelines for the Java Programming Language" helps keep Java safe and prevent attackers from using these bugs to take over control. This presentation offers an overview of the guidelines, bundled with understandable real-life examples." [endtext]
Java Security Video Tutorial | Secure Coding Guidelines for the Java Programming Language |
[postlink]
https://j2ee-tutorials-videos.blogspot.com/2013/05/how-to-apply-spring-security-to.html
[/postlink]
http://www.youtube.com/watch?v=k32KqrckLEEendofvid [starttext]This is a Video Tutorial shows how to apply Spring Security to an existing application to demonstrate how it can meet your authentication and authorization needs.
Spring Security is a framework that focuses on providing both authentication and authorization to Java applications. Like all Spring projects, the real power of Spring Security is found in how easily it can be extended to meet custom requirements. In this presentation Rob will incrementally apply Spring Security to an existing application to demonstrate how it can meet your authentication and authorization needs. It will also answer many of the common "how to" questions that are found on the forums. This will ensure that you can not only secure your application quickly, but ensure you understand Spring Security well enough to extend it to meet your custom requirements.
Get the code!
https://github.com/rwinch/getting-started-springsecurity-31
[endtext]
Spring Security is a framework that focuses on providing both authentication and authorization to Java applications. Like all Spring projects, the real power of Spring Security is found in how easily it can be extended to meet custom requirements. In this presentation Rob will incrementally apply Spring Security to an existing application to demonstrate how it can meet your authentication and authorization needs. It will also answer many of the common "how to" questions that are found on the forums. This will ensure that you can not only secure your application quickly, but ensure you understand Spring Security well enough to extend it to meet your custom requirements.
Get the code!
https://github.com/rwinch/getting-started-springsecurity-31
[endtext]
How to apply Spring Security to an existing application to demonstrate how it can meet your authentication and authorization needs | Spring Security Video Tutorial
Libellés :
Spring Security
Subscribe to:
Posts
(
Atom
)
Eclipse
(Java Server Faces) JSF
Spring
Hibernate
JAVA
Netbeans
GWT ( Google Web Toolkit )
JAVA EE 6
Tomcat
Java Persistence API (JPA)
EJB
Primefaces
Android
Web Service
GlassFish
Maven
Servlet
CDI (Contexts and Dependency Injection)
Struts
JSP
MySQL
Red5
JAVA 7
Java EE Video Programming
JDBC
Intoduction to J2EE
Spring MVC
JEE5
HTML5
Spring AOP ( Spring Aspect Oriented Programming concepts )
Spring Security
RESTful
C2DM
Google App Engine
PostgreSQL
Security
Cloud To Device Messaging
Spring Data Support (JDBC ORM Transactions)
Ehcache
Icefaces
HTML
JSTL
JUnit
Axis
Packaging and Deploying J2EE Application
Top Link
HttpSession
Log4J
Search Engine
Session
Java RMI ( Remote Method Invocation )
Oracle JDeveloper
SSL
SVN
XML
i18n
HTTPS
You can see also
J2EE is an acronym for Java 2 Enterprise Edition. The Java 2 Enterprise Edition is Software that can be used along with the J2SE, the Java 2 Standard Edition which includes the compiler and the other fundamentals of Java. The J2EE software includes development and deployment systems for Java Servlet and Java ServerPages. Both of these combine Java and HTML to produce web pages on demand. Author Mohamed Habou . understand this powerful component of Java programming.
