OAS 4.0.8.1 support for JDK 1.2

Hello,
Does any one know if there is support in OAS for the JDK 1.2 because I'm having problems trying to use java/util/TreeMap class.
Thanks

Luis,
JDk1.2 is supported from OAS 4.0.8.2
You have to use JDK 1.1.X with 4.0.8.1

Similar Messages

Oracle 11g support for JDK 1.4

Dear All,
We are planning to migrate from Oracle 10.2.0.3 to Oracle 11.2.0.2. However our application server JDK version is in JDK1.4 and we use ojdbc4.jar for JDBC connectivity.
Please let me know, to migrate to Oracle 11g requires JDK1.5 and ojdbc1.5 or can we continue to stay at JDK1.4 and uses ojdbc4.jar to connect to Oracle11g.
Help Appreciated.

There is only one real answer here: test it and test it thoroughly. Asking this question here is pointless, you cannot trust anyone here to give you advice you can rely on. Whatever is said, you have to validate the claims anyway.
Or did you think that Oracle employees were going to answer your question? If so, you are sadly mistaken. Oracle charges money for giving technical support.

Which JDK is JSF supported for?

Is JSF Supported for JDK 1.3.1_03?

I think it's more of a J2EE SDK support issue and I think (but am not sure) you need J2EE1.4.
You may want to try this question on the Sun Java Studio Creator forum:
http://swforum.sun.com/jive/forum.jspa?forumID=123
Probably not the most appropriate forum, but more correct than this forum which is focused on the Sun Web Application Framework (JATO).
craig

JDeveloper 10.1.2 certified for JDK 1.5?

Hi there,
I just wanted to find out if JDeveloper 10.1.2 is certified for JDK 1.5? I have to be able to host Java/JSP code with Generics and our servers are running JDK 1.4 ... would help to know this information.
Thanks!

If you want to develop with JDK 1.5 you should use JDeveloper 10.1.3.
The tricky part is that OAS 10.1.2 doesn't support JDK 1.5 - to fix this you can install an OC4J 10.1.3 that will be managed by OAS 10.1.2.
Details are here:
http://download.oracle.com/docs/cd/B32110_01/core.1013/b32196/reconfig.htm#BABIEHFI

2007 US Daylight Savings change time zone support in JDK 1.3

Sun has supported the 2007 US Daylight Savings change in recent versions of its JDKs 1.4 and 1.5. It has made partial Daylight Savings changes to JDK 1.3, but it's not a complete implementation like in 1.4 and 1.5, because there is no support for past/future Daylight Savings rules, only a single current set of Daylight Savings rules per time zone.
Our Java application (running in the America/New_York time zone) seems to be doomed, because the likelihood of upgrading to JDK 1.4/1.5 seems slim (we have to upgrade a third-party product first and success is seeming more and more remote), and Sun claims to be unable to fully implement the Daylight Savings change in JDK 1.3.
If any Sun Java staff can explain the reasons for being unable to implement the change in 1.3 (or at least some kind of workaround that an individual JVM user could enable), please fill me in. Any pointers on cleanly setting up a custom workaround would be valuable too.
If there are other Java users in the same situation, please fill me in on your own plans if you can. Is anybody trying to pressure Sun or other vendors for a solution? Is anybody writing their own custom workaround?
More details....
What we really need is for the default TimeZone in JDK 1.3 (America/New_York on our machines) to work regardless of whether the date/time being checked is pre-2007 or post-2007. In particular, getOffset and inDaylightTime should work for both 2006 dates and 2007 dates. The JDK should return the correct values for 2006 dates, as well as the correct values for the 2007 US DST extension dates (03/12/2007-04/02/2007 and 10/29/2007-11/05/2007). This would enable parsing and formatting using SimpleDateFormat to work correctly as well. The TimeZone and SimpleDateFormat APIs are used throughout our application.
JDK 1.3.1_19 has an interesting workaround that depends on the current system time. Prior to Jan 1 2007, it will handle 2006 dates correctly but 2007 dates wrong. After Jan 1 2007, it will handle 2007 dates correctly but 2006 dates wrong. Either way, it is always wrong for some dates.
JDK 1.4.2_13 and 1.5.0_09 both handle 2006 and 2007 dates correctly.
If JDK 1.3 will never work for 2006 and 2007 dates, then I am contemplating two workarounds:
1. Set the default TimeZone to a custom implementation as soon after JVM startup as possible.
2. Avoid the default TimeZone entirely, changing our application code to rely on explicit custom TimeZones.
Prior related Java Forum topics:
* http://forum.java.sun.com/thread.jspa?forumID=31&threadID=645874 (Java Essentials - Java Programming) winds up referencing the JDK 1.4 patch as a solution, and there is some discussion about how future/historic dates affect applications
* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=735038 (Deploying - Java Upgrade) just talks about 1.4 and 1.5 patches
* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=717268 (Deploying - Java Upgrade) also just talks about 1.4 and 1.5 patches
* http://forum.java.sun.com/thread.jspa?forumID=37&threadID=703214 (Specifications - Java Virtual Machine (JVM)) also just talks about 1.4 and 1.5
Related Sun Java Bug Database bugs:
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6471271 reports the same issue with 1.3.1_19 that I am seeing and the reporter makes the same clarification, that past/future dates don't work at all still. Sun seems to indicate that it will not fix this in 1.3.1, and the 1.3.1_19 "hack" is it for 1.3.1.
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391777 refers to updates in 1.3.1_18 to address Australia DST changes, and also indicates that past/future dates (or "historic" dates) won't work at all. It gives a little more rationale behind the difficulty of implementing this for 1.3.1.
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4257314 refers to the fixes in 1.4 to support historic DST dates.
Other articles:
* Sun Java article http://java.sun.com/developer/technicalArticles/Intl/USDST/ refers to 1.3.1_18 as "resolving" the DST issue - this is misleading because the solution in 1.3.1_18 is not complete like that in 1.4 or 1.5
* Server Side article http://www.theserverside.com/news/thread.tss?thread_id=42212 refers to fixes in 1.4 and 1.5 for the DST issue, and the discussion about 1.3 doesn't lead anywhere
Thanks for any info or advice available,
Jim

Hi KBarney
I think u have the correct data file. to make sure see the "zi" dir is backed up in ur java lib folder or not.
if u have suspicion than run the tzupdater tool again.
this tool must be run for each jre/java version on your machine separately.
I tried this on 1.4.2.13 and not on 1.5.0.10. here is the result:
C:\Program Files\Java\j2re1.4.2_13\bin>java -jar c:\tzupdater\tzupdater2006p\tzu
pdater.jar -t -v
java.home: C:\Program Files\Java\j2re1.4.2_13
java.vendor: Sun Microsystems Inc.
java.version: 1.4.2_13
JRE time zone data version: tzdata2006p
Embedded time zone data version: tzdata2006p
Validating the time zone data
Validation complete
C:\tzupdater\tzupdater2006p>java -jar tzupdater.jar test verbose
java.home: C:\Program Files\Java\jre1.5.0_10
java.vendor: Sun Microsystems Inc.
java.version: 1.5.0_10
JRE time zone data version: tzdata2006k
Embedded time zone data version: tzdata2006p
Validating the time zone data
/data/tzdata2006p.test:990: test failed: America/Managua
/data/tzdata2006p.test:1465: test failed: America/Havana
/data/tzdata2006p.test:1466: test failed: America/Havana
/data/tzdata2006p.test:1847: test failed: Cuba
/data/tzdata2006p.test:1848: test failed: Cuba
/data/tzdata2006p.test:2024: test failed: America/Campo_Grande
/data/tzdata2006p.test:2026: test failed: America/Campo_Grande
/data/tzdata2006p.test:2028: test failed: America/Campo_Grande
/data/tzdata2006p.test:2030: test failed: America/Campo_Grande
/data/tzdata2006p.test:2032: test failed: America/Campo_Grande
/data/tzdata2006p.test:2034: test failed: America/Campo_Grande
/data/tzdata2006p.test:2036: test failed: America/Campo_Grande
/data/tzdata2006p.test:2038: test failed: America/Campo_Grande
/data/tzdata2006p.test:2040: test failed: America/Campo_Grande
/data/tzdata2006p.test:2046: test failed: America/Cuiaba
/data/tzdata2006p.test:2048: test failed: America/Cuiaba
/data/tzdata2006p.test:2050: test failed: America/Cuiaba
/data/tzdata2006p.test:2052: test failed: America/Cuiaba
/data/tzdata2006p.test:2054: test failed: America/Cuiaba
/data/tzdata2006p.test:2056: test failed: America/Cuiaba
/data/tzdata2006p.test:2058: test failed: America/Cuiaba
/data/tzdata2006p.test:2060: test failed: America/Cuiaba
/data/tzdata2006p.test:2062: test failed: America/Cuiaba
/data/tzdata2006p.test:2471: test failed: America/Montevideo
/data/tzdata2006p.test:2472: test failed: America/Montevideo
/data/tzdata2006p.test:2475: test failed: America/Montevideo
/data/tzdata2006p.test:2476: test failed: America/Montevideo
/data/tzdata2006p.test:2479: test failed: America/Montevideo
/data/tzdata2006p.test:2480: test failed: America/Montevideo
/data/tzdata2006p.test:2483: test failed: America/Montevideo
/data/tzdata2006p.test:2484: test failed: America/Montevideo
/data/tzdata2006p.test:2487: test failed: America/Montevideo
/data/tzdata2006p.test:2494: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2496: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2498: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2500: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2502: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2504: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2506: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2508: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2510: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2516: test failed: BET
/data/tzdata2006p.test:2518: test failed: BET
/data/tzdata2006p.test:2520: test failed: BET
/data/tzdata2006p.test:2522: test failed: BET
/data/tzdata2006p.test:2524: test failed: BET
/data/tzdata2006p.test:2526: test failed: BET
/data/tzdata2006p.test:2528: test failed: BET
/data/tzdata2006p.test:2530: test failed: BET
/data/tzdata2006p.test:2532: test failed: BET
/data/tzdata2006p.test:2537: test failed: Brazil/East
/data/tzdata2006p.test:2539: test failed: Brazil/East
/data/tzdata2006p.test:2541: test failed: Brazil/East
/data/tzdata2006p.test:2543: test failed: Brazil/East
/data/tzdata2006p.test:2545: test failed: Brazil/East
/data/tzdata2006p.test:2547: test failed: Brazil/East
/data/tzdata2006p.test:2549: test failed: Brazil/East
/data/tzdata2006p.test:2551: test failed: Brazil/East
/data/tzdata2006p.test:2553: test failed: Brazil/East
/data/tzdata2006p.test:3451: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3452: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3453: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3454: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3455: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3456: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3457: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3458: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3459: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3460: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3461: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3462: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3463: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3464: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3465: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3466: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3467: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3468: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3469: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3470: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3471: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3791: test failed: ART
/data/tzdata2006p.test:3814: test failed: Africa/Cairo
/data/tzdata2006p.test:3844: test failed: Asia/Amman
/data/tzdata2006p.test:3848: test failed: Asia/Amman
/data/tzdata2006p.test:3852: test failed: Asia/Amman
/data/tzdata2006p.test:3856: test failed: Asia/Amman
/data/tzdata2006p.test:3860: test failed: Asia/Amman
/data/tzdata2006p.test:3887: test failed: Asia/Damascus
/data/tzdata2006p.test:3908: test failed: Asia/Gaza
/data/tzdata2006p.test:3911: test failed: Asia/Gaza
/data/tzdata2006p.test:3915: test failed: Asia/Gaza
/data/tzdata2006p.test:3919: test failed: Asia/Gaza
/data/tzdata2006p.test:3923: test failed: Asia/Gaza
/data/tzdata2006p.test:4035: test failed: Egypt
/data/tzdata2006p.test:4901: test failed: Australia/Perth
/data/tzdata2006p.test:4902: test failed: Australia/Perth
/data/tzdata2006p.test:4905: test failed: Australia/Perth
/data/tzdata2006p.test:4906: test failed: Australia/Perth
/data/tzdata2006p.test:4909: test failed: Australia/Perth
/data/tzdata2006p.test:4910: test failed: Australia/Perth
/data/tzdata2006p.test:4914: test failed: Australia/West
/data/tzdata2006p.test:4915: test failed: Australia/West
/data/tzdata2006p.test:4918: test failed: Australia/West
/data/tzdata2006p.test:4919: test failed: Australia/West
/data/tzdata2006p.test:4922: test failed: Australia/West
/data/tzdata2006p.test:4923: test failed: Australia/West
Validation tests failed.
-Ranjan

Oracle To End Support for Java 7

No More Free Updates for Java 7 after April 2015
Users must sign long-term support deals or migrate to Java 8 to avoid 'enormous headache and disruption to millions of applications'
Public updates for Java 7 -- including bug and security fixes -- will end this month, a situation that one security advocate says could impact millions of applications.
"As outlined in the Oracle JDK [Java Development Kit] Support Roadmap, after April 2015, Oracle will not post further updates of Java SE [Standard Edition] 7 to its public download sites," Oracle's Java SE Support Roadmap states. "Customers who need continued access to critical bug fixes and security fixes as well as general maintenance for Java SE 7 or older versions can get long-term support through Oracle Java SE Support. The process of migrating users from Java 7 to Java 8 through the auto update feature is expected to take place after the January 2015 CPU release."
[ The art of programming is changing rapidly. We help you navigate what's hot in programming and what's going cold and give insights into the technologies that are changing how developers work. | Keep up with hot topics in app dev with InfoWorld's Application Development newsletter. ]
Oracle released Java SE 7 in July 2011; Java SE 8 was released in March 2014. Java, particularly on the client side, has been beset by security issues in recent years. But Oracle has taken many steps to address the issues and stressed that most of the problems dated back several years, before Oracle took over Java from Sun in 2010.
Still, the impact of Oracle's cessation of public updates could be severe, an official at security firm Waratek, believes. Oracle's "rapid" end-of-life schedule for Java versions is great for innovation and language evolution, Waratek CTO John Matthew Holt said in an emailed statement. "However, there is a dangerous tradeoff; now millions of Java 7 applications will have to defend themselves against code-level vulnerabilities without the benefit of future fixes." Holt advocates either upgrades to Java 8 or use of Java Run-time Application Self Protection (RASP) technologies (Waratek is a RASP vendor).
This week's security update from Oracle, meanwhile, marks the "proverbial 'end of the road' for Java 7 application security, Holt said. "After today, the only version of the Java Platform which will receive public security updates is Java 8. This is huge news, and it is going to cause enormous headache and disruption to millions of application owners around the world."
Contacted Tuesday afternoon for a comment on the end of public updates for Java SE 7, by late evening Oracle had not yet responded.
The April 2015 Critical Patch Update released Tuesday by Oracle provides 98 new fixes for security issues across a wide range of product families, said Eric Maurice in an Oracle blog post. These range from Oracle Database to Oracle Fusion Middleware, Java SE, and MySQL. Fourteen of the security fixes are for Java SE.

Java 7 has already been dead for quite a while. While you could still use it for Java apps on your system, Apple blocked its use in browsers long ago. You have to install version 8 if you need Java support for the web.

How to install ojvm in 9.0.3.x for jdk 1.4.x

I'm trying to use the profiler in Jdev 9.0.3.x. Using jdk 1.4.1_03 the memory profiler option is disabled.
Reading from other postings i understand that i need to have my VM set to ovjm. But i cant see that option with this jdk version.
any suggestions to get this working for jdk-1.4.1??
Thanks
Vishal

The JDeveloper 10g developers preview release includes JDK 1.4.1_02 with OJVM already bundled in with it.
The version of OJVM that was shipped with 9.0.3 doesn't support JDK 1.4.1.
In short, you'd need to use the 10g preview for this.
Rob

Weblogic 10 support for java 1.4

Hi,
My application is currently running on weblogic 8.1 sp3. We are upgrading to weblogic 10 on Solaris 10.
Can I run weblogic 10 on java 1.4 in Solaris 10.
This may not sound logical, but I need answers.
Thanks in advance,
Rama

Rama,
You also need to consider the End of Life policy for JDK 1.4, unless you have a "Business Release" you will run out of support in October 2008. My understanding is BEA/Oracle will continue to support WL8 but only as far as they can. Have a look at http://java.sun.com/products/archive/eol.policy.html for more details.
Regards, Geoff

ActiveX support in JDK 1.4

Where are sun.beans.ole.Packager and unregbean utility
in Java 2 SDK, Standard Edition, v 1.4 Beta 3 for Win32?
Who knows Sun's plans about ActiveX support in JDK 1.4 releases?
Thank you,
Alexander

More info found in bug 4616580. Please vote...
-Trond

Support for bi-directional GIOP any time?

One thing I was wondering about while preparing for a presentation was why bidirectional GIOP isn't supported in the 1.5 version of the ORB? The default uni-directional nature of IIOP is the achilles heel with CORBA in terms of the firewall penetration issue. (I think most agree now that making IIOP one-way was a fundamental design mistake. Bidirectional should probably be the default now.) I was just curious why Sun hasn't pursued a firewall friendly version of their version of CORBA. RMI has some support for firewall penetration, it'd be nice to see something similar for CORBA as well and further support in RMI such as full duplex communication. (If you're using Applets or trusted applications, I don't see any reason not to support multiplexed communication. ) It'd be nice to have alternative solutions in available in the JDK for the firewall penetration problem other than HTTP-based solutions. (I know that Jacorb and OpenOrb already support bi-directional GIOP, but it'd be great to have better support in the bundled version as well.)
Thanks!
Rob

I had an exchange with Sun some time ago about this and IIRC they were not convinced of the viability of the specification, can't remember the details, sorry, it's a long time ago. Are there other implementations of bi-di IIOP?

New in Kodo 3.3.3: Improved support for Java 5 enums and generics?

Hello,
Can anybody tell me if Kodo 3.3.3 can be deployed on WebLogic 8.1 sp4, jdk
1.4.1? The reason I ask this is because one of the features mentioned for
v3.3.3 is the support for Java 5 generics, which is available on WebLogic
9 -- but not in WebLogic 8.1 sp4. The documentation for Kodo 3.3.3 seems
to indicate that it can be deployed on WebLogic 8.1 -- can anyone tell me
if this is accurate?
Thanks for your help!

Correction:
I think that my question may have been misunderstood. What I want to know
is if Kodo 3.3.3 can be deployed on WebLogic 8.1sp4 which is running JDK
1.4 or do I have to deploy on a newer version of WebLogic that is running
Java 5?
Thanks!
Rita wrote:
I think that my question may have been misunderstood. What I want to know
is if Kodo 3.3.3 can be deployed on WebLogic 8.1sp4 which is running JDK
1.4 or do I have to deploy on a newer version of WebLogic that is running
Java 4?
Thanks!
Stephen Kim wrote:
Rita,
While Kodo 3.3.x can work with JDK 5, it cannot make WL work with JDK 5.
However, Kodo 3.4 RC 3 / 4.0 EA 2 both can work with WL 9 (which works
with JDK 5).
Rita wrote:
Hello,
Can anybody tell me if Kodo 3.3.3 can be deployed on WebLogic 8.1 sp4,
jdk
1.4.1? The reason I ask this is because one of the features mentionedfor
v3.3.3 is the support for Java 5 generics, which is available on WebLogic
9 -- but not in WebLogic 8.1 sp4. The documentation for Kodo 3.3.3 seems
to indicate that it can be deployed on WebLogic 8.1 -- can anyone tell me
if this is accurate?
Thanks for your help!
Steve Kim
[email protected]
SolarMetric Inc.
http://www.solarmetric.com

XDK support for UTF-16 Unicode

Hi,
Does the Oracle Java XDK, specifically the XSQL servlet and api,
support UTF16-Unicode.
Presumably, .xsql files have to be stored, read and queries
executed in a Unicode compliant format for this to work. Is this
possible currently???
Thanks,
- Manish

If you are using XDK 9.0.1 or later, and you are using JDK 1.3,
this combination supports UTF-16. XSQL inherits the support
for "free" in this case.

PKCS#11 support for x64 Windows

Hi All,
I'm trying to discover the truth (aren't we all?) Can anyone confirm what the current (and future) support for PKCS#11 for x64 Windows system is? Looking around, it appears I might be out of luck, but I'm hoping more of you might have discovered stuff I haven't?
I understand that there ARE definately providers for other platforms (which kinda defeats the platform independancy of Java doesn't it?) but I
'm not running other platforms (well apart from x86 Windows which is fine).
Thanks in advance,
Tim.

I have the same problem. The problem with the AMD 64 bit Windows downloads (both JRE and JDK) is that the file j2pkcs11.dll is missing from the build. It is present in other releases but not this one. Does anyone know where this file can be obtained?

Support for Eclipse 3.1M1

Hi,
Does anyone know which Eclipse version the EP6 SP2 (Eclipse plugin v1.2) plugins is working with? I can not find any SAP note or document about which Eclipse version the plugins work with.
Currently Im running the Eclipse 3.0 with jdk 1.3 and 1.4 which works fine. The thing is that I would like to use the UML2 plugins which does not work for me in the Eclipse 3.0 version but in Eclipse 3.1 version.
Thanks for your attention and any help,
Raz

Hello Rasmus,
the Plugins for EP6 SP2 were the last ones that were released independently of SAPs own eclipse-based IDE, the NetWeaver Developer Studio.
The plugins are now (and will be in the future) released as part of DevStudio. This means that there won't be any "standalone" plugins for eclipse any more (and thus no eclipse 3.x support for the "old" portal plugins version 1.2)
Regards,
Dieter

Toplink support for Java 5.0

I tried to import java classes, compiled with jdk 5.0
into Toplink workbench. The mapping fails.
I tried to run the workbench with jre 5.0 but that didn't work either.
Does anyone know how to do it and does Toplink even have a version that supports java 5.0?

Anna,
TopLink 10.1.3 will offer formal support for Java 5.0. Currently the runtime should work fine with Java 5.0. The only issue may be the workbench mapping process depending on the version of TopLink you are using.
If you are using the 10.1.3 preview the workbench will still run with JDK 1.4 but should be compatible with importing and mapping classes compiled with JDK5. We will upgrade the JRE used by the workbench to JDK5 for the production release but this should not make any difference to your ability to map JDK 1.4 or 5 classes and use either at runtime.
If you are using 9.0.4.X then the workbench will not be able to run or import JDK5 compiled classes. I believe the runtime is fine but not certified. For this environment you will need to compile the classes under JDK 1.4 and map this version of the classes. You can then use JDK5 compiled version in conjunction with the runtime.
I hope this helps,
Doug

OAS 4.0.8.1 support for JDK 1.2

Similar Messages

Maybe you are looking for