Java Runtime Question

Is there any reason why IDEA requires the stock JRE supplied
with the product? Are you instrumenting the Java Classes or something?
If not, is there anything wrong with using the installed JRE if it is
the proper version?

You can examine the version of the installed Java runtime in a number
of ways:

  • Examine the Registry

  • Run "java -version" and parse the results. on my machine I get:


java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

  • Run a sample Java program to output the value of the "java.version"

to the installer. Something like this would work:

public class Main {
public static void main(String[] args) {
System.out.println(System.getProperty("java.version"));
}
}


No matter how you determine it, you can evaluate whether the JVM is
sufficient for IDEA. From there, you can always have the installer
install a different version if necessary.

It's just annoying to have to have a duplicate JRE of something I already
have installed. The version info from my installed JRE and the one included
with IDEA is identical.

53 comments
Comment actions Permalink

Please search this newsgroup. There were lot of long discussions about this
topic.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"

"Berin Loritsch" <bloritsch@d-haven.org> wrote in message
news:blet5v$n70$1@is.intellij.net...

Is there any reason why IDEA requires the stock JRE supplied
with the product? Are you instrumenting the Java Classes or something?
If not, is there anything wrong with using the installed JRE if it is
the proper version?

>

You can examine the version of the installed Java runtime in a number
of ways:

>

  • Examine the Registry

  • Run "java -version" and parse the results. on my machine I get:

>

java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

>

  • Run a sample Java program to output the value of the "java.version"

to the installer. Something like this would work:

>

public class Main {
public static void main(String[] args) {
System.out.println(System.getProperty("java.version"));
}
}

>
>

No matter how you determine it, you can evaluate whether the JVM is
sufficient for IDEA. From there, you can always have the installer
install a different version if necessary.

>

It's just annoying to have to have a duplicate JRE of something I already
have installed. The version info from my installed JRE and the one

included

with IDEA is identical.

>


0
Comment actions Permalink

Valentin Kipiatkov (JetBrains) wrote:

Please search this newsgroup. There were lot of long discussions about this
topic.


I can't see any real resolution to these long discussions, other than
JetBrains not considering what I thought were very intelligent arguments
in favor of using a working JRE if it exists.

In short:

  • I have a 20 GB hard drive shared with MS Windows XP, Visual Studio.NET

(say goodbye to half my harddrive right there), IDEA, Cygwin (full install),
my MP3s (80 hours worth), all the crap that IDEA generates in my user
directory, MS Office, other applications, and Linux. Pretty crowded, eh?

  • I am very resistant to extra cruft when it is an exact duplicate of what

I already have installed on my system. The 1.4.2 JRE is roughly 20 MB when
downloaded from Sun. Every little bit hurts.

  • Bug fix releases can solve some serious issues--some of which will affect

IDEA. By not allowing the user to specify their own JRE or use an existing
compatible JRE you will incur the support requests you were trying to avoid.
BTW, 1.4.2_01 is out now (bug fix release).

Lastly, I saw a way to modify the VM to use, which I might take advantage of.
Anyway, I'm not going to belabor the point.

0
Comment actions Permalink
  • Bug fix releases can solve some serious issues--some of which will affect

IDEA. By not allowing the user to specify their own JRE or use an
existing
compatible JRE you will incur the support requests you were trying to
avoid.
BTW, 1.4.2_01 is out now (bug fix release).

But these will be replaced by support requests for bugs introduced in
newer untested versions.

0
Comment actions Permalink

Nathan Brown wrote:

>> * Bug fix releases can solve some serious issues--some of which will
>> affect
>> IDEA. By not allowing the user to specify their own JRE or use an
>> existing
>> compatible JRE you will incur the support requests you were trying
>> to avoid.
>> BTW, 1.4.2_01 is out now (bug fix release).


But these will be replaced by support requests for bugs introduced in
newer untested versions.


?! Huh?

The difference between 1.4.2 and 1.4.2_01 is bug fixes only.
It is not like the difference between 1.4.1 and 1.4.2, an upgrad path
I can understand would be cautious about.

Heck, if IDEA was Java WebStart enabled, we wouldn't be having this
discussion because the JRE issues would be handled for us. IDEA would
have the JRE they want, and I won't be stuck with duplicate JREs on
my crowded 20GB laptop and 56kb modem. (I use my connection at work
to update IDEA).

0
Comment actions Permalink

So you think it is out of the question that a new bug could creep into a
bugfix release? And what about workarounds for bugs that suddenly break
when the bug is fixed? AFAIUI, the main concern for Jetbrains is
AWT/Swing - it is notoriously version sensitive and strange things are
always happening between releases.

N.

Berin Loritsch wrote:

Nathan Brown wrote:

>>> * Bug fix releases can solve some serious issues--some of which will
>>> affect
>>> IDEA. By not allowing the user to specify their own JRE or use an
>>> existing
>>> compatible JRE you will incur the support requests you were trying
>>> to avoid.
>>> BTW, 1.4.2_01 is out now (bug fix release).
>>
>>
>> But these will be replaced by support requests for bugs introduced in
>> newer untested versions.
>>


?! Huh?

The difference between 1.4.2 and 1.4.2_01 is bug fixes only.
It is not like the difference between 1.4.1 and 1.4.2, an upgrad path
I can understand would be cautious about.

Heck, if IDEA was Java WebStart enabled, we wouldn't be having this
discussion because the JRE issues would be handled for us. IDEA would
have the JRE they want, and I won't be stuck with duplicate JREs on
my crowded 20GB laptop and 56kb modem. (I use my connection at work
to update IDEA).


0
Comment actions Permalink


"Berin Loritsch" <bloritsch@d-haven.org> wrote in message
news:blf27j$gic$1@is.intellij.net...

The difference between 1.4.2 and 1.4.2_01 is bug fixes only.
It is not like the difference between 1.4.1 and 1.4.2, an upgrad path
I can understand would be cautious about.


I do not remember details, but one of examples of "version lock" is that
intellij guys had to use some hacks using "buggy" JVM, and in the "fixed"
JVM they could not use neither proper interface, which still was buggy, nor
"fixed" loopholes, which they previously used for hacks. Something like
that.

Bottom line: JVM has bugs and intellij are forced to use hacks to make
things work instead of using published API. But I agree that if you have the
same exact version of JDK, then IDEA could use yours. Or just ask during
the installation something like: "JVM found was not tested by JetBrains, do
you want to install bundled JVM?". In that case everybody would be happy.


0
Comment actions Permalink

Edit your idea.lax file (or idea.bat, or idea.sh), change the JRE home to whatever you like, and add -Didea.no.check.jdk=true to the JVM options. Make sure the 'tools.jar' file is in the classpath.

But if you do so, don't bother to ever post a bug report that's slightly related to the virtual machine. JetBrains folks bundle the JRE for a good reason, and is to avoid dealing with different versions of the JVM.

Believe them: the JVM is buggy, and there's lots of workaround code in IDEA. By constraining users to a single JRE, JetBrains folks are making sure their workarounds really work.

0
Comment actions Permalink

Marcus Brito wrote:

Edit your idea.lax file (or idea.bat, or idea.sh), change the JRE home to
whatever you like, and add -Didea.no.check.jdk=true to the JVM options. Make
sure the 'tools.jar' file is in the classpath.

But if you do so, don't bother to ever post a bug report that's slightly
related to the virtual machine. JetBrains folks bundle the JRE for a good
reason, and is to avoid dealing with different versions of the JVM.

Believe them: the JVM is buggy, and there's lots of workaround code in
IDEA. By constraining users to a single JRE, JetBrains folks are making sure
their workarounds really work.



Almost begs the question if they will ever use SWT...

0
Comment actions Permalink

Why? This would trade one set of bugs for another another. At least
They've already got the workarounds for Swing. (not to mention the
effort needed for migrating the UI)

0
Comment actions Permalink

dimiter wrote:

Why? This would trade one set of bugs for another another. At least
They've already got the workarounds for Swing. (not to mention the
effort needed for migrating the UI)


Just a thought.

There are some advantages:

  • SWT is open, and it is easier to get those bug fixes into SWT as opposed

to having to work around it like Swing.

  • It is designed with IDEs in mind (i.e. designed with Eclipse in mind).

  • Can use the same version of SWT accross supported versions without breaking

the application.

Granted there are disadvantages as well that you identified.

However, it makes the whole issue of which JRE to package a moot point.

0
Comment actions Permalink

http://www.eugenebelyaev.com/begblog/java/000039.html
http://www.eugenebelyaev.com/begblog//000041.html

Berin Loritsch wrote:

dimiter wrote:

>> Why? This would trade one set of bugs for another another. At least
>> They've already got the workarounds for Swing. (not to mention the
>> effort needed for migrating the UI)
>>


Just a thought.

There are some advantages:

  • SWT is open, and it is easier to get those bug fixes into SWT as opposed

to having to work around it like Swing.

  • It is designed with IDEs in mind (i.e. designed with Eclipse in mind).

  • Can use the same version of SWT accross supported versions without

breaking
the application.

Granted there are disadvantages as well that you identified.

However, it makes the whole issue of which JRE to package a moot point.


0
Comment actions Permalink
  • It is designed with IDEs in mind (i.e. designed with Eclipse in mind).


SWT has nothing to do with IDEs actually. Moreover, complex dynamic UIs are
either impossible or really hard to create with SWT. Swing offers ways more
flexibility in designing great user interfaces than SWT does.

>

  • Can use the same version of SWT accross supported versions without

breaking

the application.


In SWT you get a few nice native user interface controls for free, if
something goes out of this scope it is very hard to implement. Swing is the
opposite, you get crappy controls but if you invest in implementing your
custom components you get outstanding UIs which is in fact much more
responsive and feature rich than the native one. Swing is not simply a
control library but (given that it's based on AWT) it is a
component-oriented user interface framework, which includes features for
rendering, event handling, etc.

Here are a few points why Swing is not the best solution:

1) since it's purely light-weight framework it does not reuse native
optimizations any operating system does anyway, which makes Swing controls
perform slower than native ones in some cases
2) it does not do a really good job in looking and behaving just like the
native UI. Actually behavior is far more important for users than the look.
3) instead of having simple raw controls and then building a complex MVC
layer on top of it, they went a different way by making the core
architecture MVC by design which is too heavy for simple purposes,
prototyping and GUI builders
4) it does not really allow for good integration with heavy-weight controls,
tons of problems when you are trying to mix them together

Here are a few points why Swing is a nice solution:

1) You are fully controlling the rendering process which makes it possible
to implement double-buffering per control which makes a good way to greatly
optimize performance of custom controls. Native optimizations work only
with screen regions, not controls.
2) Pluggable look-and-feels is an awesome idea (though not implemented by
Sun good enough)
3) A lot of good ways to customize controls, like custom tree and list
renderers, borders
4) You can easily move components around any way you want

So the conclusion is that neither SWT nor Swing are ideal. The fact that
Eclipse is based on SWT means that Eclipse itself or any product which is
like Eclipse can be implemented using SWT (in fact, they told it themselves
that they had a lot of really hard time implementing some features using
SWT). I can even guarantee that if write a precise copy of IDEA but using
SWT, it will perform much slower than it is right now.

Eugene

"Berin Loritsch" <bloritsch@d-haven.org> wrote in message
news:blf4hu$sml$1@is.intellij.net...

dimiter wrote:

>

Why? This would trade one set of bugs for another another. At least
They've already got the workarounds for Swing. (not to mention the
effort needed for migrating the UI)

>

>

Just a thought.

>

There are some advantages:

>

  • SWT is open, and it is easier to get those bug fixes into SWT as opposed

to having to work around it like Swing.

>

  • It is designed with IDEs in mind (i.e. designed with Eclipse in mind).

>

  • Can use the same version of SWT accross supported versions without

breaking

the application.

>

Granted there are disadvantages as well that you identified.

>

However, it makes the whole issue of which JRE to package a moot point.

>


0
Comment actions Permalink

Almost begs the question if they will ever use SWT...


Do you have a vague idea, how much this will cost for no benefit? Don't
start a flame war Swing/SWT. IDEA runs with Swing - period.

Tom

0
Comment actions Permalink

I guess, it's approx. the same cost as turning a normal
Win32-/Windows-application into a Linux-/Unix-application, but opposed
to this example, it has no real value to the customer.

Tom


0
Comment actions Permalink

Welcome Eugene! :)
Nice to see you after rest (if it can be called so)

I see at SWT and Swing, and my point that SWT is very-very platform depended
solution. Is better if you develop under one platform, but no good for
crossplatform development.

If i right undertand it, the SWT using API function for CREATING system
controls by using system function. It communicate throught control by using
system messages.
The Swing as i know get from system only ability to draw - for DRAWING
control. Swing only get direct draw surface and draw in this context using
simple drawing algorithms.

That why SWT work faster taht Swing. But my point of view, SWT can't support
one interface look over more platforms. For example Windows have standard
control window - Button, sure MacOS and unixs have similar control - here no
probles for SWT, but if Windows have control for floating toolbar menu, then
it can be expected in some unix or MacOS system. Then SWT mus have seft
realization of such components under this system.
For Swing it no matter that kind of control - it just paint it on any
platform.

Correct me if i wrong.
Thanks!

--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com


0
Comment actions Permalink

Thomas Singer wrote:

>> Almost begs the question if they will ever use SWT...


Do you have a vague idea, how much this will cost for no benefit? Don't
start a flame war Swing/SWT. IDEA runs with Swing - period.


I think you read too much into that, dude. It was just a musing. The
official response from JetBrains clarified the issue for me. That's good
enough.

0
Comment actions Permalink

-Didea.no.check.jdk=true does not work with latest EAP

0
Comment actions Permalink


"Alexey Efimov" <aefimov@spklabs.com> wrote in message
news:blgov3$p67$1@is.intellij.net...

But my point of view, SWT can't support
one interface look over more platforms. For example Windows have standard
control window - Button, sure MacOS and unixs have similar control - here

no

probles for SWT, but if Windows have control for floating toolbar menu,

then

it can be expected in some unix or MacOS system. Then SWT mus have seft
realization of such components under this system.
For Swing it no matter that kind of control - it just paint it on any
platform.


Hence the whole industry of Windows custom controls, which were very popular
5-8 years ago. Remember BWCC or custom sliders or up/down boxes "Win95
style", then floating toolbars, etc. CreateWindow + WM_PAINT. Custom
reports, for example, are still done as custom controls. I just do not know
how easy/hard is it to create similar controls on other systems.

The key benefit is not the redraw speed, but the fact that controls are
native. That means, that they support features like third mouse button or
mouse wheel or drag-and-drop or color scheme... _They not only look visually
native, they behave native_

There are two basic strategies: either create uniform interface and its
unifrom implementation (Swing), or create interface, that would allow the
application to run on different platforms, and to use each particular
platform at its full (SWT is closer to that). And the nice thing is that one
can get a lot of useful native features without any programming, they are
already supported by native controls.

Michael Jouravlev.


0
Comment actions Permalink


"Thomas Singer" <idea@NOregnisSpam.de> wrote in message
news:blgo27$drb$1@is.intellij.net...

I guess, it's approx. the same cost as turning a normal
Win32-/Windows-application into a Linux-/Unix-application, but opposed
to this example, it has no real value to the customer.


Kylix ?


0
Comment actions Permalink

The key benefit is not the redraw speed, but the fact that controls are
native. That means, that they support features like third mouse button

or

mouse wheel or drag-and-drop or color scheme... _They not only look

visually

native, they behave native_

>

Native functions is very depend on host system. Lets look at simple example:
If Windows support clipboard operation for text control, then you reuse by
SWT native code in your application - you not think about left-click-popup
menu with Copy, Cut, Paste operation - it implemented already by Win32. But
if you don't implement this on Windows, you must implement it on system
where text control not provide such option. Is it good? I think no.
From other side: Swing not show popup menu, but JTextField have keystroke
for CtrlC, CtrlV and Ctrl+X. And this must work on any system, not only
for Windows.

So, i think that OS system must provide faster draw interface and
application (if it called as crossplatform) must not use native interface,
but must render controls. The logic is simple - if you have one interface
look on different systems, you have the same keystrokes, you have one manual
about using your GUI over any OS, and, finaly, you haven't any troubles with
supports or not supports some native code on some OS.

Thank you!
--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com


0
Comment actions Permalink

Alexey Efimov wrote:


Native functions is very depend on host system. Lets look at simple example:
If Windows support clipboard operation for text control, then you reuse by
SWT native code in your application - you not think about left-click-popup
menu with Copy, Cut, Paste operation - it implemented already by Win32. But
if you don't implement this on Windows, you must implement it on system
where text control not provide such option. Is it good? I think no.
From other side: Swing not show popup menu, but JTextField have keystroke
for CtrlC, CtrlV and Ctrl+X. And this must work on any system, not only
for Windows.


I think you missed the point. The point is that the controls behave the way
a user from that operating environment would expect it to operate. Every
time.


So, i think that OS system must provide faster draw interface and
application (if it called as crossplatform) must not use native interface,
but must render controls. The logic is simple - if you have one interface
look on different systems, you have the same keystrokes, you have one manual
about using your GUI over any OS, and, finaly, you haven't any troubles with
supports or not supports some native code on some OS.


Different perspective:

In Swing you would have to imitate the way each environment is supposed to
operate based on the system look and feel.

Now, I know your argument is that you have a consistent look and feel for all
operating environments--which saves on support costs.

However, think really hard, just what are those differences--really? Most
operating environments are basically the same. One will inovate in an area,
and the others will catch up. That way the ideas that work will make it to
all systems, and the ones that don't will go away. Really, why aren't popup
menus in the shape of pie charts? Work was done on that in the past, with
all kinds of anecdotal evidence of why it is better. But it didn't make it
in the wild. However, you go to any operating environment--Windows, Mac OS,
Mac OS X, Unix, etc. Any place there are popup windows, and they all behave
essentially the same.

There aren't that many real differences between the operating environments.
Your example was a poor one because the operating system doesn't automatically
create popup menus. The differences are subtle, and it is what gives the
illusion of polish in any one platform. Note that my comments are not
speicifically about SWT, but about native controls in general. Its like the
difference between a rayon and silk. There are subtle differences, and if you
know what to look for you can always spot them.

I am not advocating IDEA abandons Swing in favor of SWT. I already got a very reasonable response from JetBrains that shows why it is not likely to happen. I agree emphatically with their conclusions for IDEA. ]]>

0
Comment actions Permalink

Your example was a poor one because the operating system doesn't

automatically

create popup menus.


Why? In Win32 created TextBox control have clipboard menu by default... If
you sometimes write GUI programs on C++ for Win32 you may to remember it :)

Now, I know your argument is that you have a consistent look and feel for

all

operating environments--which saves on support costs.


Not quite, i want to have some code for universal GUI.The Swing give some
area for development, but that SWT give us, that only faster rendering and
native support in thier controls?

I'm not know more of SWT but it seems like step into past. I look at Swing
as to a good start point of building universal GUI. But SWT now look like
assemblers in C++ code:
void drawShape(Shape* lpShape) {
DrawingSurface* lpSurface = GetSystemDrawingSurface();
// Very slow
// lpShape.draw(lpSurface);
asm {
mov ax, lpShape
mov bx, lpSurface
...
}
}

I'm not like asm directives. For me - if some think is not fast - then i try
to make it faster by conceptual clear paradigms, but not for direct
optimization by low-level, just my point.

Maybe i not right paint my picture :))

Thank you.

--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com
"Berin Loritsch" <bloritsch@d-haven.org> wrote in message
news:bljrs5$lmu$1@is.intellij.net...

Alexey Efimov wrote:

>
>

>

Native functions is very depend on host system. Lets look at simple

example:

If Windows support clipboard operation for text control, then you reuse

by

SWT native code in your application - you not think about

left-click-popup

menu with Copy, Cut, Paste operation - it implemented already by Win32.

But

if you don't implement this on Windows, you must implement it on system
where text control not provide such option. Is it good? I think no.
From other side: Swing not show popup menu, but JTextField have

keystroke

for CtrlC, CtrlV and Ctrl+X. And this must work on any system, not

only

for Windows.

>

I think you missed the point. The point is that the controls behave the

way

a user from that operating environment would expect it to operate.

Every

time.

>

>

So, i think that OS system must provide faster draw interface and
application (if it called as crossplatform) must not use native

interface,

but must render controls. The logic is simple - if you have one

interface

look on different systems, you have the same keystrokes, you have one

manual

about using your GUI over any OS, and, finaly, you haven't any troubles

with

supports or not supports some native code on some OS.

>

Different perspective:

>

In Swing you would have to imitate the way each environment is supposed to
operate based on the system look and feel.

>

Now, I know your argument is that you have a consistent look and feel for

all

operating environments--which saves on support costs.

>

However, think really hard, just what are those differences--really? Most
operating environments are basically the same. One will inovate in an

area,

and the others will catch up. That way the ideas that work will make it

to

all systems, and the ones that don't will go away. Really, why aren't

popup

menus in the shape of pie charts? Work was done on that in the past, with
all kinds of anecdotal evidence of why it is better. But it didn't make

it

in the wild. However, you go to any operating environment--Windows, Mac

OS,

Mac OS X, Unix, etc. Any place there are popup windows, and they all

behave

essentially the same.

>

There aren't that many real differences between the operating

environments.

Your example was a poor one because the operating system doesn't

automatically

create popup menus. The differences are subtle, and it is what gives the
illusion of polish in any one platform. Note that my comments are not
speicifically about SWT, but about native controls in general. Its like

the

difference between a rayon and silk. There are subtle differences, and if

you

know what to look for you can always spot them.

>

<disclaimer>
I am not advocating IDEA abandons Swing in favor of SWT. I already got a

very

reasonable response from JetBrains that shows why it is not likely to

happen.

I agree emphatically with their conclusions for IDEA.
</disclaimer>

>


0
Comment actions Permalink


"Alexey Efimov" <aefimov@spklabs.com> wrote in message
news:bljtc4$db7$1@is.intellij.net...

i want to have some code for universal GUI.The Swing give some
area for development, but that SWT give us, that only faster rendering and
native support in thier controls?


The point is, that a user do not usually jump beween platforms, using one
app. A user runs different apps on one platform. This is why native features
are important. I do not care do they or do not implemented on other
platforms ;)


0
Comment actions Permalink

Yes, if we look from user side :)
But let look from developer side, who develop application for any users (any
systems)?

Follow your logic, we must have many copies for each user ;)

--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com


0
Comment actions Permalink

It's interesting you should say that. My experience has been similar: most
of the time, people use something on one platform only and it's very
uncommon for them to switch platforms. But I also remember that one of the
original motivations behind Swing was a massive demand from developers for
UIs that looked the same on every platform. AWT's original idea was the same
as that of SWT, but it got left to rot when Sun switched over to developing
Swing. I guess things have gone full circle.

Vil.

Michael Jouravlev wrote:

"Alexey Efimov" <aefimov@spklabs.com> wrote in message
news:bljtc4$db7$1@is.intellij.net...

>>i want to have some code for universal GUI.The Swing give some
>>area for development, but that SWT give us, that only faster rendering and
>>native support in thier controls?


The point is, that a user do not usually jump beween platforms, using one
app. A user runs different apps on one platform. This is why native features
are important. I do not care do they or do not implemented on other
platforms ;)


--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

0
Comment actions Permalink

In article <blk7p5$am3$1@is.intellij.net>,
Vilya Harvey <vilya.harvey@digitalsteps.com> wrote:

It's interesting you should say that. My experience has been similar: most
of the time, people use something on one platform only and it's very
uncommon for them to switch platforms. But I also remember that one of the
original motivations behind Swing was a massive demand from developers for
UIs that looked the same on every platform. AWT's original idea was the same
as that of SWT, but it got left to rot when Sun switched over to developing
Swing. I guess things have gone full circle.


I think what developers wanted was to be able to develop an app on one
platform and not have it automatically look like crap on another
platform.

One way to solve the problem was to let the developers control the look
of the UI at a lower level (drawing a UI with pixels in Swing instead of
with native components in AWT).

Another way to solve the problem would have been to make the UI toolkit
much higher level. So instead of the developer laying out a preference
panel by hand, the developer would provide a list of settings and the
let UI toolkit create a modal preferences dialog box with tabs on
Windows and a non-modal preference window with panel icons on Mac OS X.
This solution would have been a lot harder to implement but it would
have resulted in a much better user experience. IMHO, Java on the
desktop hasn't taken off because Swing was the wrong way to go.

0
Comment actions Permalink

Platform independence for rich GUI application is a myth and does not come
for free. There are no easy ways to deliver great applications without
investing into development (note, not only testing) for this particular
platform. Toolkits providing only a common denominator (like Sun's) do not
allow to create really great applications since often it's not enough.
However, I still think Sun could add a lot of features to AWT and Swing to
provide an experience the users expect. This seems to be more of a
political issue because if they would be telling everyone you "have" to
tweak and test your apps on every platform, that would harm the proclaimed
WORA (write once run anywhere) principle. Still, let's agree, the bare
minimum follows that promise, simple Swing apps to look work and work on all
platforms. Use standard windows, standard controls and layouts and it works
(I only wish it looked better out-of-the-box). But, this is where SWT comes
in, for simple things you can still use standard windows and controls and
they do work everywhere as well. But in this case, not only the WORA thing
is working but it also is performing better and using OS native features.
In this sense I think SWT is a better solution. On the other hand, if you
do implement custom controls and pluggable looks pretty often Swing is an
easier path. As I have already written before, both SWT and Swing are not
ideal and the only way I know of to create really great apps is to invest in
really good UI programmers and designers to develop it. And it does not
matter if it's Swing or SWT.

Eugene Belyaev


"Erik Hanson" <ehanson-lists@eh.cdeh.org> wrote in message
news:ehanson-lists-F8AA84.12102903102003@host98.intellij.net...

In article <blk7p5$am3$1@is.intellij.net>,
Vilya Harvey <vilya.harvey@digitalsteps.com> wrote:

It's interesting you should say that. My experience has been similar:

most

of the time, people use something on one platform only and it's very
uncommon for them to switch platforms. But I also remember that one of

the

original motivations behind Swing was a massive demand from developers

for

UIs that looked the same on every platform. AWT's original idea was the

same

as that of SWT, but it got left to rot when Sun switched over to

developing

Swing. I guess things have gone full circle.

>

I think what developers wanted was to be able to develop an app on one
platform and not have it automatically look like crap on another
platform.

>

One way to solve the problem was to let the developers control the look
of the UI at a lower level (drawing a UI with pixels in Swing instead of
with native components in AWT).

>

Another way to solve the problem would have been to make the UI toolkit
much higher level. So instead of the developer laying out a preference
panel by hand, the developer would provide a list of settings and the
let UI toolkit create a modal preferences dialog box with tabs on
Windows and a non-modal preference window with panel icons on Mac OS X.
This solution would have been a lot harder to implement but it would
have resulted in a much better user experience. IMHO, Java on the
desktop hasn't taken off because Swing was the wrong way to go.



0
Comment actions Permalink

Erik Hanson wrote:
> IMHO, Java on the desktop hasn't taken off because Swing was the wrong
> way to go.

I don't think the direction of Swing was the cause of Java's troubles on the
desktop. I believe that Java on the desktop simply got a bad reputation to
begin with and has never really gotten over it. AWT has always been a poor
UI toolkit and early versions of Swing were slow & very resource hungry.
Since then most (but not all) of the original criticisms have been
addressed, but the reputation lingers.

> Another way to solve the problem would have been to make the UI toolkit
> much higher level.

I do like the idea of a higher level toolkit, but that would almost
certainly not be suitable for everyone. As it is, Swing (and, presumably,
SWT) is something that you can build a higher level toolkit on top of.
That's good enough for me.

It would be interesting to see how such a toolkit would fare if it was
released into the wild as an open-source project. Are there any currently
available?

Vil.
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0
Comment actions Permalink

If it is posible to build Universal UI by invest to Swing or SWT, then it no
matter that start from - Swing or SWT. Is it?
Maybe am wrong, but i think that to building Universal UI Swing or SWT (AWT)
will not used. The new solution (whole new) must be apears.
For example - the best way to create crossplatformmed UI - is not improve
Swing or SWT, but make specification for UI in OS. Like ATX standard on
computer cases. I think that every user system must implements UI standard
and application must use standard UI API interface (same interface on all
platforms). I really think that is only possible way to create such UI
platform for development.

Thank you!

--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com


0
Comment actions Permalink

You can use an installed JDK.
All you have to do is copy the jdk/bin and jdk/lib folders to jdk/jre/bin and jdk/jre/lib.

0

Please sign in to leave a comment.