Disadvantages of Java!

Hi
I was looking for disadvantages of Java on the web (for Interview) and found following:
(1) Because programs written in Java language runs on a virtual machine, it runs somewhat slowly compared to other programs. However, it is unlikely that it feels annoyingly slow on today's fast computers.
(2) Rather, a worse problem is that the programs do not always work correctly even if they are written correctly, because a Java virtual machine may be written incorrectly. It is difficult to write a perfect program, especially if it is as big as a virtual machine, so that programs written in Java langauge tend to suffer from slightly different problems depending on the platforms on which the Java virtual machines run.
Are this really true? Can somebody pls explain a bit more or point me to any available links?
Advance Thanks

(1) Because programs written in Java language runs
on a virtual machine, it runs somewhat slowly compared
to other programs. However, it is unlikely that it
feels annoyingly slow on today's fast computers. Welcome to the 2001 century of programming languages--Java and .Net
(2) Rather, a worse problem is that the programs do
not always work correctly even if they are written
correctly, because a Java virtual machine may be
written incorrectly. It is difficult to write a
perfect program, especially if it is as big as a
virtual machine, so that programs written in Java
langauge tend to suffer from slightly different
problems depending on the platforms on which the Java
virtual machines run. Have you ever found a bug in your compiler, OS, debugger, DB or other program? I have even after numerous version releases too (The one I love is when your told by the 1st line support tech that: "It doesn't do that." As you are checking your 1000's case showing it does.)--it's very anoying, but it happens. It is very true that larger programs are more complex and each time there is a change, there is a chance for getting something wrong -- welcome to the real world of program development! (Much of the software released on the market today is not bug free--but is released with an "acceptable level of bugs".) This is true for the JVM, a compiler, interpreted languages, OS's and just about every thing that runs on a computer, including ROM's, and has been true since the very beginning.
So if you are looking at the "disadvantages" and thinking these are Java specific, think again and check out MS's bug logs, Sun's bug logs, IBM's bug logs, and any other large company's bug logs for their products. You will probably be at least supprised at what you find, if not mortified at some of the holes that were patched after the fact.

Similar Messages

Disadvantages of Java 1.5

Hi everyone,
can anyone please list down the issues, concerns, problems faced and disadvantages encountered while using java 1.5.

i do understand that in is used as reference for InputStream in many cases, im just trying to explain that the enhanced for loop is too much streamlined also i tried to do some decrement in for loop like
(i=1;i<10;i--) and --i using the enhanced for loop but im unable to get the result. is this another disadvanage or im doing wrongly. please help me.

Disadvantages/advantages JAVA vs PHP

Hello we are discussing why JAVA should be prefered for developing internet/intranet applications than PHP .
Could you give some reasons, e.g. MVC or security and so on?
Thanks a lot, Mario

Hi,
Java is familiar coz,
platform independence
robust
scalable
supports
OOPs
MVC
Security
JAAS
Lastly
"write once run anywhere"
This is not possible by any lanaguage till date inmarket.
Hope it helps.
Regards,
Guru

Java Mapping, XSLT Mapping, ABAP Mapping

Hi Experts,
Could any one explain what is the main features of the following Mapping. How to pick the mapping?
Java Mapping - When to use and what is the advantage.
ABAP Mapping - When to use and what is the advantage.
XSLT Mapping - When to use and what is the advantage.
Graphical Mapping - When to use and what is the advantage.
cheers,
Sunee

There are 4 types of mapping in XI
1. Graphical Mapping
2. XSLT Mapping
3. JAVA Mapping
4. ABAP Mapping
When to use Message mapping
1 When the logic for your mapping is simple and straight forward, you can use
Advantages of message mapping
1)Easy to use.
2) has GUI drag and drop.
3) used for simple mapping cases
4) it does not involve any complex logic
Disadvantages of message mapping
1)has limitation in terms of complex hierarchy
When to use Java mapping
1) Java mapping are used when graphical mapping cannot help you.
Advantages of Java Mapping
1)you can use Java APIs and Classes in it.
2) file look up or a DB lookup is possible
3) DOM is easier to use with lots of classes to help you create nodes and elements.
Disadvantages of Java mapping
1)SAX parser is not easy to develop
2)DOM parser is intensive
3) Java knowledge is required
4) bit complexer
XSLT Mapping - When to use
1)When the required output is other than XML like Text, Html or XHTML (html displayed as XML )
2)When default namespace coming from graphical mapping is not required or is to be changed as per requirements.
3)When data is to be filtered based on certain fields (considering File as source)
4)When data is to be sorted based on certain field (considering File as source)
5)When data is to be grouped based on certain field (considering File as source)
Advantages of using XSLT mapping
1)XSLT program itself defines its own target structure.
2)XSLT programs can be imported into SAP XI. Message mapping step can be avoided. One can directly go for interface mapping once message interfaces are created and mapping is imported.
3)XSLT provides use of number of standard XPath functions that can replaces graphical mapping involving user defined java functions easily.
4)File content conversion at receiver side can be avoided in case of text or html output.
5)Multiple occurrences of node within tree (source XML) can be handled easily.
6)XSLT can be used in combination with graphical mapping.
7)Multi-mapping is also possible using xslt.
8)XSLT can be used with ABAP and JAVA Extensions
Disadvantages of using XSLT mapping
1)Resultant XML payload can not be viewed in SXMB_MONI if not in XML format (for service packs < SP14).
2)Interface mapping testing does not show proper error description. So errors in XSLT programs are difficult to trace in XI but can be easily identified outside XI using browser.
3)XSLT mapping requires more memory than mapping classes generated in Java.
4)XSLT program become lengthier as source structure fields grows in numbers.
5)XSLT program sometimes become complex to meet desired functionality.
6)Some XSL functions are dependent on version of browser.
Advantages of Abap Mapping
1) A person comfortable with OOABAP can go for ABAP mapping instead.
Disadvantages of Abap Mapping
1) Abap knowledge is required
2) bit compexer
For further info on each of the mapping, refer to these links,
Graphical Mapping,
http://help.sap.com/saphelp_nw04/helpdata/en/6d/aadd3e6ecb1f39e10000000a114084/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/43/c4cdfc334824478090739c04c4a249/content.htm
XSLT Mapping
http://help.sap.com/saphelp_nw04/helpdata/en/73/f61eea1741453eb8f794e150067930/content.htm
http://www.w3.org/TR/xslt20/
Java Mapping
http://help.sap.com/saphelp_nw04/helpdata/en/e2/e13fcd80fe47768df001a558ed10b6/content.htm
DOM parser API
http://java.sun.com/j2se/1.4.2/docs/api/org/w3c/dom/package-frame.html
Check this blog on Mapping:
/people/ravikumar.allampallam/blog/2005/02/10/different-types-of-mapping-in-xi
Also, check this thread for more info,
Different types of Mapping in XI

Should we avoid Graphical mapping and stick with Java mapping?

After developing mappings in XI for a month, I just don't see any good reasons to use Graphical mappings over Java mappings. Maybe some experienced users here can give me some valid reasons why we should choose Graphical mappings. Here is what I think:
Disadvantages of Graphical mappings:
1. No way to perform automated unit testings. This is probably the biggest reason I hate it. You can do some tests manually when you work in Integration Builder. But there is no way you can write some unit testing utilities to automate the task.
2. Complexity. Even for some simple requirements, your Graphical mappings can become complicated and hard to understand. A lot of times, I find myself staring at several dozens of graphical nodes and try to understand what it does.
3. Impossible to reuse. This is totally against the DRY (Don't repeat yourself) principle. For example, to generate messages for JDBC adapter, it is common to have two identical fields for primary keys: one in the access node and another in the key node. If you change the mapping logic in one, you have to remember to change the other.
Advantage with Java mappings:
1. Fully automated unit testing. You can create JUnit tests along with your Java mapping classes and use Maven or other build tools to perform automated unit testing.
2. Your choice of XML parsing and binding. With Java mapping, you can choose any open source framework for XML parsing and binding. For example, with XMLBeans, I can convert XML input message to a Java object, transform to another Java object and write to output message. And each Java object is generated from its corresponding XML schema.
3. Highly reusable. We can use fundamental object-oriented designs to create highly reusable mapping components.
4. Better version control. Since the mappings are just Java classes, we can use CVS or SVN to track code changes.
5. Better build tools. We can fully utilize build tools like Ant and Maven to automate the build, unit tests, or even generate documents and mapping web sites.
So do you guys agree? Maybe I am still new to XI or I am missing some important things. But at this point, I just don't see why I should use Graphical mappings. Is there anyone developing XI interfaces completely with Java mappings?
Thanks in advance for any comments!
Kenny Cheang

Hi Suraj,
> Since its graphical the blocks will take space, but
> there is always an adavntage of processing time.
> Ebven though it may appear bigger, it will take less
> time as compared with Java code (for the same
> mapping).
Could you explain more why the graphical mapping has better performance? I thought the graphical mapping is compiled into a Java class in the runtime anyway.
> Yes thats there, but same goes with Java mapping too
> right (if you haven't mentioned it as constants)
I mainly think about inheritance. If I have to build 10 interfaces and they all have some common behavior, I can create a base interface class to encapsulate the common logic. But with graphical mapping, you have to duplicate them in each interface.
> Disadvantages of Java mapping:
> 1. Performance
Same as above. I just don't see why Java has worse performance. I actually think Java should have better performance. You can optimize the code anyway you want. In some cases, you have to use queue functions in graphical mapping but it's not necessary in Java.
> 2. All might not be well versed with Java Code(though
> everyone may know basic java) .
I am not asking everyone to abandon graphical mapping. I am just wondering which one is better when you have skills for both.
> 3. Lot of standard functions are available in GM
> which you can choose, but you have to remember the
> exact code for those in Java mapping.
You can create functions in Java too. All you have to do is to remember the function name.
Kenny

Advantages of JAVA???

I've been using java for doing my project work.
It a good PL i mean, but sometimes other Programming Language is effective in some other perspective.
Since i am new to the world of programming,
I hope to get some advise here.
for web development,
applications,
business world, and many more!!!
What is the hotest and popular PL that require in this
business world???

A word of advice: Never ask things like "What programming language/operating system/brand of mobilephone/etc is best?". You'll be triggering a Holy War.
And besides... what does "best" mean? If someone says "That thing is the best" I immediatly ask "Best at what?". Something can't be just "best"... it has to be best at something. It's like a World Champion. You can't just be "World Champion"... you have to be World Champion in a particular event.
When you are given the job to choose what is programming language is best... you choose the one that is best... at performing the job you want it to do. Depending what the job is, different languages will claim the title for best. Therefore it becomes your job to find the advantages and disadvantages of different languages and compare which has the most advantages and least disadvantages for what you want it to do.
Advantages of Java:
- Low cost.
- Large community support.
- Compile Once, run everywhere.
- It has among the most comprehensive API's and libraries available.
- Very "uniform". As a Java programmer you learn to regonize patterns in the language.
Disadvantages of Java:
- A memory-hogger. It uses lots and lots of memory, especially for large application.
- Requires a Java virtual machine to be installed.
- Performance is improving rapidly but it is still not up to par. You don't want to use Java for heavy number-crunching.
/Michael

Java application development on Mac OSX

Does anyone do Java application development on a Mac? I know that Mac has their own version of Java and I was wondering if there were any difficulties of Java development on a Mac. I'm considering a switch from Windows to Mac and want to evaluate how it will impact my Java development. I currently use Eclipse 3.2. What are the advantages and disadvantages of Java development on a Mac?
Thanks

I'm no Java3d expert but i'm quite sure java is slow on macs, as the java for mac technology is quite bad. Even 2d games with few sprites go slowly on my mac, it's a shame. However this might change as Apple is working quite hard on getting java to work properly, ( mainly because if java becomes popular the macs will lose their incompatibility problem! )

Java must be hardware integrated on standard PC's

We are working on Java Tech for 10+ years as I see the most disadvantage of Java is now ,
its still Virtual , for 10+ years of experience I've seen is , always hardware friendly software won the race like
OpenGL and DirectX on Graphics side.
Hardware compatible systems forces developers to use them as a standard more.
If OpenGL was just software layer , all people would do their own Engine.
But its stopping them to use they use them for best performance.
And for end users , they are happy because OpenGL hardware friendly and
that makes OpenGL very fast and make both end user happy.
Whats the lack of things on Java Tech ?
Its still Virtual Machine.
Java should be real machine on PC's !!!
As i read , AMD LWP will be released for .NET and Java VM
but in my opinion , it cant help Java for to be faster.
Java has IO and memory problem so how can these problems can be solved ?
In my opinion , if you implement simple Gigabyte i-RAM on 1 PC ,
http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180
You will see Java will run very fast startup time and class loads , image loading operation will be very fast !!!
That means on just IO operations java will be faster.
Yes but its not solving problem %100 , so ?
You should implement static caches for Java on PC's instead of making java on Operating System.
Some people know about UPNP ,
I've opened JUPNP project on dev.java.net :
https://jupnp.dev.java.net/
UPNP is now being used on hardwares of PC's on modems especially!
But i wished to see JXTA on ADSL and future of modems.
JXTA would be cool technology having all modems these tech.
UPHP doesnt have capabilities what JXTA has !
But it forces developers to use UPNP because all hardware modems have that Technology!
The most disadvantage of Java Swing Apps is ,
They all store their Swing Images on HDD ,
They also should be stored on GPU hardware.
Yes I've read Java can access on GPU too but i mean all swing images and object must be in seperate static cache of Graphics card so
when PC startup , they must be loaded on Graphics Card.
Java must have a classes that accesses,
MMX , SIMD capabilities of hardwares.
But they shouldnt be done on JNI !!!
JNI makes penalty calls , they sould be native instructions.
You should make new Generation of PC's having
static java caches like Gigabyte iRam
same iRam should be on Graphics adapter Swing too...
Maybe you say it will be expensive PC's but people paying 250$+ for DirectX compatible graphic hardwares!
think more how much cost iRam on Java/Swing Graphic Adapter or JXTA Compatible ADSL/Cable/?
If , these technologies will be done , i'm sure within 7 years Java will take place much and much more on markets!
Send Java and .NET Technologies to hell and as i read your all hardware servers is World's best ,
if you do same best hardwares for end users it will change destiny of Java/JavaFX.
Never think virtual , real machines!!!
PC's really important technology then any other technology to force people accept technologies!
Dont forget Java needs Fast IO Hardware System now!
Take care all Sun Group
Regards,
Kadir BASOL

WTF? It's hard enough to get people to download the latest JRE. How many folks do you think will be willing to go out and purchase a new "Java Card" for their PC every two years?

Java must be real hardware on PCs !

We are working on Java Tech for 10+ years as I see the most disadvantage of Java is now ,
its still Virtual , for 10+ years of experience I've seen is , always hardware friendly software won the race like
OpenGL and DirectX on Graphics side.
Hardware compatible systems forces developers to use them as a standard more.
If OpenGL was just software layer , all people would do their own Engine.
But its stopping them to use they use them for best performance.
And for end users , they are happy because OpenGL hardware friendly and
that makes OpenGL very fast and make both end user happy.
Whats the lack of things on Java Tech ?
Its still Virtual Machine.
Java should be real machine on PC's !!!
As i read , AMD LWP will be released for .NET and Java VM
but in my opinion , it cant help Java for to be faster.
Java has IO and memory problem so how can these problems can be solved ?
In my opinion , if you implement simple Gigabyte i-RAM on 1 PC ,
http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180
You will see Java will run very fast startup time and class loads , image loading operation will be very fast !!!
That means on just IO operations java will be faster.
Yes but its not solving problem %100 , so ?
You should implement static caches for Java on PC's instead of making java on Operating System.
Some people know about UPNP ,
I've opened JUPNP project on dev.java.net :
https://jupnp.dev.java.net/
UPNP is now being used on hardwares of PC's on modems especially!
But i wished to see JXTA on ADSL and future of modems.
JXTA would be cool technology having all modems these tech.
UPHP doesnt have capabilities what JXTA has !
But it forces developers to use UPNP because all hardware modems have that Technology!
The most disadvantage of Java Swing Apps is ,
They all store their Swing Images on HDD ,
They also should be stored on GPU hardware.
Yes I've read Java can access on GPU too but i mean all swing images and object must be in seperate static cache of Graphics card so
when PC startup , they must be loaded on Graphics Card.
Java must have a classes that accesses,
MMX , SIMD capabilities of hardwares.
But they shouldnt be done on JNI !!!
JNI makes penalty calls , they sould be native instructions.
You should make new Generation of PC's having
static java caches like Gigabyte iRam
same iRam should be on Graphics adapter Swing too...
Maybe you say it will be expensive PC's but people paying 250$+ for DirectX compatible graphic hardwares!
think more how much cost iRam on Java/Swing Graphic Adapter or JXTA Compatible ADSL/Cable/?
If , these technologies will be done , i'm sure within 7 years Java will take place much and much more on markets!
Send Java and .NET Technologies to hell and as i read your all hardware servers is World's best ,
if you do same best hardwares for end users it will change destiny of Java/JavaFX.
Never think virtual , real machines!!!
PC's really important technology then any other technology to force people accept technologies!
Dont forget Java needs Fast IO Hardware System now!
Take care all Sun Group
Regards,
Kadir BASOL

WTF? It's hard enough to get people to download the latest JRE. How many folks do you think will be willing to go out and purchase a new "Java Card" for their PC every two years?

Disadvantages of Reflection

I want to use Java Reflection api, but I want to know disadvantages of this ap. İs there any disadvantages of Java reflection api ? If yes, where are these?
thnx -

Somethings come to mind.
Security: Example: Access modifiers to fields, methods etc can be bypassed by Reflection.
Safety: Example: you can modify immutable instances with possible disastrous results.
The unexpected always happens: you can rely on your Reflection code to do exaclty what you want it to do, as you don't necessarily know what you want the reflection operations to do the unexpected can and will happen.
Abstraction: Working with reflection can be confusing, you are working with Objects and Classes all the time. Doing useful things with Reflection takes thought and care.
Big Advantage: You can achieve just about everything with Reflection you want to acheive.

RE: (forte-users) RE: Forte' vs J2EE

Hi Alexandra,
1) Forte 4GL and FJEE (Forte for Jave Enterprise Edition) are tools.
2) TOOL and Java are languages.
3) TOOL is proprietary and Java is public.
4) J2EE is a proposed, Java-based achitecture. Not a tool, not a language,
not a standard.
5) J2EE looks a lot like the architecture already supported by Forte 4GL,
however J2EE is explicetaly based on Java, EJB, JSP, JDBC and Servlets.
There are 3 versions of Forte for Java. The "Consumer Edition (CE)", the
"Internet Edition (IE)" and the "Enterprise Edition (EE)". CE is really a
remake of "NetBeans" and can be downloaded for free. IE and EE do not exist
yet. However, EE should be a remake of SynerJ, Forte's first Java tool.
You quoted someone who was very negative about Forte. I don't think that's
deserved. He's probably someone who simply didn't manage to understand the
tool. However, he is right in complaining about the support of Forte 4GL.
And it's true that the version people are currently using is at least more
than 2 years old and outdated. Since this period, there have been some
bugfixes, but hardly any real improvements.
From the description of your application, I would really advise to use Forte4GL. However, the lack of improvements, new releases, press releases, etc.
has me worried about the future of that product.
One of the real disadvantages of Java is performance. Java is very slow and
requires very heavy hardware to perform acceptably. Swing is a GUI framework
based on Java, which is notoriously slow even by Java standards. FJCE
development GUI is based on Swing. Download this product, install it and run
it and you'll see what I mean.
Forte applications can run in 2 modes. Interpreted or compiled. If they're
compiled, they're turned into platform dependent executables, which perform
really well. If they're interpreted, they're running inside a Forte Virtual
Machine, which performs less well, but still very acceptable. Java
applications run only in Java Virtual Machines and perform far less.
I would use Forte server side and Forte client side. For the browsers, I
would simply use any available tool to build webpages and use CGI to
interface with Forte. I would not try to use a different client side tool
that should communicate to a Forte server side.
Express is a good tool for developing CRUD (Create Read Update Delete)
applications based on an existing, and relatively static, database model. I
don't know about Rapport. However, don't be fooled into believing that
Express makes it easier for unexperienced developers to build Forte
applications. If anything, it makes it harder. A common look and feel can
easily be achieved by agreeing on the look and feel of windows during the
design-phase, and have all developers conform to this standard. It really
isn't that hard. Just don't create very large window class trees. That
causes strange behaviour.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Alexandra Macedo [mailto:ammeasysoft.pt]
Sent: Tuesday, December 05, 2000 3:55 PM
To: forte-users
Subject: (forte-users) RE: Forte' vs J2EE
Alexandra I presume.
Excuse me for asking but isn't J2EE just a STANDARD? And Forte aprogramming
language that may or may not adhere to that standard?
Now to the question, if the C++ experience is good - what's wrong withusing
C++?
Do you need to build component based distributed systems? Then hire saytwo
experienced architects - to design a practical model (UML perhaps).
Are there already good systems around you could tailor for your needs?
Just a few questions that need to be addressed to make an informeddecision.
What business are you in (your team/company)? If it's not IT then ask
yourself why do it inhouse?
Regards,
Dirk
PS: What country and from where is the Forte support? You mean peoplecode
in a language other than English?----------------------------------------------------------------------
Well, Forté is certainly not a programming language, TOOL is the
language for the Forté 4GL environment.
J2EE is a standard, and there are already some Application servers
that
implement it (as I was told, webSphere, Iplanet and weblogic,
sorry if I am missing someone).
I really do not know the standard, and I am not sure it says it will
have to be implemented in Java, but all these 3 application servers
do it in Java...
The C++ experience is only from part of the team, and is not from
Database applications, the type of application we are doing is not
well suited to do in C++, we all agree, C++ is out of the question.
I have received many answers (not posted in this mailling list
unfortunatly) telling me that Java is best, others told me Forté is
good Java is just a promise, but they really did not know Java
very well, someone even said:
Forte 4GL sucks terribly. It is not supported well by what
is left of 'Forte the company'.
The tools for this proprietary environment suck.
No distributed debugging or profiling!
There is really no adequate profiling support at all
Avoid Forte like the plague that it is.
Any way, a Forté person told us that Forté is good, precisely, for
our kind of application, and as some people made more questions about
it, I am explaining better our application:
- We are doing this application because we are an IT company, our
job is to make and sell back-office applications for the finance
sector (accounting, third-party, bank management, credit
management), now we want to make one application with all of these.
In simple terms we can define it as an ERP for Credit Operations.
- The users will be in-house except for a small set of
functionalitty, which will be available through browsers.
The front-end should run in an ordinary PC running WINDOWS (we
were told that Java is too heavy and PC's should have at least 256Mb
RAM, which, I believe, is to much for all our clients)
If this is true, it puts Java clients (with Swing) or Java applets out,
HTML, we believe is not powerfull enough for all the interface.
The server, will have to work well with about 300 simultaneous
internal users, plus some Web ones (do not know how many)
The application must be multi-lingual, that is, it should be easy to
put it in any language.
The application is based on a big database, with more than 500
tables, some with about 100 columns, some with millions of records.
- We want to be sure that the application will have the same layout
(look and feel) in every screen, so it will be nice something to
generate code or to create similar functionality (table screens,
for instance) in an automatic way ( that is why we are considering
Express for it). Of course this will help also the maintenance of
the sources.
Our questions are:
FORTÉ or JAVA for the server-side.
Which tool for the client-side?
Which framework to use?
-Express or Rapport from albion if using Forté?
-Are there any good frameworks for Java ?
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Gabriel,
I disagree with you on one very important point. You say it's nearly
impossible to predict anything about the future in ICT-world, so it's better
to not predict at all and only look at the here and now. Here and now, Forte
is better than Java. So, the best choice would be Forte.
But you also mention that Forte is best suited for big projects. Big
applications usually have a long lifetime. Many of the current Forte
applications are the legacy systems of tomorrow. While all the VB, Access,
ASP and Java crap that's being produced will be replaced within 6 to 18
months, Forte applications will live for years.
Migrating such large applications to a new environment, even if this
environment is using a similar technology, requires very high investments.
Companies will want to avoid this as much as possible. So, they'll want to
invest in technology that can evolve with the rest of the world. As
operatingsystems change, databases change, middleware architectures become
obsolete (DCE) and new ones are created (EJB), end user interfaces evolve
(from text to GUI to Web), requirements change (data-oriented,
process-oriented, eCommerce), etc.
Of course, flexibility is not only achieved through technology. A good
design is probably more important.
Managers, not developers, will have to make the strategic decisions about
where to spend their millions. So, they have to look at the future, no
matter how hard that is. At the moment, Forte is still superior, even though
it hasn't been truly improved for over 2 years and that's pretty impressive.
Java is still very "hyped" and no one knows what's going to happen to it.
But the future of Java looks much brighter than the future of Forte. If
Forte doesn't put some serious effort in product development and marketing,
like now, the future of this product suite looks very bleak indeed. And I
wouldn't want to spend my millions knowing I have to do it all over again 2
years from now.
Keeping an eye on the future, where the only certainty is change, I would
not focus on platform independance. I would focus on language independance.
CORBA seemed like a very good idea 2 years ago, but it turned out to be too
complex, technical and inflexible. I would definately go for a CBD
architecture, using XML as backbone. XML can be exchanged between components
using HTTP, CORBA, DCOM, FTP, file copy, DCE, C/C++ call in/out, RMI, IIOP,
E-mail, MQSeries, etc. etc. Or any mixture of these systems.
The role of the data architect will become much more important than the role
of the application architect. The choice for a language or tool is reduced
to "the best choice here and now" as long as you design your large
application as loosly coupled components. It's OK if all of these components
are Forte and they're all communicating using Forte native RMI's. As long as
the design is sound, it's not going to be very difficult to exchange
individual components by others, built in Java, VB, Perl, Cobol++, Fortran
for Windows, or what other monsters the future might bring. The only thing
that binds them, is the datamodel (NB: datamodel is not the same as
databasemodel)
I do worry about the trend to use very large, omni-present, closed,
non-component architectures, like the current ERP applications. This locks
organisations into a single, expensive and hard to maintain technology.
However, it is an opportunity for us, OO - C/S - CBD developers, to build
bridges, adapters, wrappers and gateways to hook these systems into the rest
of the organisation.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Gabriel, C200/Fa. GFT, DA [mailto:A.Gabriel3deutschepost.de]
Sent: Wednesday, December 06, 2000 5:44 PM
To: 'forte-userslists.xpedior.com'
Subject: Re: (forte-users) RE: Forte' vs J2EE
If I were you, I would also consider this very important issue ( I think
it's the same for all 4GL users ), WILL THERE BE FORTE 4GL 5.0?I wonder every time I see that... Why is this that important?
(my mail is long.. if you don't like long mails, delete it now :) )
Let's see from the business' point of view:
If you would like to have an application implemented now,
use now, then you choose an environment existing now.
Now Forte 4GL seems to be a better alternative than Java,
because of the issues mentioned by others already.
I seem to be short-sighted, but could anybody tell me
with 100% accuracy, what will happen to Java in two years?
I doubt...
Forte did not changed too much in the last two years, and
still rocks, at least compared to other existing enterprise
level alternatives. So, nothing has changed that dramatically.
If you look behind the marketing-hype, you will probably agree.
I think, for the next two years Forte will be good enough for us too.
And what then? We will find out then, not now. Anybody, who tries to
explain you what will be in two years in the IT, almost certainly lies :)
Of course, using a "two years old technology" is not that cool from the
marketing point of view, but you use a solid technology, most likely
bug-free,
or at least having only known bugs. That is technically important!
If you ask about investment protection ... ?
Forte is very good in this subject too. If you look at it, you will see, it
is
sold as an integration solution (Fusion, Conductor, etc...)
If something is sold as an integration tool, it should be not that difficult
to
integrate :) Forte supports the most important standards, existing now.
If your future system supports it (it should), it will be easy to upgrade to
it,
using the existing product,know-how, etc... Probably without noticeable
downtime.
Scalability issues: Forte scales well from big to very-big to ultra-big.
What is big, you have to decide :)
For example, one million mails per day is not big. :)
For small businesses Forte isn't good. Java is. And a lot of other
environments
are, for example Perl, Python, etc...
My personal opinion is that our future will be heavily influenced by free
software.
They are very good already, and will be only better.
As Forte evolves, one important step would be to port it to free (and thus
independent)
OS's and DB's like Linux or FreeBSD and Postgres or Mysql. Even without
warranty!
I can't see what Sun's goal is with Forte, maybe they wouldn't
like this idea at all, since that may be the market segment what their Java
is thought for.
But that would be the perfect investment production as the company grows,
they don't have
to do anything to the software, just buy machines, and play around in
Environment Console :)
From the personal point of view:Although I don't work with Forte in the moment, I did this till last year,
and I will do
that in the next year too :)
If you would like to protect your "investment" and/or "market value" then
try to learn
platform and language independent things. I think, knowing Forte is 25%
platform dependent
knowledge (so useless anywhere else) and 75% platform independent. Using,
analysing, designing,
programming, and living OO is absolutely platform independent.
Project (and self-) management, presentation techniques, design and
documentation practices, version
and revision management, and so on, they are all platform independent.
Furthermore if you quit the Forte world, and have to program f.e. Java, you
will learn it in weeks.
JFC, Swing, et. al. are nothing, if you know OO. You just need a book or
an online manual, and you
can write programs in the first week. You will have much more problems with
the working environment,
and you will wonder, how the others can use that crap... after the smart
Forte IDE :)
Back to business a bit:
One big advantage of Forte, that came to my mind right now is that you can't
(ok, you can, but it is
difficult) to write bad OO programs (and designs). In Java, it is too
easy... believe me, I saw some examples ... :)
Sorry for the bad english and the long mail...
Best regards,
Akos Gabriel
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

[svn:cairngorm3:] 21199: Maven Tests failing for unkown reason:

Revision: 21199
Revision: 21199
Author:   [email protected]
Date:     2011-05-04 01:08:33 -0700 (Wed, 04 May 2011)
Log Message:
Maven Tests failing for unkown reason:
https://bugs.adobe.com/jira/browse/CGM-60
Ticket Links:
    http://bugs.adobe.com/jira/browse/CGM-60
Modified Paths:
    cairngorm3/trunk/libraries/NavigationParsley/pom.xml

Hi Suraj,
> Since its graphical the blocks will take space, but
> there is always an adavntage of processing time.
> Ebven though it may appear bigger, it will take less
> time as compared with Java code (for the same
> mapping).
Could you explain more why the graphical mapping has better performance? I thought the graphical mapping is compiled into a Java class in the runtime anyway.
> Yes thats there, but same goes with Java mapping too
> right (if you haven't mentioned it as constants)
I mainly think about inheritance. If I have to build 10 interfaces and they all have some common behavior, I can create a base interface class to encapsulate the common logic. But with graphical mapping, you have to duplicate them in each interface.
> Disadvantages of Java mapping:
> 1. Performance
Same as above. I just don't see why Java has worse performance. I actually think Java should have better performance. You can optimize the code anyway you want. In some cases, you have to use queue functions in graphical mapping but it's not necessary in Java.
> 2. All might not be well versed with Java Code(though
> everyone may know basic java) .
I am not asking everyone to abandon graphical mapping. I am just wondering which one is better when you have skills for both.
> 3. Lot of standard functions are available in GM
> which you can choose, but you have to remember the
> exact code for those in Java mapping.
You can create functions in Java too. All you have to do is to remember the function name.
Kenny

What's disadvantages when using bind variables always in java?

Hello everyone .. Could someone tell me what's the disadvantage when using bind variable in java ? I heard it somecases since before.. Thanks in advance!

99% of the time, you should be using bind variables. If you have columns which are highly skewed, however, you may want to consider using literals (assuming CURSOR_SHARING=EXACT), since that may allow the CBO to make a better decision.
If you have an orders table, for example, you may have a status column that specifies whether the order is complete, in transit, or new. If you've been running for a while, 99% of your orders will be complete, so
SELECT COUNT(*)
FROM orders
WHERE status = :1should do a full table scan if you specify 'COMPLETE'. If you passed in 'IN TRANSIT', though, an index scan might be more appropriate. If you want to pass in different values and get different query plans, you need to use literals. 99% of the time, though, you want the same plan, so you want to use bind variables.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Java reflection - any disadvantages

1. Are there any disadvantages in using java reflection api (too much)?
2. How do obfuscators deal with reflection based applications?
Thanks
Santosh

Sorry, i wanted to know how the code
Object obj = new MyClass();
is different from
Class clazz = Class.forName("MyClass");
Object obj = clazz.newInstance();
at the byte-code level.
That is, in both the cases the classloader has to
search for MyClass and invoke the constructor. Hope I
am clear :)I don't think there is any difference as far as performance is concerned between the above mentioned methods for instantiating the object of MyClass.
But here is what is generally said about using reflection(u can find it on google):
===============================================================
Don?t overuse the Reflection API. Programs that use it are more difficult to understand and maintain. In addition, accessing fields and calling methods through the Reflection API is slower than using them in the ?normal? way, so use reflection only when it is really necessary.
===============================================================
We too had concerns about reflection's performance, but as long as you cache the lookups, reflection is very fast. What is slow is doing things like looking up a method on a class or looking up an instance member. We do all these lookups once and then cache the results.
===============================================================
Why is it slow as stated above? - Maybe because flexibility always comes at a price !!! Maybe the internal implementation of the call sequence by the JVMs is such that it cannot be implemented any faster...

Advantages and Disadvantages of webdynpro JAVA over J2ee?

Hi,
Can anybody provide me the advantages and disadvantages of webdynpro java over the J2EE?
Regards,
Harish.

Hi,
Webdynpro is the SAP standard technology for developing business user intrefaces.
Webdynpro is like the frame work which follows the MVC Design pattern.
Webdynpro uses most of the UI developement as declarative approach , i.e. most of the code will generated by the framework. so it will reduce the developement efforts.
Adaptive RFC model to connect with SAP systems.
All these are advantages over than the J2ee.
Regards,
Naga

Disadvantages of Java!

Similar Messages

Maybe you are looking for