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.
Please sign in to leave a comment.
Well, that's good for the programmers but bad for the users.
The user expects all applications on his platform to behave similarly.
He doesn't care whether one program has the same behavior across different platforms.
That is, for example, a gross misconception in OpenOffice.
Swing can at least adjust its look. But it does not adjust well to behaviors (drag & drop, for example).
-- Peter
Personally I'd like to see something akin to the UI development environment supported by Cocoa (OS X). The GUI is described in a seperate xml-based file (called a nib). Interface objects defined in a nib are instantiated at runtime and can be accessed by name. Interface objects can be defined to throw events which you can subscribe to in your code.
This scheme has the following advantages (among others):
- Developers and (smart) users can make visual changes to the interface without access to the source. This includes localization and per-user customization.
- There is a fairly clean seperation between functionality and representation.
To achieve a good trade-off between WORA and GUI compliance I propose the following:
- Java will contain a nib-engine specific to the platform on which it runs. This engine is responsible for building a native GUI from platform-specific nibs and offering an API which is platform-independent (as much as possible). You can foul up your application with platform-specific code if you want something fancy, but non-generic API's will be marked.
- Nib-engines will guarantee the existance of certain components. They will have to provide native implementations if those components are not provided by the platform.
- A GUI application will transparantly load the appropiate nib (users will be able to add/replace nibs).
- The JDK contains a converter to easily convert nibs between platforms. The different nib formats are the same as much as possible to facilitate this. Interface objects which cannot be converted or can only partially be converted are flagged. You are responsible for testing/fixing this. Ideally, everything which is not flagged is guaranteed to work.
- There may be a nib-engine for Swing so you can guarantee an interface for all GUI's and/or slowly migrate your app.
This solution will achieve excellent GUI compliance, without limiting you to the lowest common denominator. You can fairly easily maintain various platform-specific GUI's. Seperate codepaths are only necessary if you use exotic components and even then the custom code is minimized. I don't have a solution for custom components though. I'm afraid that a clean solution is impossible when using native components. Still, I believe that GUI compliance is much more important, something which Swing will never enable.
Wouter Zelle wrote:
This is an idea which is occurring to a whole slew of people. Search
google for "Swing XML framework" or something along those lines and
you'll probably come across 40-50 such projects. You've found just one.
The idea sounds good in practice, but I also see a number of drawbacks,
which is possibly why none of these projects is really taking off.
1) Works for ready-made canned GUI widgets. Can you explain to me how
you would go about creating a custom widget?
This is a real Swing strength.
2) You go from maintaining your code in one place to two places - java
code and XML.
3) GUI development is about look as well as behavior. XMl or otherwise
resource files capture the look well enough. Support for listeners,
though, is kludgy in all the frameworks I've seen.
XML is not really designed for behavior. You run into some of the same
kinds of problems as spoken of in the java.net article -
http://today.java.net/pub/a/today/2003/06/10/jython.html.
4) W.r.t. your point 1, smart users make visual changes, and run - to
discover an obscure exception. Compile time safety checking is lost.
5) W.r.t. your point 2, that separation exists between the JComponent
subclasses and ComponentUI subclasses. It is the poor execution of the
latter which is causing people to complain.
Sumit.
In article <blrfpr$oek$1@is.intellij.net>,
Vilya Harvey <vilya.harvey@digitalsteps.com> wrote:
I have yet to see a Java application that behaves like a platform native
app. They are often slower (especially to start up) and they just don't
look or feel quite right. I doubt that a Java-based desktop app could
compete in the marketplace with natively-implemented applications.
(Except for custom app or apps that have no competition, like IDEA for
example.)
I've been following this discussion of Swing and SWT with interest,
particularly because this is the first time I see a known Java UI
guru pipe in.
It's obvious from frequent news releases that Eclipse has way more
momentum than Netbeans ever could garner. However, the state of SWT
perplexes me. I'm not sure how much of this momentum is because of a
buy-in into Eclipse (or IBM) vs. a buy-in into SWT. Most of what I find
on the web when I search for SWT is discussions, just like this one,
arguing the merits of SWT and native widget toolkits vs. Swing and
emulated widget toolkits. Other than eclipse.org, there's hardly any
resources beyond the very basic tutorial on SWT. No company touting
custom widgets. Sun is often criticized for its poor management of
AWT/Swing, but as a developer from day one I found tutorials covering
Swing development in good detail. To this day, on eclipse.org itself,
the articles on SWT are piecemeal and introduce certain parts of SWT -
enough to get introduced to SWT but way short of what I would need to
get started developing applications using SWT. There's nothing close to
a comprehensive SWT reference anywhere online. I search amazon for SWT,
and I come up with 0 books. I search monster.com and careerbuilder.com,
and I come up with 7 and 0 postings respectively for SWT. Among my
acquaintances, I know of no SWT developer - although I know lots who
dabbled in SWT on their own when it came out. If Jon Lipsky's finding
on http://blog.xesoft.com/jon.lipsky/blog/ are any indication, the
reasons for choosing SWT over Swing are ever shrinking.
Setting aside all the technical merits and demerits, it looks to me like
SWT is like .NET - a pretty good idea which is very far from taking off
the way it was supposed to. (OK, I feel reasonably safe from flames
saying this in a java forum. ) Maybe its time has already passed.
If you, the users of IDEA, find your experience to the contrary and see
corporate buy-in into SWT as a framework and serious work using it, can
you describe just where, how and how much you see SWT being really used?
Sumit.
Yes you are right, now is realy one user used one system. But i belive that
soon will be a smart phones with Windows inside, Palms etc. And user must be
used one application over different platforms. Whole diferent, but it must
work!
So, i think it realy time to sitdown and thinking about GUI application
standard or Operation Systems GUI API standard.
Just my point.
--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com
Erik Hanson wrote:
I can think of a few counter-examples:
Database tools: I know quite a lot of people who've stopped using TOAD (a
native app) in favour of DbVisualiser (a Swing app).
P2P Clients: I've heard, but can't confirm, that at least one of the
leading P2P client apps is written in Java.
IDEs: There are a few IDEs around which are written in native code. These
generally can't compete with the ones written in Java
It makes me wonder. Is it really "native" widgets that people want, or just
an application that looks good? There seem to be more and more applications
these days, both native AND Java, that are deliberately moving away from
standard widgets to skinnable UIs. Things like music players (WinAmp,
MusicMatch, etc.) and even, disastrously IMO, McAfee VirusScan. For these
apps, using something that looks like a native widget is a drawback as their
"cool" interface becomes a selling point. Perhaps the entire industry is
missing the point? Maybe not, but Java apps can compete in look and feel
terms with native apps in that sort of arena.
On a different note: I think you're right about start up times for Java
apps. They've gotten quicker, but they're still not as fast as the native
apps. I suspect that would change if the JVM were to pre-cache things
(dynamic libraries, JDK classes, etc.) in the same sort of way that e.g.
Mozilla does under Windows.
Cheerio,
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/
Vilya, I agree. I don't know a user who complains that our geodetic
software is not "native". Our users want to get a good looking
application, that is easy to learn and use, that is stable (my
experience: native applications tend to crash more often than Java
applications), has all the features they want and is fast enough.
I think, it's a myth from developers, that users want "native"
applications. Users want functionality they know from native
applications, but they don't care whether it is native.
BTW, a lot of native applications do not look native, because their
developers have choosen weird toolkits or tried to make it extra-cool.
And, yes, my Mozilla Thunderbird starts as slow as a Java/Swing application.
Tom
Exactly,
And i repeat again, if we look at desktop computer system - as it now, we
see one use per only system. Now user not want to change their system and
not cary about "realy native" GUI.
But if we look a little in future, we can look more mobile devices runned on
diferent systems, but user will want to see one aplication (eq mail client)
on his smartphone, palm and home computer.
And i think question about "native" code will down actuality, becose all
forces will be centered on issue of "crossplatform aplication" and "WORA"
will play main role :)
I realy belive, that "native" code, and fast aplications and not very actual
as ability to run anywhere. If aplication run anywhere it will be optimized
as it posible, but if it optimized firstly, i think its very hard to make it
crossplatformed.
Correct me if i wrong.
Thanks!
--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com
I think what users need most is consistency
Applications should behave in a similar, predictable way. Unfortunately, there are not many good examples on Windows (Linux is even worse).
Most Windows users won't complain about it, because they don't know better. They are already used to it...
-- Peter
This is what I meant with "easy to learn and use".
Tom
? wrote:
It's interesting to note that, as you seem to imply, behavioural consistency
is more important than visual consistency. That is to say, as long as the
user can identify a widget as a button, it is more important that all
buttons behave consistently than that all buttons have identical
decorations. I believe the same, but it contradicts what people tend to say
when they are criticising Swing (or Java GUIs in general).
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/
"Thomas Singer" <idea@NOregnisSpam.de> wrote in message
news:blu219$cp8$1@is.intellij.net...
>
Of course, users do not care about "nativeness" per se, they are looking for
standard features like drag-and-drop, like standard mouse and keyboard
operations, window resizing, focus control, etc. The point is, that with
native controls all this behaviour is for free, and what is more important,
it is changed automatically and uniformly system-wide with each new system
release or COMDLG32.DLL (yes, I am a Windows user). The controls would
always stay consistent and app developers would not have to alter the app
behaviour with each new OS update. Check out Arianda, for example. Look at
dialog windows: awful keyboard control, groups are badly defined if at all,
no drag-and-drop. If standard windows controls were used, most of this
functions would be implemented by Windows libraries. It would unload
unnecessary tasks from developers and at the same time would provide better
user interface.
I hate that trend, but I keep WinAmp with custom skin, because its standard
skin is not system standard and is quite plain. For everyting else I would
prefer standard controls. But this is me, others may think different. But
whatever they look like, they should behave the same.
Michael J.
standard
WinAMP is fully drawed window without any windwos controls exclude
visualization area. No buttons no scrolls, or something else.
So, WinAMP is not clear "native" application ;)
For drag & drop support as i know, you can implement only for root window
and then your aplication will control drag & drop by "native". Also for
Windows messages etc.
JFrame in Swing is a window this drawing surface, so - it can listen Windows
messages and catch them.
I think that such "native" support is enouth why not? Why clip application
areas to "native" areas to pass messaging queue to Windows?
So where only JFrame that hooks native messages from window, and may create
"native" window with native title, icon and title button, and with native
"drawing surface". It is enouth to keep succes messaging quering from host
system (including Drag & Drop mesages, etc). But that is drawing inside of
application window - it only application thing, and system will not take
apart of this process, i guess.
And last - drawing aplication to hard to be hacked "on fly" like the
password opener hack for example - hacker just send message to window and it
set style and show password not in asteriks, but in plain text. So, drawed
GUI is more secuired that application, whith using native controls.
Thanks!
--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com
In article <bluctu$gdj$1@is.intellij.net>,
Vilya Harvey <vilya.harvey@digitalsteps.com> wrote:
Excellent point. A consistent "feel" is more important than a consistent
"look". And that's what I complain about most with Swing (or Java GUIs
in generaal). Of course, the look is important too, especially for us
Mac users.
In article <bltvrn$g72$1@is.intellij.net>,
Vilya Harvey <vilya.harvey@digitalsteps.com> wrote:
Is the "cool" interface a selling point? Do most users really want
skins? Or is it just the same crew who enjoy PC case modding? (Nothing
wrong with PC case modders of course, just that they are a minority.)
I personally hate skins. When I was stuck using Windows, the first thing
I did was install Mozilla. The second thing I did was install a skin to
make Mozilla look like a native app. When I was able to
switch to a Mac, I didn't even bother downloading Mozilla because I was
afraid that I'd have to waste my time trying to get it to look like a
Mac app.
In article <blu219$cp8$1@is.intellij.net>,
Thomas Singer <idea@NOregnisSpam.de> wrote:
I'd agree with that. If an app behaves like the other apps on the
system, then the user probably doesn't care whether it is native or not.
(Actually, perhaps users' definition of "native" is "behaves like other
apps on the system".)
Vilya Harvey wrote:
http://www.limewire.org/
AFAIK those projects are all different from what I propose. This is not just about an XML-representation of the GUI, the 'magic' is in using native components which are generalized to the app. Unlike AWT, you can make substantial changes to the interface for different platforms and you are not limited by the intersection of features. For instance, I can use a status bar on windows and a textfield on OS X (in different locations on the screen). As long as they understand setText() it works.
I've already identified this weakness in my post. However, I'm not sure that this is a big problem. Given the crappy GUIs with bitmapped graphics that many companies create, I am in favor of making it harder to build your own. More programmers need to use what is out there instead of pretending that their square wheels are the innovation everyone was waiting for. If you insist (there is a small chance you actually came up with something useful), you can always create a native component. If that's not worth the trouble, it's a safe bet your fantastic widget isn't that great to begin with.
The XML should just contain definitions.
The code which controls behaviour stays in your app. The GUI definition file contains parameters which define positioning, size, etc (which you can also alter in your app, but probably shouldn't) & the names of components. You define listeners in your code and wait for someone to fill in some text or push that button after which you get control.
In code, it might be something like this:
Gui gui = GuiFactory.createGuiFromXML();
gui.setListener("textThingy", gui.textthingies.FilledInTextEvent, myTextThingyListener);
- gui-XP.xml defines the name "textThingy" and other stuff we let the GUI designer worry about (things like the type of component).
textThingy can be a TextField, TextPane or any damn thing in which you can fill in text. Our talented user Mary can switch between those widgets or use any other widget which provides the functionality we rely upon. Of course, she might screw up, but this is sanctioned hacking. No guarantees. She can always go back to our vanilla setup. On the other hand, if it works she will be extremely happy.
True, but you'll have the same problem if you store a number in a preference file. Someone may fill in some text and your program will die at runtime. If you care enough, you build an interface which checks the input. Same can be done for the interface (using the class-files to find the contraints on the GUI). The GUI should be edited visually anyway by 99% of the users. The rest should be wise enough not to screw things up.
BTW, weak typing isn't that bad:
http://mindview.net/WebLog/log-0025
> XML-representation of the GUI, the 'magic' is in using native
components which are generalized to the app. Unlike AWT, you can make
substantial changes to the interface for different platforms and you are
not limited by the intersection of features. For instance, I can use a
status bar on windows and a textfield on OS X (in different locations on
the screen). As long as they understand setText() it works.
>
ok, an XML framework not backed by AWT/Swing but by something closer to
SWT, or Mozilla and XUL. Still not much new in the proposal.
This argument leads nowhere. component customizability is not only about
putting glaring yellow icons in toolbar buttons just because you can.
It's as much about a serious company branding a product with their own
identity. Swings allows Jetbrains, Weblogic, SAP to give their products
their unique look relatively easily.
It's also about not putting your data in the one type of table that you
have, but utilizing the MVC architecture to come up with tables that are
specialized for the work you need them for.
It's not like your proposal would, say, not allow putting icons in
toolbar buttons if it is to be widely useful. Give your users that
power, sit back and see some ugly GUIs result! Nothing about your
proposal safeguards against bad GUIs, but does make work harder for
serious GUIs.
>>2) You go from maintaining your code in one place to
>>two places - java code and XML.
so?
>>3) GUI development is about look as well as behavior.
>>XML or otherwise resource files capture the look well
>>enough. Support for listeners, though, is kludgy in
>>all the frameworks I've seen.
ok, this is another take on the approach that i've seen so far. usually,
i see in the XML GUI representation
]]> gui.textthingies.TextThingyListener
you do it backwards.
I'm assuming one of your ideas with putting the GUI in an XML was easy
customizability. You have a panel with 2 buttons, sometime later you
decide you want 3 buttons, you just change the XML. Now, while the
thingy is in the XML, you have to come back and add the listener to the
code. No simpler.
You have a buttonlistener which disables all widgets, fetches data and
updates a table, writes to the statusbar and changes menu items. All of
a sudden your listener code is full of cross-references to the XML. Hard
to understand, hard to debug.
>
if this is the only thing the platform buys you, a good look and feel
implementation which is themable enough and gives
enough choices can do it easily. Switching widgets only works for the
really simple widgets.
Sumit.
You don’t need to copy anything just change the JRE path in the idea.lax file.
As I see this, the Idea team should support provided JDK, there is nothing wrong with this, but allow to run on JDK of any choice with out support.
Hello,
I was really enjoyed the discussion about Swing and SWT. My last project I was forced to use SWT (I needed ActivX integration... for free). So few words. SWT is slower! Well, it's faster in a pure rendering, but the application is not the only painting. When I have to make a complex design I need MVC otherwise I have to make a lot redunant code just to find which object I have selected (well remember the windows controls i.e. list) so every time I select I have to find a REAL object what the selected text is representing...
Few words about the portability - there is no 100% portability with SWT - it's just imposible - different controls in Win/Lin perform different and any wrapper can't make them work 100% equal.
My dream is:
SWT - just make all controls by your own in C++ (like QT) and make wrapper over it (with MVC)
SWING - get rid of AWT. make java2D working over OPENGL (there is standard openGL mapping proposed by JSR). continue... I mean that SWING is buggy but this is the right direction... Just fix it and use "deprication".
peace
My 2 kopeyka
Dmitry
XUL is different because it creates its own components. It's more like Swing in that regard. SWT is different because it doesn't allow different GUI's for different platforms. You'll still be dealing with the lowest common denominator and hard to fix bugs (the button is bigger on OS A, text size differs, etc).
I don't believe in branding by creating your own crappy GUI components. For me, IDEA is good because of the features which have got little to do with custom GUI components. Custom stuff usually detracts from the quality of an app by making it hard to use/understand. IMHO, quality is the best branding there is.
Why do you need special components for different views? Usually, it's more about using available components effectively (choosing the columns intelligently and such). Perhaps I misunderstand. Can you give an example?
I believe that it will be easier to create good, compliant GUIs and cross-platform problems will be reduced/much easier to solve. Using Swing, you will be non-compliant for any non-trivial app and you will usually run into cross-platform problems which require hacks.
So you don't necessarily want data mixed with code. Besides, you've already got code in two places: the windowing toolkit and your app. That windowing toolkit is variable. Bridging those using a abstraction layer has been a succesful solution in other problem domains (OO/SQL bridges for instance).
Yes, the button just generates events. Your code is responsible for subscribing to those events. It doesn't make any sense to me that the event generator would know who is listening to him. AFAIK, the reason for using events is to keep all the code needed for a listener in one place. In your example, you would still have to edit both your listener and the XML if you add or remove that listener.
Three major reasons:
- You can have different GUIs for different platforms without scores of if/elses in your code.
- The GUI editor has got a well-defined responsibility and doesn't need to reverse-engineer code.
- The GUI designer, translator and user can change the GUI without understanding Java (or even having access to your code).
You will indeed have to switch between the XML/GUI editor and your code, but that's acceptable to me because the division of responsibilities is clear and the advantages are there.
I don't see the problem. You know where the definition and the behaviour are. I think that's easy to understand and not really hard to debug.
That's true. It's a bit far-fetched. I was dreaming about the limits of what one can do. Being able to move & resize widgets, change the keymap (not just when your app supports it), change text and possibly removing widgets altogether (requires dropping messages to removed widgets) outside of your code are things that will be very useful to many. And a native GUI will always beat a themable look and feel. At least, I've never seen a look and feel which was themable enough to feel native.