Weblogs Forum - What Are Your Java Pain Points, Really?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What Are Your Java Pain Points, Really?

264 replies on 18 pages. Most recent reply: Jan 17, 2008 7:07 AM by GJ sonke

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 264 replies on 18 pages [ « | 1 ... 12 13 14 15 16 17 18 | » ]

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension

Posted: Feb 25, 2007 12:07 PM

OK, Erik,

I'm glad that you're looking at solutions. What you suggest could fly.

As for bi-drectional links, all you would need is for each site to keep a registry of page links. When a page is moved then referencing remote registries would be updated too. The pages themselves would reference their local registry. So when you link across to a page then you would look up the remote URL locally first.

I'm sure there are better schemes out there and I know it is something that people have looked at. I came up with this idea after 5 minutes thought. The point is that the web must be able to change and grow dynamically (something that the OSGi people have worked out and why EJBs are a dead end). This is achieved by using a generic interface - this is the basis of REST and the Uniform Connector idea. Dynamic OOP does the same thing using a generic message passing semantic that is unform across all objects (everything is an object).

CLOS is a bit different but can obey the same uniform messaging semantic. C++/Java/C# can't. So as Alan Kay says, why can't every object have a URL? and why can't we send OO messages across languages? With dynamic OOP you can, which would give you a very different web!

BTW. I would urge you to check out Strongtalk. It's fast, it has message sends, it's dynamically compiled and it has static type checking. Strongtalk shows what's technically possible when marketing and politcs are put to one side.

Paul.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 25, 2007 1:45 PM

> It discourages thinking of
> the data on a high-level and creating a strategy for
> managing it.
Are you seriously saying that it is bad, because it makes using SQL easier?

> If the data no longer comes from SQL, you
> will have to change the program, even if the actual data
> used by the program does not change. My experience is
> that it's much better to push data to code instead of
> embedding queries in the code.
Wanting to put an abstraction layer over the SQL schema is like defining an interface for every class - it's overly generic. It creates unnecessary complexity and maintenance.

First, many applications only need an SQL storage.

Second, if you start to add another storage, you'll still have to make changes - which are more difficult if the existing architecture is more difficult.

Third, Linq would help in creating an SQL layer, too.

Last, and most importantly, it makes your system harder to learn, use, and adapt for others - this is a huge problem in our company.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Lack of extension

Posted: Feb 25, 2007 7:17 PM

> As for bi-drectional links, all you would need is for each
> site to keep a registry of page links. When a page is
> moved then referencing remote registries would be updated
> too. The pages themselves would reference their local
> registry. So when you link across to a page then you would
> look up the remote URL locally first.

One of the more interesting things about this comment is the fact that the web is so unicast while the rest of the world is so multicast. The scale up required to support a multicast style of communication is not really possible yet.

A key Java technology that everyone passes over is Jini. Jini is now officially an Apache podling as the River project. Jini provides a very secure, extensible platform for the use of mobile code as a late binding platform.

The ServiceUI standard provides a simple extensible standardization of a Entry implementation that allows UIs to be dynamically added to services by 3rd parties who have control access to the service registrations.

Because Jini services capitalize on interface based programming, the functions of the service are programatically visible to the same tools that you use for writing code in your IDE. Because it utilizes the security features of Java and extends them for the mobile code environment, you can achieve a wide range of security based control of what is downloaded, who executes it, and what authentication you pass around to services you are using.

This is precisely what the applet paradigm should have started out as, and what Java web start should had started with. Instead, we have the concept of small applications (applets) and seldom changing codebases of large focused applications (java web start's download optimization) as the platform supported paradigms of distributed application deployment strategies.

Jini is targeted at late binding everywhere. It allows the exploit of smart proxies to create new, appropriate wire protocols to help applications optmize their behaviors over time by distributing method calls to multiple services or otherwise map an existing interface for backward compatility onto new service implementations.

Because of interface based programming and because service discovery is used to "find" the service providing the implementation of the needed interface, the implementors are free to change the backend implementation in anyway they want. They can support old and new implementations through the same service object downloaded by all clients.

IDEs can programatically do discovery of services for developers and show them all of the bits of the service definition (no WSDL required).

> I'm sure there are better schemes out there and I know it
> is something that people have looked at. I came up with
> this idea after 5 minutes thought. The point is that the
> web must be able to change and grow dynamically (something
> that the OSGi people have worked out and why EJBs are a
> dead end). This is achieved by using a generic interface -
> this is the basis of REST and the Uniform Connector idea.

The uniformity of the REST "API" is only a redherring in the mix of security, interoperability and extensibility. Behind the scenes, client and service software must still be written. Servlets in java or some other parallel in another language have to exist. Clients have to use APIs that allow them to use HTTP effectively.

If you think that this simple interoperability implementation is where the most value is added in distributed computing, you probably are only considering a very small number of simple applications based on the resource/file model of the "web". It works good for pages and files. It doesn't always map efficiently to many types of applications that have much better protocols for managing interactions.

It's the support for plugging in different endpoint protocols and different invocation layers as well as integrated support for security and integrity that I value the most.

The Jini Extensible Remote Invocation (JERI) stack provides this kind of thing so that you can keep your developers writing Java code, while providing services which provide the same programmatic support for accessing a MODBUS device as it does for accessing a proprietary device. Additional devices are trivially supported.

> Dynamic OOP does the same thing using a generic message
> passing semantic that is unform across all objects
> (everything is an object).

The notion of considering method invocations the same as messaging is very much what helps one come to grips with the true nature of distributed computing. Generic messaging passing semantics are what the JERI stack exposes in the invocation layer component of its API. Direct access to the "invoke" operation's interactions with the client and server environment allows truely dynamic interaction with the local and remote systems through whatever customization is needed to make things work as needed.

> CLOS is a bit different but can obey the same uniform
> messaging semantic. C++/Java/C# can't. So as Alan Kay
> says, why can't every object have a URL? and why can't we
> send OO messages across languages? With dynamic OOP you
> can, which would give you a very different web!

The interesting thing about the JERI stack is that you can plug in a web services, HTTP/REST or some other endpoint or invocation layer implementation. You can create java clients that interact with a wide range of languages as services. Those clients can capitalize on the Java platform features needed, while still utilizing a wealth of different services.

This plugability is something that is, for me, a very powerful capability. Instead of creating interoperability around a "lower level" protocol, the interoperability is created at the language level without the direct visibility of APIs such as the java.net.URL API for example. Web services requires a huge set of tooling because of all the layers and layers of indirection required to integrate so many diverse and completely opposing systems.

> BTW. I would urge you to check out Strongtalk. It's fast,
> it has message sends, it's dynamically compiled and it has
> static type checking. Strongtalk shows what's technically
> possible when marketing and politcs are put to one side.

Does it include mobile code and a security model? In this world of come as you are computing, security is vital to help users get the most out of the mobile code paradigm.

Javascript has access to the document model which the Java applet model should have had to begin with. It provides a mobile code model which is great for HTML pages.

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension

Posted: Feb 25, 2007 9:57 PM

Lots of interesting things in your response...

>
> One of the more interesting things about this comment is
> the fact that the web is so unicast while the rest of the
> world is so multicast. The scale up required to support a
> multicast style of communication is not really possible
> yet.

People are doing it now! Go to this site:

www.opencroquet.org

There is a lot of info there. But if you download and run the Just for kids distribution you will be amazed. Seeing Firefox run in a 3D collaborative space is amazing. These people have built "The Matrix".
>
> A key Java technology that everyone passes over is Jini.
> Jini is now officially an Apache podling as the River
> r project. Jini provides a very secure, extensible
> platform for the use of mobile code as a late binding
> platform.

I like Jini too. I've never understood why Sun never marketed it harder and chose to focus on RMI and EJBs, even after CORBA had shown the limitations of a static "IDL" approach.
>
> The ServiceUI standard provides a simple extensible
> standardization of a Entry implementation that allows UIs
> to be dynamically added to services by 3rd parties who
> have control access to the service registrations.

The issue possibly with Jini is that Java is not late-bound itself. So an Interface is OK, but what happens when that interface needs to change? Say you want to add an aditional message to a service what happens? The true meaning of polymorphism is "many forms" and following a change in form the exisiting clients should still work. With Java the verifier would see the changed service as a new interface.

Alan Kay and his team wanted to use Java for Croquet and where forced to re-implement Smalltalk themselves (Squeak) because of these types of limitations.

>
> Because Jini services capitalize on interface based
> programming, the functions of the service are
> programatically visible to the same tools that you use for
> writing code in your IDE. Because it utilizes the
> security features of Java and extends them for the mobile
> code environment, you can achieve a wide range of security
> based control of what is downloaded, who executes it, and
> what authentication you pass around to services you are
> using.
>
I've never used Jini and it would be interesting to see how far you can go with it. My concern though is that with a statically compiled language, all you have a runtime is a collection of bits. So the runtime may not present the required meta features to support what you are suggesting fully. What you would want to do is inspect objects remotely, perhaps read dcoumentation on methods remotely, and send messages and see what responses you get. I know in Smalltalk where each class is an object that can be manipulated, inspected and extended at runtime that all this is possible. The meta facilities in Java though are rather weak.

> This is precisely what the applet paradigm should have
> started out as, and what Java web start should had started
> with. Instead, we have the concept of small applications
> (applets) and seldom changing codebases of large focused
> applications (java web start's download optimization) as
> the platform supported paradigms of distributed
> application deployment strategies.

What a lot of people do not understand is that java was produced in a hurry. Sun saw it a a strategic tool in their battle with Microsoft. The last thing the Oak designers had on their minds was the internet, they where more concerned with toasters :^).
>
> Jini is targeted at late binding everywhere. It allows
> the exploit of smart proxies to create new, appropriate
> wire protocols to help applications optmize their
> behaviors over time by distributing method calls to
> multiple services or otherwise map an existing interface
> e for backward compatility onto new service
> implementations.
>
> Because of interface based programming and because service
> discovery is used to "find" the service providing the
> implementation of the needed interface, the implementors
> are free to change the backend implementation in anyway
> they want. They can support old and new implementations
> through the same service object downloaded by all
> clients.
>
> IDEs can programatically do discovery of services for
> developers and show them all of the bits of the service
> definition (no WSDL required).
I like the no WDSL! But static interfaces have their limitations too.

>
> The uniformity of the REST "API" is only a redherring in
> the mix of security, interoperability and extensibility.
> Behind the scenes, client and service software must still
> l be written. Servlets in java or some other parallel in
> another language have to exist. Clients have to use APIs
> that allow them to use HTTP effectively.
I agree, but you do need a common substrate to build on. In dynamic OOP it all starts with the message. With a message you then can start to ask an object questions (whilst knowing nothing about it's implementation). What methods do you have, what can you do? am I allowed to access you? All these things can be addressed with messaging and a meta-protocol that is common to all objects. Again take a look at Croquet.

BTW. I believe that Jini has the same idea of a common substrate. For Jini I believe it is the "lookup".

>
> > BTW. I would urge you to check out Strongtalk. It's
> fast,
> > it has message sends, it's dynamically compiled and it
> has
> > static type checking. Strongtalk shows what's
> technically
> > possible when marketing and politcs are put to one
> side.
>
> Does it include mobile code and a security model? In this
> world of come as you are computing, security is vital to
> help users get the most out of the mobile code paradigm.
>

Yes to mobile code. This is why the dynamic compilation is so important. It will compile byte code to machine code on the fly. When a polmorphic message send hits a new method (for example I have changed implementation dynamically), then the VM will de-optimise back to interpreting byte code which is then later compiled. So the implementation can change while the program is still running, all hidden behind a message send.

As for security, like I said this can be implemented as a meta protocol using messaging. I believe this is the approach they intend to use with Croquet.

Incidently the "type-feedback" approach used in Strongtalk was derived from the Self research at Sun that was looking at distributed objects and mobile code long before Java existed. Self had a visual distributed mobile objects space which they called Kansas. (Javascript was later modelled on Self).

So technically all these things have been possible for a long while. Strongtalk was designed and built in 1995, before being bought by Sun and buried. The Strongtalk developers went on to work on the Java JIT "hot spot" VM.

http://www.strongtalk.org/

So technically all this is possible.

Paul.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Lack of extension

Posted: Feb 25, 2007 10:28 PM

> What a lot of people do not understand is that java was
> produced in a hurry. Sun saw it a a strategic tool in
> their battle with Microsoft. The last thing the Oak
> designers had on their minds was the internet, they where
> more concerned with toasters :^).

The other thing a lot of people don't understand is that Oak was pretty much a failure at its Plan A, which (as you implied) was to be an embedded systems language. I don't think Gosling really had any embedded systems experience and if he had he never would have attempted to create a platform-independent embedded systems language at that point in time. In the 1991/1992 time-frame, a 64K embedded program would be considered medium to large and about half were written in assembly.

Java can be used successfully in embedded systems these days simply because memory resources have increased more than an order of magnitude since the Oak era. Even today Java's embedded role seems mostly limited to non-realtime applications.

Carl Scharenberg

Posts: 1
Nickname: kingprad
Registered: Feb, 2007

Re: What Are Your Java Pain Points, Really?

Posted: Feb 25, 2007 11:57 PM

My main annoyance is the String class which, to my mind, has some annoying deficiencies. It seems silly not to have a very simple function to test for substrings, like a contains() function. Performing indexOf() and comparing to an integer to determine such a basic thing seems silly - gratuitous orthogonality, if you will. Adding contains() and some other convenience functions such as those in scripting languages (Python, Ruby, etc) would would eliminate a lot of little hassles in my work.

Jean-Daniel Nicolet

Posts: 13
Nickname: jdnicolet
Registered: Oct, 2003

Re: Why I don't like Java

Posted: Feb 26, 2007 9:57 AM

> Java claims heritage from C++ but as a simplification of
> it. Making it like C++ would defeat the purpose. If Java
> were just like C++, there would be no reason for it to
> exist.

This last sentence is just amusing, because this is more or less what the other contributers in this forum tend to say, perhaps not so abruptly.

Now that many programmers have gained experience with Java, they tend to point out at all the shortcomings and weaknesses when compared to its C++ ancestor, often without knowing that most of what they are asking for is already present in that venerable ancestor.

The main simplicity argument advocated when Java was created tend to be now its Achille's heel. The problem is that the pretended lack of complexity was achieved by throwing away "complicated" features of C++, like for example a good template mechanism or operator overloading, but without paying enough attention to the completeness of the new language, i.e. the possibility to extend it with good libraries without constantly resorting to adding new features in the language.

Another important aspect is the general lack of consistency, being in the design of the API's as noted regarding the collections, or in the language itself, leading to these numerous gotchas with the "half" generics added afterward that are covariant by essence, whilst being nonetheless compatible with old arrays that are themselves contravariant.

Many people in this forum points out that this is gonna to kill the language, because it is yet not simple enough anymore for the beginners it was intended for, but not powerful enough for educated programmers able to master abstract concepts like generics, functional programming, and the like.

All in all we see retrospectively that designing a well-balanced language between complexity and powerfulness is very difficult and time-consuming, and that Java missed that point.

Hopefully the new popular VM-based langagues like Scala will do better and we won't have that same discussion again about them in ten years from now!

(By the way, C++ has not said its last word and propositions to simplify its declarative syntax (e.g. not having to explicitly repeat the type twice) are now part of the new standard's proposal).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 26, 2007 12:20 PM

> > It discourages thinking of
> > the data on a high-level and creating a strategy for
> > managing it.
> Are you seriously saying that it is bad, because it makes
> using SQL easier?

Please forgive the curtness of my previous response. I should have just waited until today as I was ill this last weekend.

i don't think it makes SQL easier. It appears to make it easier to bind the data access to application logic. Binding data access to logic is (IMO) a bad practice. This doesn't make the tool bad per se, it just addresses the wrong problem. People are already binding data access to application logic.

At a superficial level it does seem silly to say that making something easier is bad but if take it in perspective it makes sense. Here's an analogy: crack is great improvement for cocaine delivery (to the consumer and his/her bloodstream). But that doesn't make it a good thing. Things that make it easier to create problems can be bad, yes. Theoretically, tools that make bad things easier are irrelevant (because they shouldn't be done anyway) but in terms of human behavior, tools that make bad things happen faster can be problematic.

> > If the data no longer comes from SQL, you
> > will have to change the program, even if the actual
> data
> > used by the program does not change. My experience is
> > that it's much better to push data to code instead of
> > embedding queries in the code.
> Wanting to put an abstraction layer over the SQL schema is
> like defining an interface for every class - it's overly
> generic. It creates unnecessary complexity and
> maintenance.

That has nothing to do with what I am talking about.

> First, many applications only need an SQL storage.
>
> Second, if you start to add another storage, you'll still
> have to make changes - which are more difficult if the
> existing architecture is more difficult.

What I am saying is that mixing the application logic with data storage is not a good idea over the long term even though it seems really great in the short-term. Now, I could use Linq to do that but I don't think strongly coupling your data access to your development tools provides enough benefit in the context of that approach. Many of the problems that solved by mixing data access with application code are not serious issues in a data-driven approach.

I want to step back from the focus of schema changes and that type of thing. This is not really the main benefit of a data-driven approach. It's easier, yes but will (as you pointed-out) still require application changes. It's my fault for being lazy and mentioning it as a benefit. The main benefit of the data driven approach is that it becomes much easier to manage the relationship between the data and the logic. I am sure you understand the benefits of decoupling in application development.

> Third, Linq would help in creating an SQL layer, too.
>
> Last, and most importantly, it makes your system harder to
> learn, use, and adapt for others - this is a huge problem
> in our company.

I think you are not understanding. I am not talking about an abstraction layer over the database. I am talking about an abstract layer over the logic. The application should not retrieve the data. It should receive it or request it but avoid retrieving it explicitly. A lot of the usefulness of this approach necessitates a dynamic data approach. If you are not comfortable with that type of design, it might be hard to swallow.

I am also not in agreement with the idea that because an approach is harder to understand that it should not be used. There is a cost-benefit analysis that must be considered. You cannot design to the lowest common-denominator nor can you design at a level that cannot be understood. Again and again the biggest messes I've had to maintain were developed with an overly-simplified approach. When the solution proves to be insufficient it's usually too late. This results in bloat and almost constant development just to solve the same problems again and again. I believe using fairly simple tools to create designs with an appropriate level of complexity rather than using complex tools to create simplistic designs. The logic is that it's fairly easy to address the complexity in your designs but almost impossible to address complexity in your tools.

I just want to add that I don't want my statements to be interpreted as an attempt to state universal truths. I am only speaking from my own personal experience and the kinds of systems and projects I have worked with. It may be in the kind of work that you do, my approach makes no sense. I don't think the ideas I am espousing are that widely accepted. I'm pretty sure they go against much of the common-wisdom of developers and designers. Maybe I'm just a nut. I'm not rejecting what you are saying. I'm just giving my opinion on the matter. Whether my concerns are warranted will not be known for a number of years. Some might argue that it doesn't matter because of that time frame. I would say, however, that I have dealt with too many 5-15 year old systems where this mistake was made. It just seems to me that this industry suffers from amnesia and is doomed to make the same mistakes again and again.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Lack of extension

Posted: Feb 26, 2007 1:11 PM

> > The ServiceUI standard provides a simple extensible
> > standardization of a Entry implementation that allows
> UIs
> > to be dynamically added to services by 3rd parties who
> > have control access to the service registrations.
>
> The issue possibly with Jini is that Java is not
> late-bound itself. So an Interface is OK, but what happens
> when that interface needs to change? Say you want to add
> an aditional message to a service what happens? The true
> meaning of polymorphism is "many forms" and following a
> change in form the exisiting clients should still work.
> With Java the verifier would see the changed service as a
> new interface.

When you want to add a method to an interface, the you have to do something that many seem to consider problematic. You have to create a new interface that subclasses the old interface. And, you should just copy all the method signatures from the old interface into the new interface so that at some point you can just remove the "extends" clause for that old interface.

This allows your new "service" to be seen as "the old interface" and the new interface. If you don't want to augment the interface name with a version string, then make the package provide the version delineation.

org.wonderly.jago.v1.Service

becomes

org.wonderly.jago.v2.Servi ce

This allows users to continue to "search" based on the well known service name, but to simply change in import when they want to upgrade to use the new interface.

With mobile code, you should always include all interfaces in your downloaded jar so that this kind of "new class" will be resolvable anywhere the code travels to.

In Jini, we have the PreferredClassLoader which clients use by default. It supports a META-INF/PREFERRED.LIST file in the downloaded jar (the first jar in the codebase). That file says which classes are preferred, and the class loader will then always resolve them to the codebase instead of looking up the tree. This solves the most classic versioning problem in mobile code comming from multiple places.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Lack of extension

Posted: Feb 26, 2007 1:11 PM

> The other thing a lot of people don't understand is that
> Oak was pretty much a failure at its Plan A, which (as you
> implied) was to be an embedded systems language. I don't
> think Gosling really had any embedded systems experience
> and if he had he never would have attempted to create a
> platform-independent embedded systems language at that
> point in time. In the 1991/1992 time-frame, a 64K embedded
> program would be considered medium to large and about half
> were written in assembly.

I'd venture a guess that at the time Oak was embedded in the controller that has been seen as the "platform" it was designed for, that the whole environment was not very big.

> Java can be used successfully in embedded systems these
> days simply because memory resources have increased more
> than an order of magnitude since the Oak era. Even today
> Java's embedded role seems mostly limited to non-realtime
> applications.

If you want to see small Java systems, look at what the aJile chip and others can do when using CLDC as the only required platform and using post compile analysis to remove unneeded classes.

If you want to see really small Java applications look at what is happening at www.muvium.com.

It's possible to do small things with Java the language. If you want to do small things with Java the platform, you need to plan on how you will support "the platform".

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Lack of extension

Posted: Feb 26, 2007 1:13 PM

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Lack of extension

Posted: Feb 26, 2007 1:59 PM

> I'd venture a guess that at the time Oak was embedded in
> the controller that has been seen as the "platform" it was
> designed for, that the whole environment was not very
> big.
>

Well, you're being a bit vague about what you mean by "big". Clearly much of what we consider "small" today would have been considered enormous in 1992.

Many of the embedded systems of that era didn't even include OS's, so adding a JVM would increase resource requirements significantly.

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension

Posted: Feb 26, 2007 3:28 PM

> > > The ServiceUI standard provides a simple extensible
> > > standardization of a Entry implementation that allows
> > UIs
> > > to be dynamically added to services by 3rd parties
> who
> > > have control access to the service registrations.
> >
> > The issue possibly with Jini is that Java is not
> > late-bound itself. So an Interface is OK, but what
> happens
> > when that interface needs to change? Say you want to
> add
> > an aditional message to a service what happens? The
> true
> > meaning of polymorphism is "many forms" and following a
> > change in form the exisiting clients should still work.
> > With Java the verifier would see the changed service as
> a
> > new interface.
>
> When you want to add a method to an interface, the you
> have to do something that many seem to consider
> problematic. You have to create a new interface that
> subclasses the old interface. And, you should just copy
> all the method signatures from the old interface into the
> new interface so that at some point you can just remove
> the "extends" clause for that old interface.
>
> This allows your new "service" to be seen as "the old
> interface" and the new interface. If you don't want to
> augment the interface name with a version string, then
> make the package provide the version delineation.
>
> org.wonderly.jago.v1.Service
>
> becomes
>
> org.wonderly.jago.v2.Service
>
> This allows users to continue to "search" based on the
> well known service name, but to simply change in import
> when they want to upgrade to use the new interface.
>
> With mobile code, you should always include all interfaces
> in your downloaded jar so that this kind of "new class"
> will be resolvable anywhere the code travels to.
>
> In Jini, we have the PreferredClassLoader which clients
> use by default. It supports a META-INF/PREFERRED.LIST
> file in the downloaded jar (the first jar in the
> codebase). That file says which classes are preferred,
> and the class loader will then always resolve them to the
> codebase instead of looking up the tree. This solves the
> most classic versioning problem in mobile code comming
> from multiple places.

I thought as much. The use of Interfaces in Java does make things more dynamic, but it just doesn't go far enough (IMO). This coupled with weak meta-facilities makes
Java a poor candidate as a distributed, mobile code, OO language for the web.

This is a shame, because this is the exact purpose Sun initially marketed Java for.

Take a detailed look at Croquet:

http://www.opencroquet.org/index.php/Main_Page

Peer-to-peer replicated mobile objects creating a 3D virtual collaborative space across the web. This isn't web2.0 or 3.0. This is WebNG (Next Generation). Late-binding to anything on your desktop. So You and I could be editing the same document in a shared 3D space, using a 2D word processor like Word that doesn't even know that it is being used collaboratively across the web in a 3D space.

This technology is here now and works, and just isn't possible with Java.

Paul.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 26, 2007 4:20 PM

> i don't think it makes SQL easier. It appears to make it
> easier to bind the data access to application logic.
> Binding data access to logic is (IMO) a bad practice.
> . This doesn't make the tool bad per se, it just
> addresses the wrong problem. People are already binding
> data access to application logic.
>

Its purpose is to make it it easier to perform queries and to make that process type-safe. It has nothing special to do with "application logic" vs. any other kind.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Lack of extension

Posted: Feb 26, 2007 7:21 PM

> Well, you're being a bit vague about what you mean by
> "big". Clearly much of what we consider "small" today
> would have been considered enormous in 1992.

I'm talking about 64KB-128KB for big applications in that day and age on small devices. Micro-controller applications were largely written by hardware "dudes" in that day and age, and they weren't really software engineers familiar with virtualization techniques of the day. Most of the time, processors capable of going beyond 64KB would only have 32KB or 48KB because of the perceived expense of memory. The demand is what kept the price of memory up. Only when the PC market 1

> Many of the embedded systems of that era didn't even
> include OS's, so adding a JVM would increase resource
> requirements significantly.

If you have to "add" a JVM in a micro environment, you haven't designed your micro environment to capitalize on Java. Instead you've decided that Java can't add any real value and so it should just be an add-on that you can pitch when it fails to meet the needs of the users.

This is precisely what has happened in the cell phone industry. J2ME CLDC with MIDP is terrible to use on mobile phones because you can't make it interact with the user without disabling everything else the user wants to use the phone for. The manufactures don't think Java is a platform. They think that Java is an add-on for games and gimics.

Java is not an add-on technology! Java is a platform technology. If you are not getting everything that you need out of Java, I'd wager that you have not put it close enough to the problem space to allow it to work effectively.

RTSJ demonstrates that Java can provide real-time programming. Java smart card (every resident of Korea, and Brazil carries a Java smart card), demonstrates that Java can be a platform on a very limited device.

If you've never written code for all of the Java platforms, then you probably don't understand the issue of Java portability. If you've written applets, and then moved on to java script, then you probably understand the issue of making a application platform into an add-on, instead of a platform.

Flat View: This topic has 264 replies on 18 pages [ « | 12 13 14 15 16 17 18 | » ]

Previous Topic

Next Topic