The Artima Developer Community
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

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 264 replies on 18 pages [ « | 1 ... 11 12 13 14 15 16 17 18 | » ]
Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: What Are Your Java Pain Points, Really? Posted: Feb 22, 2007 3:09 AM
Reply to this message Reply
Advertisement
> I also don't eat with a spork. I use a
> separate spoon and fork.
>
> And I'm glad you don't eat with a spork. Personally, I
> always found them sort of unwieldy. ;-)

Hey, don't knock the spork! Dynamically typed cutlery - it's the future! Why implement a complete, statically typed place setting when all you want is to wolf down some Pot Noodles? If it's shaped (a bit) like a fork then it is a (sort of) fork (thing).

In fact, the spork really doesn't go far enough. It's still usually implemented in Metal or Plastic which means that, once defined, it can't easily be extended or recast as something else. The problem is the separation of creating and using cutlery. It's so 'last year'.

As a result I propose Smallspork (tm). With this the 'spork' can be defined using a light weight, soft modelling clay. This allows for run-time modifications (and eliminates any need for casting). It also does away with any of the usual overheads associated with creating your own CutleryFactory pattern first. Bent a prong? Simply straighten it 'on-the-fly'. Just realised that what you really needed was a can-opener? Simply add the appropriate extension (while you eat).

For new users, I would suggest you take a look at Squork. In this implementation, the base clay comes in many colours and is especially suitable for children who can use it to implement any cutlery (even cutlery that hasn't beeninvented yet), limited only by their imagination.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 22, 2007 6:06 AM
Reply to this message Reply
> > > Linq isn't released yet (except for betas), but I
> > haven't
> > > even used C# yet.
> > > I've looked at the examples (found via Wikipedia) and
> I
> > > liked the static typing of SQL
> >
> > I've used languages that allow embedded SQL.
> PowerBuilder
> > and COBOL for example. The embedded SQL inevitably
> > becomes the biggest maintenance problem.
> I have also found embedded SQL to be a maintenance
> problem.
> I think the reason being that it cannot be refactored
> (probably because it is not statically typed). This
> problem is solved in Linq.
>
> > It's something I
> > don't care to suffer through again. Inversion of
> control
> > (no, I don't mean Spring or Hibernate in particular) is
> a
> > much more maintainable approach.
> I guess you mean that you change the SQL schema without
> changing the code.
> I think this is only true for trivial schema changes - and
> that refactoring can do the same for you.
> OTOH, Linq can do things that Hibernate cannot do as
> easily - otherwise you wouldn't need HQL (embedded SQL).
> I have to admit that I don't have experience with
> Hibernate or Linq, though...

I don't use Hibernate either. I don't want another language and complex framework to learn and have to teach to others.

I'm not sure what static typing does for me if the schema changes.

The benefits of pulling the queries out of the code include:

* A single place to manage changes
* A single place to find existing queries
* It's easy to reuse queries when appropriate (doesn't happen all that often, really)
* It's Easy to debug queries i.e. run them outside of the application
* Code is more reusable because it depends only on the data, it can receive that data from any number of sources. It's not coupled to the query.

There are more I'm sure but I haven't had my coffee yet.

> In essence, the XLinq objects have methods like
> descendants, parent, etc. that don't make sense in DLink
> (database version of Linq)

So there are multiple versions of the syntax. I could be mistaken but I thought your point was that it would be good to only have one syntax, which I agree with, I just think it's not feasible. Actually I think it might be impossible to create a clean, concise syntax that meets that requirement (which is a subjective requirement that cannot be proven or disproven.) It seems to me that this kind of syntax branching is a slippery slope. Do you know if they started out with branched syntax or if that was a later developement?

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 22, 2007 6:41 AM
Reply to this message Reply
> So there are multiple versions of the syntax. I could be
> mistaken but I thought your point was that it would be
> good to only have one syntax, which I agree with, I just
> think it's not feasible. Actually I think it might be
> impossible to create a clean, concise syntax that meets
> that requirement (which is a subjective requirement that
> cannot be proven or disproven.) It seems to me that this
> kind of syntax branching is a slippery slope. Do you know
> if they started out with branched syntax or if that was a
> later developement?

In the broker that I wrote back in the late 1990's, I have support for an XML driven configuration. Here's an example of the storing of data to a database. Under the covers, there is a "map" of name/value pairs, extracted from some inbound data, which flows through the system with a "report" name associated with it. Delivery Models specify how to process data by mapping internal names to database field names along with indicating key fields. The system was designed to process raw streams of data from small devices, do data extraction (which is described by another document type) and then routing into the enterprise systems.

<?xml-stylesheet type="text/xsl" href="delivery.xsl"?>
<delivery id="Data from the XYZ System">

<destparms name="MSSQLParms">
<descr>Paradevs needed for access to the database</descr>
<param name="url"
value="jdbc:microsoft:sqlserver://host.name:1433"/>
<param name="driver"
value="com.microsoft.jdbc.sqlserver.SQLServerDriver"/>
<param name="username" value="user"/>
<param name="password" value="password"/>
<param name="type" value="mssql"/>
<param name="transact" value="14400"/>
<param name="maxidle" value="14400"/>
<procedure call="execute">
<prefix val="{call "/>
<suffix val="}"/>
</procedure>
</destparms>

<fieldvaluemap name="dataMap">
<descr>
Map the fields for storing into the database.
</descr>
<store field="mtype" as="devtype"/>
<store field="dev_station" as="dev_station" key="yes"/>
<store field="dev" as="dev" key="yes"/>
<store field="systimestamp" as="prod_date_time" key="yes"/>
<store field="subhour" as="subhour" key="yes"/>
<store field="minflow" as="flowtime"/>
<store field="mcf" as="mcf_1473"/>
<store field="dtf" as="energy"/>
<store field="dp" as="dp"/>
<store field="rawpress" as="psia_pres"/>
<store field="temp" as="temperature"/>
<store field="unc_vol" as="unc_vol"/>
<store field="intext" as="intext"/>
<store field="pb_status" as="pb_status"/>
<store field="datasource" as="data_source"/>
<store field="seq" as="sequence_num"/>
<store field="gmtstamp" as="gmt_time"/>
<store field="offset" as="gmt_offset"/>
</fieldvaluemap>

<deliveredby name="dataDeliv">
<descr>
Delivery description for storing data to the database.
</descr>
<lookup>


<!-- lookup data parameters for this device and do pre-store
conversions
-->
<select sql="select atmospheric_pressure,type,effective_date_time from schema.dev_characteristic where dev_station=? and dev=? and effective_date_time = (select max(effective_date_time) from schema.dev_characteristic where dev_station = ? and dev=?)">
<arg><ref field="dev_station"/></arg>
<arg><ref field="dev"/></arg>
<arg><ref field="dev_station"/></arg>
<arg><ref field="dev"/></arg>
</select>

<!-- process values from parameter lookup -->
<set field="dev_type" type="string" from="type"/>
<set field="atmospheric_pressure" type="float"
from="atmospheric_pressure"/>
<set field="rawpress" type="float">
<ref field="press">
<add field="atmospheric_pressure"/>
</ref>
</set>

<!-- handle other data conversion/mapping -->
<set field="isorifice" type="boolean">
<ref field="dev_type">
<contains pattern="ORIFICE"/>
<convert to="string"/>
</ref>
</set>
<set field="unc_vol" type="float">
<when field="isorifice">
<eq val="true">
<null type="FLOAT"/>
</eq>
<else>
<ref field="sqrtextn"/>
</else>
</when>
</set>
<set field="intext" type="float">
<when field="isorifice">
<eq val="true">
<ref field="sqrtextn"/>
</eq>
<else>
<ref field="zero"/>
</else>
</when>
</set>
<set field="dp" type="float">
<when field="isorifice">
<eq val="true">
<ref field="dp"/>
</eq>
<else>
<ref field="zero"/>
</else>
</when>
</set>
<set field="mtype" type="string">
<when field="isorifice">
<eq val="true">
<ref field="orifice"/>
</eq>
<else>
<ref field="other"/>
</else>
</when>
</set>
</lookup>

<!-- perform the JDBC "insert" -->
<write/>
</deliveredby>

<model report="dataReport">
<descr>
Model for storing data to the appropriate destinations
</descr>
<deliver
location="schema.table_name"
deliveredby="dataDeliv"
fieldvaluemap="dataMap"
destparms="MSSQLParms"
destination="DataStore"
/>
</model>
</delivery>


The <write/> above allows additional attributes which specify the name of a "module" which is an implementation of the "DeliveryModel" interface. That module might write to log files instead, or to a JMS queue, or to something else such as a socket to a remote monitoring system using JMX events.

I've always felt that this kind of "scripting" is what Java needs. When I did this, we were running on JDK1.1.8. There was no other external scripting support, but there where XML DOM and SAX parsers. So, that's what I used. There are XSL stylesheets that convert this into a printable page that you can take to a meeting and talk about the things inside of the tags instead of wading through all the XML.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 22, 2007 7:10 AM
Reply to this message Reply
> I've always felt that this kind of "scripting" is what
> Java needs. When I did this, we were running on JDK1.1.8.
> There was no other external scripting support, but there
> e where XML DOM and SAX parsers. So, that's what I used.
> There are XSL stylesheets that convert this into a
> a printable page that you can take to a meeting and talk
> about the things inside of the tags instead of wading
> through all the XML.

I'm not sure whether you are agreeing with me that
a syntax to query XML and relational data is not workable,
disagreeing, or none-of-the-above.

But don't misunderstand me. There are things that one might
do with XML that make sense to write in Java. I love SAX
personally. It's the most underrated parser. I believe
that's because most people don't understand the Builder
pattern. In any event, I've written pretty-printers for
XML and other kinds of data-agnostic processes for XML in
Java to good effect. Java is an acceptable language for
implementing an XSL interpreter.

The problems start to creep in when people are using XML to
serialize data that is used in business logic. That is
Getting specific elements and mapping them to data elements
in your code (basically XML-OO mapping whether automatic or
not. My personal experience and what I see on countless
blogs and forums tells me that this is a problem that is
fairly generally misunderstood. This is why so many
attempts have bad results. Not accepting that XML-specific
languages are superior for working with XML data is a huge
error. It's orders of magnitude easier. And it doesn't
mean you remove the logic from Java. You just don't try to
query the XML from Java.

Now the question that Gregor and I are discussing is whether
a XML specific language should be embedded in a general
programming language. I say no. I think it provides very
little benefit and steers the unwary towards maintenance
problems.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 22, 2007 8:11 AM
Reply to this message Reply
> I'm not sure whether you are agreeing with me that
> a syntax to query XML and relational data is not
> workable, disagreeing, or none-of-the-above.

What I'm showing is that it is possible to completely separate scripting and meta-language configuration from the application code. That is, one can create frameworks which are externally scriptable/configurable and then make that how the application is extended/reused for various applications.

The unfortunate effect of allowing XML and SQL to be embedded into the language is that people will be interweaving higher and lower levels of programming instead of abstracting the operations that they need into a externally controlled framework.

This is the key of good API and library design. In the past, we've always written libraries to be used by like languages. I think there is plenty of possibilities to write libraries that can be driven by external languages which provide a much higher level of abstraction with a more focused domain of problem space.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 22, 2007 9:38 AM
Reply to this message Reply
> The unfortunate effect of allowing XML and SQL to be
> embedded into the language is that people will be
> interweaving higher and lower levels of programming
> instead of abstracting the operations that they need into
> a externally controlled framework.

I agree although a framework is not a requirement. Frameworks in Java have become nearly equivalent to languages in their scope (e.g. Spring and Hibernate) without really providing the power of a language. Sometimes it makes sense to put an application on rails (if you'll forgive the connotations of that word) but it's not a general solution.

> This is the key of good API and library design. In the
> past, we've always written libraries to be used by like
> languages. I think there is plenty of possibilities to
> write libraries that can be driven by external languages
> which provide a much higher level of abstraction with a
> more focused domain of problem space.

This is exactly the kind of thing that I am doing with Jython. This is not to say I am some sort of innovator but that this is not just a possibility. It's real right now. On a side-note (but related to the discussion) the interaction of Python with Java creates true double-dispatch. Because variables do not have types in Python, there's no way to simulate static binding to Java calls. The runtime type is used to determine which overloaded version to use. What makes this interesting to me is that Python doesn't have double-dispatch on it own either (no method overloading.)

Chuck Adams

Posts: 3
Nickname: chuckadams
Registered: Feb, 2007

Lack of extension Posted: Feb 22, 2007 1:30 PM
Reply to this message Reply
I originally had some really florid prose about this, but I'm respecting the format. My three, but all related and about equal:

3. No facility for extending the language with macros or outright new syntax. Related somewhat is operator overloading. Syntax must belong to the programmer. Which leads to:

2. A protective custodial culture. Java has owners, and the owners are out to protect it and us from the harm of being overly expressive. The concerns of managers demanding uniformity and simplicity have come to override almost completely the needs of programmers, save for a trickle of half-baked new features every JDK. The tide may be turning, but the competition doesn't stand still either.

1. A culture of adopters that demands this status quo remain and defends against any change as frivolous, even when these technologies have proven themselves in other languages for decades. I'm seeing people say with all serious that nothing should change in JDK7. Nothing at all. This extreme of conservatism may be rare, but I would dare say that the majority of sentiment is closer to keeping java a static and dead language than not. Paradoxically this leads to a proliferation of boondoggles in the language, such as including an entire Javascript interpreter. At the risk of sounding inflammatory, it's there as a sort of tacit admission that Java itself isn't up to the job.

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension Posted: Feb 23, 2007 5:11 AM
Reply to this message Reply
You are spot on here.

The underlying issues are complex, but come down to people, purpose and culture.

Oak is a fine language for the purpose for which it was designed. But if you want internet wide mobile objects, then you need late binding (just like HTTP) and you need meta-facilties and extensibility(like mime-types). So the mash-ups people are now creating with Javascript and HTML are just not possible with Java objects/components today.

The problems with Java stems from the fact that it is being used more and more for purposes for which it was not designed. The problem is though, is that Java was first marketed as an internet language (Applets), then as a late bound component language (JEE and EJB's). Oak was not designed for either.

So what would I like in an internet language:

1. Message sends (true ecapsulation and polymorphism)
2. Late-binding,
3. Mixins,
4. Closures

As for compile time type checking. This is an orthogonal concern and a nice to have (I like completion in eclipse too). You can have this and be fully dynamic. Take a look at Strongtalk.

So Java ported to the Strongtalk VM, would solve most of the problems, but then again it would not be Java, it would be something new :^)

Paul.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Lack of extension Posted: Feb 23, 2007 5:12 PM
Reply to this message Reply
>1. Message sends (true ecapsulation and polymorphism)

A little vague...

>2. Late-binding

SmallTalk (et. al.) forcing the usage of dynamic binding is no better than Java forcing the usage of static and polymorphic binding. I'm all for the invokedynamic bytecode in the JVM, but honestly I'd rather Java the language have dynamic binding. I'll use Groovy or Jython or something else for that.

>3. Mixins

C++ style, Ruby style, or some unique Java style?

>4. Closures

I think first-class functions, including lambdas (like Python), should come first. Closures can be useful, but they are also magical and dangerous.

>Language extension

Go program LISP. Making Java syntax more malleable would make it no longer be Java. It would break the conceptual integrity of the language. It's time for a new main stream JVM language. All these ideas are great by they're not Java, and all represent trades with significant downsides.

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension Posted: Feb 24, 2007 1:55 AM
Reply to this message Reply
>1. Message sends (true ecapsulation and polymorphism)

>> A little vague...

Nothing vague about this at all. Try listening to Alan Kay, he coined the terms: encapsulation, polymorphism and objects.. What you mean is that the C++/Java etc communities still do not get it over 30 years on!

>2. Late-binding

>> SmallTalk (et. al.) forcing the usage of dynamic binding is no better than Java forcing the usage of static and polymorphic binding. I'm all for the invokedynamic bytecode in the JVM, but honestly I'd rather Java the language have dynamic binding. I'll use Groovy or Jython or something else for that.

You don't force dynamic binding on anyone. The web is dynamically bound (ever heard of anyone bringing down the entire web, editing, compiling and starting the whole thing up again, just to add a new web page?) - and I don't hear anyone complaining.

>3. Mixins

>> C++ style, Ruby style, or some unique Java style?

C++ does not have Mixins. The concept is language neutral, but late binding tends to help.

>4. Closures

>> I think first-class functions, including lambdas (like Python), should come first. Closures can be useful, but they are also magical and dangerous.

One tends to go with the other...

>Language extension

>> Go program LISP. Making Java syntax more malleable would make it no longer be Java.

I am! And many others are moving to Lisp derived languages like Ruby and Phython. The issue is purpose. If I want late-bound components, DSLs, etc then Lisp is great. If I want Algol syntaxt aswell, then there is Ruby and Python.

>>It would break the conceptual integrity of the language. It's time for a new main stream JVM language. All these ideas are great by they're not Java, and all represent trades with significant downsides.

I agree. The biggest downside is backward compatibility. I agree what is needed is a different language. You choose not to mention my reference to Strongtalk and static type checking with a dynamic language. I think there is an IronPython in the making that does the same thing too.

Java was marketed at the C++ crowd. They see objects very differently from the Smalltalk/Lisp crowd. For C++ers compile-time type checking is a must. Well you can have this with a dynamic language! I'm not sure of the JVM as a platform though. What is required is a dynamic VM not a static one IMO. If you want to know why, try listening to Gilad Bracha of Sun.

Paul.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 24, 2007 5:24 AM
Reply to this message Reply
> So there are multiple versions of the syntax.
I think you got me all wrong.
Did you look at the examples and the document that I linked?

Linq is not a language. Technically, it's
1) a few keyword additions to C#/VB.NET
2) those keywords are translated to method calls by the compiler (via extension methods)
3) after this step, it's only a framework
4) this means that it's possible to use any .NET methods - it's not the same as executing SQL (and having to do everything which must be done on the database server in stored procedures/functions)

In this video, Anders Hejlsberg explains how to use Linq
http://channel9.msdn.com/Showpost.aspx?postid=114680

This video explain the technical background, including how the keywords are translated into method calls, and how extension methods and anonymous types and type inference play together in Linq.
http://channel9.msdn.com/Showpost.aspx?postid=236352

PS: Linq helps with schema changes in that they result in a compile time.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Lack of extension Posted: Feb 24, 2007 2:46 PM
Reply to this message Reply
>C++ does not have Mixins. The concept is language neutral, but late binding tends to help.

http://www.oonumerics.org/tmpw00/eisenecker.html

There are people who would disagree with you. I just yanked that as an example, but I've heard the term "mixin" used as a technique for C++ from many sources.

But actually my point is that I don't think mixins have a solid, well accepted definition.

>The web is dynamically bound

Yup...and it is full of broken bindings.

>and I don't hear anyone complaining.

I hear people swearing about broken links all the time.

>You don't force dynamic binding on anyone.

If the compiler doesn't for polymorphic binding (is that a real term? I just made it up) then dynamic binding will exist in the codebase because static typing imposes a significant immediate cognitive load that dynamic typing does not. There are times when it is worth it, and there are times when it is a waste. The point is people are lazy so making it optional will make it exist.

>What you mean is that the C++/Java etc communities still do not get it over 30 years on!

The C++/Java/C#/??? community hijacked Alan Kay's terms and that probably was detrimental to the industry because of the confusion it created. But that doesn't mean that Alan Kay's version is right and C++'s is wrong. It just means they are different and people should have used different words in referring to them.

Paul Beckford

Posts: 51
Nickname: phaedrus
Registered: Feb, 2007

Re: Lack of extension Posted: Feb 24, 2007 11:58 PM
Reply to this message Reply
Hi Erik,

Broken links have nothing to do with dynamic binding. It has to do with uni-directional links. If the web had bi-directional links the problem wouldn't exist.

BTW. I agree that there are different OOPs. The thing is which OOP is best suited to the types of apps Java has been marketed for? If Java was positioned as a static, low level highly perfomant system language much like C++, for writing embedded software or device drivers then fine.

The problem is that it has been marketed as an internet language, and as a high level, user centric, distributed application language. It was not designed for either of these purposes and it shows - hence this thread.

So what is the solution?

Paul.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Lack of extension Posted: Feb 25, 2007 8:25 AM
Reply to this message Reply
Paul,

>Broken links have nothing to do with dynamic binding.

Sure seems to for me. I remove a webpage to which I have another page linking. When I click the link to the page, I receive an error that says that page does not exist.

I have a method on one class being used by another. I remove that method. When I run my code, I receive an error saying the method could not be found.

>It has to do with uni-directional links. If the web had bi-directional links the problem wouldn't exist.

Please explain how this would work. Particularly on an internet scale.

>So what is the solution?

Something like LISP only with a modernized (and cleaned up) standard library, probably using a more Algol-like syntax. Neither Ruby nor Python fit this criterion, because LISP is can be compiled, can have fairly extensive static checks in the compiler, and is extremely fast. I also like the LISP take on object orientation better than C++ or Smalltalk.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 25, 2007 8:45 AM
Reply to this message Reply
> > So there are multiple versions of the syntax.
> I think you got me all wrong.
> Did you look at the examples and the document that I
> linked?
>
> Linq is not a language. Technically, it's

I don't think I claimed it was a language. But I think the distinction is purely semantic.

> 1) a few keyword additions to C#/VB.NET
> 2) those keywords are translated to method calls by the
> compiler (via extension methods)
> 3) after this step, it's only a framework
> 4) this means that it's possible to use any .NET methods -
> it's not the same as executing SQL (and having to do
> everything which must be done on the database server in
> stored procedures/functions)

It's interesting and I can see how that would be useful but it seems to me that this is the kind of thing that seems great when you first start using it but causes all kinds of problems later on. It discourages thinking of the data on a high-level and creating a strategy for managing it. 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.

Flat View: This topic has 264 replies on 18 pages [ « | 11  12  13  14  15  16  17  18 | » ]
Topic: What Are Your Java Pain Points, Really? Previous Topic   Next Topic Topic: The Future of Online Dialog

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use