Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Scrap JAVA console

Created: 06 Aug 2009 | 13 comments
ShadowsPapa's picture
17 Agree
4 Disagree
+13 21 Votes
Login to vote

Scrap the Java console, move instead to ASP or ASP.NET or better yet, C++ interface.
Reasons.....
JAVA is notorously slow - even those I've worked with who program in JAVA admit it's a slow way.....
JAVA is rife with security holes and risks - how many updates have come out this year alone? And with each update to JAVA, which as security adminstrators we MUST apply, how many break SEM console? I've had to totally uninstall all JAVA and reinstall an older version twice this year to get the console to work again after a JAVA update applied for security purposes.
JAVA times out a lot.
JAVA as used even for Cisco equipment interfaces is slow so it's not just the SEM console, but the SEM console is among the slowest management consoles I've ever used. It times out a lot, it opens empty windows when I need to view or edit policies, it crashes now and then if you leave it open long-term.
Where ASP interfaces, as used in a forum I manage, acccess SQL data FAST, allows for configuring, and can be used with any browser as it's rendered on the server.
Scrap JAVA console or at least modify it to work with ANY flavor or version of JAVA and speed it up a LOT.
Java was a good idea back when, but it's time is passed...........

Comments 13 CommentsJump to latest comment

Frank019's picture

Java is easier for them it should work on all OS.

0
Login to vote
Rob374's picture

Scrap the Java!!!

+1
Login to vote
jonathan.spangler's picture

Symantec should stay with Java -- it works on everything...

0
Login to vote
JRV's picture

Comments that Java potentially enables the console to run on any OS are correct. It will run equally poorly on any OS. Actually, that's not quite true: I have one Windows machine on which it can't connect to the database for some reason. (No, not firewalling. Something more mysterious.)

Comments that Java is easier for Symantec are also correct. But what matters is what is easier for the customer, and Java ain't it.

There's precedent, even within Symantec, for dumping Java. Backup Exec used to have a Java remote console you could install, but it was slow and buggy...sound familiar? It quietly went away. Unfortunately, we don't have a choice with SEPM.

Give me an MMC console any day. One that can be installed and uninstalled without a reboot, like most MSCs, and unlike Symantec System Center's MSC. A snap-in that I can integrate with my custom MMC consoles.

0
Login to vote
peterc's picture

It's 2009 now... anything that doesn't respond immediatly on modern hardware is too slow!!
Java doesn't work, it was a great idea, but has had many years to come up to speed and just doesn't deliver.

This might have been ok with the limited hardware options back in 1995, but should not be acceptable now.

C++ works.  Use it.

+1
Login to vote
AravindKM's picture

good idea

Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind

-1
Login to vote
ShadowsPapa's picture

Question for those who believe Java is good, and is the answer:
Then why are there so many different releases and versions - and so many security holes?
Why is it that when JAVA is updated because of serious holes that some things break?
It's not just Symantec products, CISCO software reliant on JAVA is slow, too - and won't run under all browsers.
There are a number of JAVA based things that will not run in my FIREFOX. And JAVA apps keep crashing my OPERA install.
If JAVA runs on anything - which version? What happens when Cisco says their console will work best with release xxx.xxx.001 and Symantec says you have to run xxx.xxx.004 and there's a conflict? And then Sun releases xxx.xxx.008 because the others have holes big enough to drive a root kit through?
Security consoles based on a platform rife with security holes and constantly being updated............. not to mention the speed issues.
When I'm using the SEP console, there are times I'm there because I need something done and need it done FAST. But I hit a policy tab and it takes 20 seconds for the view to change? (and this is on the SERVER)
Or I click to refresh and the screen goes blank for 15 seconds, then comes back finally, and it takes another 10 seconds for it to respond to a mouse.
It's not the install - it does this on all of our machines running the console - servers, VISTA, XP, you name it.
IMO - >
JAVA is slow
JAVA is constantly being updates due to security risks and other issues
There is no standard JAVA build that all companies can agree on.
An update to JAVA can break your SEP console? Yes. Ironic, isn't it?
Basing a security app console on JAVA, which has security issues more than once a year is rather ironic, I think.
But - I have to agree, it's the cheap, easy way out..............
But why - when SEP is for Windows based computers only, why then do we care if it will run on other OSs? Sep and SEM won't.........
Why would i care if the console will run on MAC or LINUX - SEP and SEM won't............

0
Login to vote
JRV's picture

Playing devil's advocate: Currently, Mac and Linux users are stuck with SAV. But my guess, particularly because the console uses Java and SEPM uses Tomcat, is that Symantec's plans are to support Windows, Mac and Linux with both SEP and SEPM. Someday.

And there advantages to all of us (but especially for the minority OS's) to having one code base for all 3. It will enormously reduce their development cost, ensure feature parity across all OS's, and, overall, make the product's development easier to manage.

But I'd much prefer to have native code for each platform. Or at least for the only platform I care about: Windows.

0
Login to vote
John_Prince's picture

Greetings,

I do know that we plan to support both MAC and Windows with SEP soon, I am unsure on Linux though. This would be client only, not the SEPM. The SEPM , as far as I am aware, will only be on Windows so we could theoretically use any code base that Windows will support and still not have any issues with cross platform support. The only cross-platform support we would handle is HTTP traffic from one platform to another and that has nothing to do with Java or any other code base we could use. I completely agree that moving away from Java would be best. From an internal perspective, it seems to cause more problems than the ease of coding is worth. Then again I am not a developer so...

We do plan to move away from IIS at some point for similar reasons. Hopefully we can get some more positive votes on this!

Remote Product Specialist, Business Critical Services, Symantec

+1
Login to vote
JRV's picture

Thanks for that insight. I hereby retract all my speculation. And scrap Java!!

0
Login to vote
rshah's picture

Totally agree with this, i was shocked at how slow it was when i first installed SEPM!!!

0
Login to vote
pebcak's picture

Let them work with the Unser Interface folks from the Altiris Platform and move it to Silverlight.  The work they are doing on the Altiris side is slick and fast.  No graoning about being stuck with IE.

Senior Consultant @ Creative Breakthroughs, Inc. a Symantec Platinum Partner

http://www.cbihome.com/

+1
Login to vote
Barb123's picture

Yes please scrap Java - troublesome, slow, insecure and patch nightmare.

0
Login to vote