Java servlet on browsers: dying or kicking ?

Discussion in 'Java' started by SL@maxis, Dec 24, 2012.

  1. SL@maxis

    SL@maxis Guest

    What is the current state of java servlet support by major browsers ?

    Is it a dying technology or still alive and kicking ?

    Thanks.

    --
    Using Opera's revolutionary email client: http://www.opera.com/mail/
     
    SL@maxis, Dec 24, 2012
    #1
    1. Advertising

  2. SL@maxis

    Arne Vajhøj Guest

    On 12/24/2012 12:04 PM, SL@maxis wrote:
    > What is the current state of java servlet support by major browsers ?
    >
    > Is it a dying technology or still alive and kicking ?


    Servlets is server side technology and therefore "supported"
    by all browsers.

    If you mean applets, then I believe that all modern
    PC browsers support it, but that smartphone browsers
    do not support it.

    (applet support = Java plugin available)

    Java applets are definitely not in fashion. RIA
    are typical done with Flash/Flex or HTML/CSS/JS/AJAX
    today.

    Java applets are still used occasionally, because the
    ability to sign them and give them client PC access are
    useful/necessary in some contexts.

    Some internet usage and a lot of intranet usage.

    Arne
     
    Arne Vajhøj, Dec 24, 2012
    #2
    1. Advertising

  3. SL@maxis

    Lew Guest

    SL@maxis wrote:
    > What is the current state of java [sic] servlet support by major browsers ?


    No browser supports servlets.

    > Is it a dying technology or still alive and kicking ?


    Very much still kicking.

    --
    Lew
     
    Lew, Dec 24, 2012
    #3
  4. SL@maxis

    SL@maxis Guest

    On Tue, 25 Dec 2012 01:37:38 +0800, Arne Vajhøj <> wrote:

    >
    > Servlets is server side technology and therefore "supported"
    > by all browsers.
    >
    > If you mean applets, then I believe that all modern
    > PC browsers support it, but that smartphone browsers
    > do not support it.
    >
    > (applet support = Java plugin available)
    >
    > Java applets are definitely not in fashion. RIA
    > are typical done with Flash/Flex or HTML/CSS/JS/AJAX
    > today.
    >
    > Java applets are still used occasionally, because the
    > ability to sign them and give them client PC access are
    > useful/necessary in some contexts.
    >
    > Some internet usage and a lot of intranet usage.
    >


    Ha, my mistake; "servlet" should actually be "applet". Thanks for
    correcting me.

    --
    Using Opera's revolutionary email client: http://www.opera.com/mail/
     
    SL@maxis, Dec 24, 2012
    #4
  5. On 24.12.2012 20:06, Lew wrote:
    > SL@maxis wrote:


    >> Is it a dying technology or still alive and kicking ?

    >
    > Very much still kicking.


    Which one? Browsers, servlets or applets? ;-)

    Cheers

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Dec 24, 2012
    #5
  6. SL@maxis

    Eric Sosman Guest

    On 12/24/2012 5:33 PM, Robert Klemme wrote:
    > On 24.12.2012 20:06, Lew wrote:
    >> SL@maxis wrote:

    >
    >>> Is it a dying technology or still alive and kicking ?

    >>
    >> Very much still kicking.

    >
    > Which one? Browsers, servlets or applets? ;-)


    Kicklets. They still have the ballslets to fight for
    their rightslets, defending their nichelets against all
    threatlets, patriotically emptying their wallets and spilling
    their platelets.

    Happy holidayslets to you.

    --
    Eric Sosman
    d
     
    Eric Sosman, Dec 24, 2012
    #6
  7. On 12/25/2012 12:15 AM, Eric Sosman wrote:
    > On 12/24/2012 5:33 PM, Robert Klemme wrote:
    >> On 24.12.2012 20:06, Lew wrote:
    >>> SL@maxis wrote:

    >>
    >>>> Is it a dying technology or still alive and kicking ?
    >>>
    >>> Very much still kicking.

    >>
    >> Which one? Browsers, servlets or applets? ;-)

    >
    > Kicklets. They still have the ballslets to fight for
    > their rightslets, defending their nichelets against all
    > threatlets, patriotically emptying their wallets and spilling
    > their platelets.
    >
    > Happy holidayslets to you.


    Eric, thanks for making my day! *chuckle*

    All the best

    robert
     
    Robert Klemme, Dec 25, 2012
    #7
  8. SL@maxis

    Lew Guest

    Robert Klemme wrote:
    > Lew wrote:
    >> SL@maxis wrote:
    >>> Is it a dying technology or still alive and kicking ?

    >
    >> Very much still kicking.

    >
    > Which one? Browsers, servlets or applets? ;-)


    I took the antecedent to be servlets, I assume they already know the
    answer to browsers, and since then I've seen that they actually meant
    applets.

    --
    Lew
     
    Lew, Dec 25, 2012
    #8
  9. In article <op.wpt8ogiewv4027@kiat-1>,
    "SL@maxis" <> wrote:

    > On Tue, 25 Dec 2012 01:37:38 +0800, Arne Vajhøj <> wrote:
    >
    > >
    > > Servlets is server side technology and therefore "supported"
    > > by all browsers.
    > >
    > > If you mean applets, then I believe that all modern
    > > PC browsers support it, but that smartphone browsers
    > > do not support it.
    > >
    > > (applet support = Java plugin available)
    > >
    > > Java applets are definitely not in fashion. RIA
    > > are typical done with Flash/Flex or HTML/CSS/JS/AJAX
    > > today.
    > >
    > > Java applets are still used occasionally, because the
    > > ability to sign them and give them client PC access are
    > > useful/necessary in some contexts.
    > >
    > > Some internet usage and a lot of intranet usage.
    > >

    >
    > Ha, my mistake; "servlet" should actually be "applet". Thanks for
    > correcting me.


    Definitely in decline. HTML 5 + WebSockets can make fully interactive
    applications that look and feel native. The improvements are so great
    that the dreaded workflow and business logic tier can be moved from the
    server side to the client side. Moving that tier to the client takes a
    HUGE load off the server, making the server a pure number cruncher and
    data service.

    Some Servlet engines have WebSocket support built in. Jetty converts
    the protocol upgrade request into a servlet call for a WebSocket
    handler. Adding WebSocket support is not much different from adding a
    new method handler to your servlet. Your WebSocket then sends and
    receives messages to communicate with the client.

    I still shudder when recalling my time writing applets. Sun's attempts
    at making GUI APIs is the stuff nightmares are made of. It made me
    nostalgic for C++ GUIs that abused polymorphism to extremes.
    --
    I will not see posts from Google because I must filter them as spam
     
    Kevin McMurtrie, Dec 27, 2012
    #9
  10. SL@maxis

    Arne Vajhøj Guest

    On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
    > In article <op.wpt8ogiewv4027@kiat-1>,
    > "SL@maxis" <> wrote:
    >> Ha, my mistake; "servlet" should actually be "applet". Thanks for
    >> correcting me.

    >
    > Definitely in decline. HTML 5 + WebSockets can make fully interactive
    > applications that look and feel native.


    The decline is not caused by HTML 5 and websockets. It happen
    many years before those showed up.

    And there are still 40-50% of PC browsers that do not support
    websockets (primarily IE < 10).

    Arne
     
    Arne Vajhøj, Dec 28, 2012
    #10
  11. SL@maxis

    Arne Vajhøj Guest

    On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
    > In article <op.wpt8ogiewv4027@kiat-1>,
    >> Ha, my mistake; "servlet" should actually be "applet". Thanks for
    >> correcting me.

    >
    > Definitely in decline. HTML 5 + WebSockets can make fully interactive
    > applications that look and feel native. The improvements are so great
    > that the dreaded workflow and business logic tier can be moved from the
    > server side to the client side. Moving that tier to the client takes a
    > HUGE load off the server, making the server a pure number cruncher and
    > data service.


    Business logic should not be put in client side JS.

    Client side JS can be manipulated by the user.

    Arne
     
    Arne Vajhøj, Dec 28, 2012
    #11
  12. On Thu, 27 Dec 2012 21:07:02 -0500, Arne Vajhøj <>
    wrote:

    >On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
    >> In article <op.wpt8ogiewv4027@kiat-1>,
    >>> Ha, my mistake; "servlet" should actually be "applet". Thanks for
    >>> correcting me.

    >>
    >> Definitely in decline. HTML 5 + WebSockets can make fully interactive
    >> applications that look and feel native. The improvements are so great
    >> that the dreaded workflow and business logic tier can be moved from the
    >> server side to the client side. Moving that tier to the client takes a
    >> HUGE load off the server, making the server a pure number cruncher and
    >> data service.

    >
    >Business logic should not be put in client side JS.


    I disagree. Client-side logic makes for quicker UI response.

    >Client side JS can be manipulated by the user.


    But since this is also true, put the logic in the server side,
    too.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Dec 28, 2012
    #12
  13. In article <50dcfecc$0$292$>,
    Arne Vajhøj <> wrote:

    > On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
    > > In article <op.wpt8ogiewv4027@kiat-1>,
    > >> Ha, my mistake; "servlet" should actually be "applet". Thanks for
    > >> correcting me.

    > >
    > > Definitely in decline. HTML 5 + WebSockets can make fully interactive
    > > applications that look and feel native. The improvements are so great
    > > that the dreaded workflow and business logic tier can be moved from the
    > > server side to the client side. Moving that tier to the client takes a
    > > HUGE load off the server, making the server a pure number cruncher and
    > > data service.

    >
    > Business logic should not be put in client side JS.
    >
    > Client side JS can be manipulated by the user.
    >
    > Arne


    Some of the most difficult business logic is creating the workflow that
    defines a smoothly operating online product. It's a complex process of
    analyzing where you've been, what you chose to do, what data you have,
    what operations are available, and then offering meaningful solutions to
    reaching the next step. That used to be sprinkled all over the client
    and server sides, making it difficult to maintain. Now much of that can
    now go in the JavaScript layer.

    Business logic related to security and data integrity remains on the
    server. What's gone is the hand-holding steps to recovery when
    integrity would be violated. Now it's just a 4xx status code.
    --
    I will not see posts from Google because I must filter them as spam
     
    Kevin McMurtrie, Dec 28, 2012
    #13
  14. SL@maxis

    Arne Vajhøj Guest

    On 12/28/2012 12:13 AM, Gene Wirchenko wrote:
    > On Thu, 27 Dec 2012 21:07:02 -0500, Arne Vajhøj <>
    > wrote:
    >> On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
    >>> In article <op.wpt8ogiewv4027@kiat-1>,
    >>>> Ha, my mistake; "servlet" should actually be "applet". Thanks for
    >>>> correcting me.
    >>>
    >>> Definitely in decline. HTML 5 + WebSockets can make fully interactive
    >>> applications that look and feel native. The improvements are so great
    >>> that the dreaded workflow and business logic tier can be moved from the
    >>> server side to the client side. Moving that tier to the client takes a
    >>> HUGE load off the server, making the server a pure number cruncher and
    >>> data service.

    >>
    >> Business logic should not be put in client side JS.

    >
    > I disagree. Client-side logic makes for quicker UI response.


    I don't think there is much point in having business logic that is
    not enforced.

    And client side logic can not be enforced in a web solution.

    >> Client side JS can be manipulated by the user.

    >
    > But since this is also true, put the logic in the server side,
    > too.


    I don't think there is much point in implementing all the business
    logic twice - server side in Java and client side in JavaScript. That
    would be an awfully waste of money.

    But I think I know what you are thinking about. You are talking about
    data input validation.

    There are good reasons to do that both client side (for smooth UX) and
    server side (for security).

    But the overlap between data input validation and business logic
    is pretty small. Most business logic is not data input validation.
    And a big chunk of data input validation is really UI and not
    business logic.

    Arne
     
    Arne Vajhøj, Dec 28, 2012
    #14
  15. SL@maxis

    Arne Vajhøj Guest

    On 12/28/2012 3:41 AM, Kevin McMurtrie wrote:
    > In article <50dcfecc$0$292$>,
    > Arne Vajhøj <> wrote:
    >> On 12/27/2012 2:20 AM, Kevin McMurtrie wrote:
    >>> In article <op.wpt8ogiewv4027@kiat-1>,
    >>>> Ha, my mistake; "servlet" should actually be "applet". Thanks for
    >>>> correcting me.
    >>>
    >>> Definitely in decline. HTML 5 + WebSockets can make fully interactive
    >>> applications that look and feel native. The improvements are so great
    >>> that the dreaded workflow and business logic tier can be moved from the
    >>> server side to the client side. Moving that tier to the client takes a
    >>> HUGE load off the server, making the server a pure number cruncher and
    >>> data service.

    >>
    >> Business logic should not be put in client side JS.
    >>
    >> Client side JS can be manipulated by the user.

    >
    > Some of the most difficult business logic is creating the workflow that
    > defines a smoothly operating online product. It's a complex process of
    > analyzing where you've been, what you chose to do, what data you have,
    > what operations are available, and then offering meaningful solutions to
    > reaching the next step. That used to be sprinkled all over the client
    > and server sides, making it difficult to maintain. Now much of that can
    > now go in the JavaScript layer.
    >
    > Business logic related to security and data integrity remains on the
    > server. What's gone is the hand-holding steps to recovery when
    > integrity would be violated. Now it's just a 4xx status code.


    It is certainly possible to move the flow logic (success go to
    this page, error 1 go to another page, error 2 go to yet another
    page - all the Struts 1 action-mappings !) to client side
    JavaScript.

    But I must admit that I do not consider that business logic.

    IMHO that is pure UI. I consider heavy AJAX to move the UI layer
    from server tier to client tier and replace it in server tier with
    a service layer.

    Arne
     
    Arne Vajhøj, Dec 28, 2012
    #15
  16. On Fri, 28 Dec 2012 11:07:31 -0500, Arne Vajhøj <>
    wrote:

    [snip]

    >I don't think there is much point in implementing all the business
    >logic twice - server side in Java and client side in JavaScript. That
    >would be an awfully waste of money.
    >
    >But I think I know what you are thinking about. You are talking about
    >data input validation.


    Exactly.

    >There are good reasons to do that both client side (for smooth UX) and
    >server side (for security).


    Exactly my point.

    >But the overlap between data input validation and business logic
    >is pretty small. Most business logic is not data input validation.
    >And a big chunk of data input validation is really UI and not
    >business logic.


    True. I am tired of Web pages that could catch entry errors, but
    do not until I have finished a whole page. It seems that a lot of
    people ignore putting any validation in the front-end. I would like
    people to think of putting code in both places.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Dec 28, 2012
    #16
  17. On 28.12.2012 18:50, lipska the kat wrote:

    > I spend much of my working life translating a clients business processes
    > into something that can run on a computer and the trend is now more than
    > ever away from a strictly web based process and towards systems that are
    > completely independent of delivery mechanism.
    >
    > So, where as a few years ago we had 'we gotta have a web site because
    > our competitors have a web site' now we have 'we need a system that can
    > implement our business and deliver our business value over multiple
    > communication channels'
    >
    > So as well as a web site we often provide one or more of, a mobile
    > interface, a social media interface delivering targeted updates to the
    > likes of twitter, farcebook etc. an XML RSS feed, an interactive XML
    > based catalogue and recently a way of delivering business value via web
    > TV. We also provide interfaces to existing legacy systems and machine
    > interfaces to allow JIT supplier order fullfilment, shop floor intranet
    > access via hand held devices, POS systems etc etc. Only last week I was
    > asked about a 'Virtual Worlds' interface, Second Life and suchlike. I
    > had a second life account for a while but got so absorbed that I started
    > to neglect my earthly one :-(
    >
    > I try to design our systems to be completely isolated from both
    > persistence mechanism and delivery mechanism
    >
    > What I inevitably end up with is a slightly less that perfect decoupling
    > but I like to think that eventually, given the appearance of a truly
    > scalable way to persist entire Object trees I will be able to produce a
    > business system that will be completely decoupled from earthly
    > considerations like UI and database


    This sounds exactly like the use case JEE was intended for. Your
    business logic sits in session beans, your state is made persistent with
    JPA whatever backend is used (mostly RDBMS though) and you can interface
    to legacy systems with JCA. Transaction control across these layers is
    available in most modern JEE containers. Most of them let you create a
    web UI with JSF or other modern technologies. Usually you can also
    expose session beans as Web Services as well with relatively low effort.
    JASS handles authentication and can interface with various backends
    (LDAP, AD...).

    In practice of course this is pretty complicated and architecting such
    an application and setting it up has quite some overhead. But if you
    have it set up you have a nice separation of concerns.

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Dec 28, 2012
    #17
  18. On 28.12.2012 22:08, lipska the kat wrote:
    > On 28/12/12 20:22, Robert Klemme wrote:
    >> On 28.12.2012 18:50, lipska the kat wrote:
    >>
    >>> I spend much of my working life translating a clients business processes
    >>> into something that can run on a computer and the trend is now more than
    >>> ever away from a strictly web based process and towards systems that are
    >>> completely independent of delivery mechanism.

    >
    >> This sounds exactly like the use case JEE was intended for.

    >
    > Well yes, I remember early days writing EJB deployment descriptors by
    > hand. What a hideous nightmare that was. An early, poorly documented
    > version of Weblogic and trying to figure out how everything was glued
    > together because the company couldn't afford the price of Weblogic
    > training. RMI over IIOP, stubs and skeletons, oh misery thy name is J2EE
    > ... and don't get me started on the Sun One application stack


    But you did notice that things have considerably changed in JEE world,
    did you?

    > You know what, I don't actually use it much these days. I have a bunch
    > of classes that implement the core business logic. A facade hides the
    > atomic business logic methods from clients and people write to the
    > facade. Need more functionality ... no problem, update the facade by
    > combining atomic methods in new ways.
    >
    > I rarely use web frameworks either, or persistence frameworks or any
    > other type of framework unless the client specifically requests it.
    > I still write most of my own SQL ... for the same reason I still write
    > stuff in assembler. It just seems like a good idea to stay close to the
    > machine/problem space


    This sounds like a case of NIH syndrome. It may actually be that you'd
    be better off with all the framework logic though. If things work well
    for you the way they are then that's good.

    > Validation is done serverside, client side validation is a nice thing to
    > have but I would never rely on this, I would always back it up on the
    > server, after all, validation can be a fundamental part of your business
    > logic.


    Absolutely.

    Cheers

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Dec 28, 2012
    #18
  19. SL@maxis

    Arne Vajhøj Guest

    On 12/28/2012 12:50 PM, lipska the kat wrote:
    > What I inevitably end up with is a slightly less that perfect decoupling
    > but I like to think that eventually, given the appearance of a truly
    > scalable way to persist entire Object trees I will be able to produce a
    > business system that will be completely decoupled from earthly
    > considerations like UI and database


    I thought a business logic layer by definition was separate
    from UI layer and data access layer.

    :)

    Arne
     
    Arne Vajhøj, Dec 28, 2012
    #19
  20. SL@maxis

    Arne Vajhøj Guest

    On 12/28/2012 4:08 PM, lipska the kat wrote:
    > On 28/12/12 20:22, Robert Klemme wrote:
    >> On 28.12.2012 18:50, lipska the kat wrote:
    >>> I spend much of my working life translating a clients business processes
    >>> into something that can run on a computer and the trend is now more than
    >>> ever away from a strictly web based process and towards systems that are
    >>> completely independent of delivery mechanism.

    >
    >> This sounds exactly like the use case JEE was intended for.

    >
    > Well yes, I remember early days writing EJB deployment descriptors by
    > hand. What a hideous nightmare that was.


    They could be generate by IDE's.

    Or they could be generated by xdoclet.

    And they were not that hard to write manually.

    Today they can be replaced with annotations if one prefer those.

    > An early, poorly documented
    > version of Weblogic and trying to figure out how everything was glued
    > together because the company couldn't afford the price of Weblogic
    > training.


    That id more the company's problem than the technology's
    problem.

    ? RMI over IIOP, stubs and skeletons, oh misery thy name is J2EE

    RMI over IIOP is no worse than other binary serialized protocols.

    And stubs+skeletons is a standard solution for remote calls - EJB's
    or web services or whatever.

    Dynamically generated such do make life a little bit easier though.

    > You know what, I don't actually use it much these days. I have a bunch
    > of classes that implement the core business logic. A facade hides the
    > atomic business logic methods from clients and people write to the
    > facade. Need more functionality ... no problem, update the facade by
    > combining atomic methods in new ways.
    >
    > I rarely use web frameworks either, or persistence frameworks or any
    > other type of framework unless the client specifically requests it.
    > I still write most of my own SQL ... for the same reason I still write
    > stuff in assembler. It just seems like a good idea to stay close to the
    > machine/problem space


    Sounds pretty expensive to me not to utilize what other have
    come up with.

    DI frameworks, MVC web frameworks, ORM etc..

    To quote Newton "If I have seen further it is by standing on the
    shoulders of giants".

    Arne
     
    Arne Vajhøj, Dec 28, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?SSBhbSBTYW0=?=

    Datagrids are kicking my ass!! Please help

    =?Utf-8?B?SSBhbSBTYW0=?=, Mar 14, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    408
    JohnFol
    Mar 14, 2005
  2. Matt
    Replies:
    2
    Views:
    369
    Andrew Thompson
    Feb 25, 2004
  3. windandwaves

    kicking a list to visible into IE

    windandwaves, Aug 2, 2005, in forum: HTML
    Replies:
    3
    Views:
    422
    windandwaves
    Aug 5, 2005
  4. korean_dave
    Replies:
    2
    Views:
    439
    Lawrence D'Oliveiro
    Oct 19, 2008
  5. Tuc

    Regexp kicking my ass

    Tuc, Jan 27, 2005, in forum: Perl Misc
    Replies:
    4
    Views:
    167
    Gunnar Hjalmarsson
    Jan 27, 2005
Loading...

Share This Page